Updated SSM Agent version

[WilboMo]

Issue number:
Fixes #7

Description of changes:
Bumps SSM Agent to latest available, 3.0.732.0, and updates S3 URL to the first region SSM Agent releases are deployed to.

Testing done:

Reviewed SSM Agent changelog for changes which would affect control-container usage and verified functionality of SSM Agent in control-container:

Confirmed control-container functionality by pushing a test image to ECR, pulling it into a Bottlerocket EKS stack as a replacement control-container. Verified enable-admin-container ran correctly and checked SSM agent in use is the correct version: 3.0.732.0.

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

[tjkirch]

Sounds like the main reasons for the 3.0 bump is Opt-in self update feature to upgrade if agent is running a deprecated version and Telemetry feature to send important audit events to AWS. Opt-in send to customer CloudWatch, which we wouldn't opt-in to.

It also has Monitor and keep the ssm-agent-worker process running in the 3.0 bump which makes me think we should inspect the differences with regard to how the agent service runs, just to make sure we're not worried about how it'll start/restart inside the control container. (e.g. they also mention Fix for systemd configuration to always restart the agent when it exits for any reason which is probably ok, but worth understanding.)

I looked through the rest of the changelog and didn't see anything that scared me.

[WilboMo]

Sounds like the main reasons for the 3.0 bump is Opt-in self update feature to upgrade if agent is running a deprecated version and Telemetry feature to send important audit events to AWS. Opt-in send to customer CloudWatch, which we wouldn't opt-in to.

It also has Monitor and keep the ssm-agent-worker process running in the 3.0 bump which makes me think we should inspect the differences with regard to how the agent service runs, just to make sure we're not worried about how it'll start/restart inside the control container. (e.g. they also mention Fix for systemd configuration to always restart the agent when it exits for any reason which is probably ok, but worth understanding.)

I looked through the rest of the changelog and didn't see anything that scared me.

Thank you for calling those items out, I took a deeper look into them and found the following:

Fix for systemd configuration to always restart the agent when it exits for any reason:

This change sets the SSM Agent to restart regardless of the exit code. It also sets some logic to delay the restart to allow for reboots initiated by scripts. Should the exit code for the agent be 194 (reboot requested), it doesn't restart at all.

Monitor and keep the ssm-agent-worker process running:

It appears that this change introduced a worker which the core SSM Agent communicates with over IPC. There are a few channels which the agent and worker communicate over to determine worker health, process restart requests from the agent core and should the agent core terminate, allows the worker to determine if it should also terminate. Primarily the logic changes are around introduction of code to allow communication with the agent and worker, the overall functionality seems to be largely the same. Most of this is laid out in the agent/ipc/messagebu/respondent.go and agent/agent/agent.go files introduced/modified in release 3.0.151.0.

[etungsten]

🚀

[zmrow]

🦅

[tjkirch]

Thanks!