feat(main): Make configuration parameters of type SSM SecureString

[alpozcan]

It is understandable to keep non-sensitive configuration information as a plain SSM String, however for the purposes of SOC2 compliance in our organisation, we need to make all SSM Parameters encrypted.

This PR changes the type for the below SSM parameters so that they are SecureString:

• "${var.ssm_paths.root}/${var.ssm_paths.config}/cloudwatch_agent_config_runner"
• "${var.ssm_paths.root}/${var.ssm_paths.config}/run_as"
• "${var.ssm_paths.root}/${var.ssm_paths.config}/agent_mode"
• "${var.ssm_paths.root}/${var.ssm_paths.config}/enable_jit_config"
• "${var.ssm_paths.root}/${var.ssm_paths.config}/enable_cloudwatch"
• "${var.ssm_paths.root}/${var.ssm_paths.config}/token_path"

[npalm]

Thank you for taking the time to create a PR. The SSM paramters you are changing are not considers to be secret or senstive and all. For that reason, we use the plain string. Please can you explain why you think those should be sentive?

[alpozcan]

Thank you for taking the time to create a PR. The SSM paramters you are changing are not considers to be secret or senstive and all. For that reason, we use the plain string. Please can you explain why you think those should be sentive?

Hi,
I believe I already did in the first paragraph above, also acknowledging that they are not sensitive.

[npalm]

Thank you for taking the time to create a PR. The SSM paramters you are changing are not considers to be secret or senstive and all. For that reason, we use the plain string. Please can you explain why you think those should be sentive?

Hi, I believe I already did in the first paragraph above, also acknowledging that they are not sensitive.

Sorry mis-read the description. Did you test your change on a actual deployment?

[alpozcan]

@npalm Sorry, didn't actually mean to close this.

I have re-forked this in our GH organisation, applied the changes above there and also reverted it to v4.6.0. This'll do for our purposes for now.

It deployed successfully on top our v4.1.0 deployment. However, even thought the runners get launched fine, they do not pick up jobs now.

I'll troubleshoot this later.