Adding regex validation for SSM parameters in nodeadm init command

[vikash-s1]

Issue #, if available: N/A

Description of changes:
SSM Activation parameter validation in nodeadm init command:
Added Regex validation for SSM Activation parameters based on SSM documentation - https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreateActivation.html#systemsmanager-CreateActivation-response-ActivationId

Testing (if applicable):

1. Added comprehensive unit tests to validate:

• Presence of IAM and SSM parameters in nodeConfig file
• Presence of SSM ActivationID and ActivationCode
• Regex pattern matching for SSM Activation parameters format

2. E2E tests - done

Logs:

2025-06-20T13:59:17.627-0700	INFO	Status: Success
2025-06-20T13:59:17.627-0700	INFO	ResponseCode: 0
2025-06-20T13:59:17.627-0700	INFO	Stdout: * Validating hybrid node configuration [Success]
* Validating access to AWS IAM Roles Anywhere API endpoint [Success]
* Validating authentication against AWS [Success]
* Validating access to Kubernetes API endpoint [Success]
* Validating unauthenticated request to Kubernetes API endpoint [Success]
* Validating authenticated request to Kubernetes API endpoint [Success]
* Validating Kubernetes identity matches a Node identity [Success]
* Validating access to Kube-API server through VPC IPs [Success]
* Validating kubelet server certificate [Success]

--- 

:35:24.899-0700	INFO	Stdout: * Validating hybrid node configuration [Success]
* Validating access to AWS SSM API endpoint [Success]
* Validating authentication against AWS [Success]
* Validating access to Kubernetes API endpoint [Success]
* Validating unauthenticated request to Kubernetes API endpoint [Success]
* Validating authenticated request to Kubernetes API endpoint [Success]
* Validating Kubernetes identity matches a Node identity [Success]
* Validating access to Kube-API server through VPC IPs [Success]
* Validating kubelet server certificate [Success]

3. nodeadm test on Node

• "./nodeadm init -c file://nodeConfig.yaml" with invalid ACTIVATION_CODE

# ./nodeadm init -c file://nodeConfig.yaml
{"level":"info","ts":"2025-06-06T20:08:08.316Z","caller":"init/init.go:62","msg":"Checking user is root.."}
{"level":"info","ts":"2025-06-06T20:08:08.316Z","caller":"init/init.go:76","msg":"Loading installed components"}
{"level":"info","ts":"2025-06-06T20:08:08.600Z","caller":"init/init.go:92","msg":"Validating firewall ports for cilium and calico"}
{"level":"info","ts":"2025-06-06T20:08:08.641Z","caller":"node/node.go:13","msg":"Loading configuration..","configSource":"file://nodeConfig.yaml"}
{"level":"info","ts":"2025-06-06T20:08:08.641Z","caller":"node/node.go:23","msg":"Setting up hybrid node provider..."}
{"level":"fatal","ts":"2025-06-06T20:08:08.643Z","caller":"./main.go:55","msg":"Command failed","error":"invalid ActivationCode format: TEMPWuobPjjP2oRATM6. Must be 20-250 characters"}

• ./nodeadm init -c file://nodeConfig.yaml with invalid ACTIVATION_ID

# ./nodeadm init -c file://nodeConfig.yaml
{"level":"info","ts":"2025-06-06T20:08:59.611Z","caller":"init/init.go:62","msg":"Checking user is root.."}
{"level":"info","ts":"2025-06-06T20:08:59.611Z","caller":"init/init.go:76","msg":"Loading installed components"}
{"level":"info","ts":"2025-06-06T20:08:59.875Z","caller":"init/init.go:92","msg":"Validating firewall ports for cilium and calico"}
{"level":"info","ts":"2025-06-06T20:08:59.916Z","caller":"node/node.go:13","msg":"Loading configuration..","configSource":"file://nodeConfig.yaml"}
{"level":"info","ts":"2025-06-06T20:08:59.917Z","caller":"node/node.go:23","msg":"Setting up hybrid node provider..."}
{"level":"fatal","ts":"2025-06-06T20:08:59.918Z","caller":"./main.go:55","msg":"Command failed","error":"invalid ActivationID format: E2043439-ace9-4962-83ce-89fcf7c62426. Must be in format: ^[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}$"}

Documentation added/planned (if applicable): N/A

[jaxesn]

Just a thought, not suggesting one way or another, currently the debug command deos require the config, but we do not necessarily need all of it. like for example if the ssm stuff isnt in there, debug doesnt really care since its intended to be run after the init process where the ssm will either register or fail.

im not opposed to adding these validations on the config in the debug command, just wanted to call out that some (maybe most) of the specifics in the config do not matter to the debug command.

[junpengdev]

Unit test is failing. Please fix them.

[junpengdev]

The sample you show in the PR description for invalid ACTIVATION_CODE seems not correct. It showed invalid ACTIVATION_ID.

[vikash-s1]

Unit test is failing. Please fix them.

Ack, String match error in unit test. Fixed in #2.

[vikash-s1]

Just a thought, not suggesting one way or another, currently the debug command deos require the config, but we do not necessarily need all of it. like for example if the ssm stuff isnt in there, debug doesnt really care since its intended to be run after the init process where the ssm will either register or fail.

im not opposed to adding these validations on the config in the debug command, just wanted to call out that some (maybe most) of the specifics in the config do not matter to the debug command.

Agree, debug command, looks designed to run after Init. However, the debug command can also run without the init command or with a failed init configuration.
The intent behind adding the "hybrid node configuration validation" to validate the input provided in "file://nodeConfig.yaml" file, and provide error logs and remediation steps. If we do not log this error in the debug output, the access to the AWS SSM API endpoint will still pass, even without the correct nodeConfig file. This could potentially confuse the user.

root@hybrid-node:/home/eksahybrid# ./nodeadm debug -c file://nodeConfig.yaml
* Validating hybrid node configuration [Success] <- Newly added validation in this PR.
* Validating access to AWS SSM API endpoint [Success] <- SSM Authentication can be success with wrong parameters 
* Validating authentication against AWS [Success] <- IAM Authentication can be success with wrong parameters 
* Validating access to Kubernetes API endpoint [Success]
* Validating unauthenticated request to Kubernetes API endpoint [Success]
* Validating authenticated request to Kubernetes API endpoint [Success]
* Validating Kubernetes identity matches a Node identity [Success]
* Validating access to Kube-API server through VPC IPs [Success]

[jaxesn]

lets just remove this from debug for now, per previous discussions with @g-gaston. debug is not meant to be run until init has succeeded. If a user does run debug before getting a successful init, most of the checks are going to return back errors because its expecting the node to be setup and working. Validating the config adds little value in those cases.

Its a minor change either way and if we see customer usage of debug/init not matching our expectations and it makes sense to add this back, we always can later.

[vikash-s1]

Done. Removed debug validation.