[singholt]

Summary

Add config/capability for IMDS-based task credential retrieval. This also acts as the feature flag, which is disabled for now.

Implementation details

• config: Resolves whether the feature should be enabled based on IMDS availability and instance state. The new helper method to check these conditions isn't invoked in this PR, hence the configuration stays disabled by virtue of Go's default boolean value of false.
• data: Persists enablement across restarts and detects in-place upgrades via running/pending task state. The new key is also not used currently.
• capability: Advertises the capability when the config is enabled.
• utils/ec2metadata: Checks IMDS reachability on the instance.

Testing

New tests cover the changes: yes, added new unit tests

Manually built this on an ECS instance, and verified that the new config and capability isn't enabled.

Description for the changelog

Feature - Add config/capability for IMDS-based task credential retrieval (disabled for now).

Additional Information

Does this PR include breaking model changes? If so, Have you added transformation functions?
No.

Does this PR include the addition of new environment variables in the README?
No.

Licensing

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[sparrc]

detects in-place upgrades via running/pending task state

This seems like a strange way to detect in-place upgrades to me, why not do it via ecs-init env var (since ecs-init knows about in-place upgrades since it detects the special exit code)? Or what about gating this feature on just simply the existence of a state db?

[sparrc]

I am also thinking that perhaps it's safer to not ever change the "credential mode" of an existing instance, even if it's been idle for a while, do we know that IMDS will definitely be updated to provide the special cred endpoints on a long-running instance?

[singholt]

detects in-place upgrades via running/pending task state

This seems like a strange way to detect in-place upgrades to me, why not do it via ecs-init env var (since ecs-init knows about in-place upgrades since it detects the special exit code)? Or what about gating this feature on just simply the existence of a state db?

Good call-out. Although ECS init knows that an in-place upgrade has occurred, it cannot distinguish between 1) an in-place upgrade to/from 2 imds-iam-roles feature aware instances, and 2) in-place upgrade from a non-imds-iam-roles feature aware instance to a imds-iam-roles aware instance. It also doesnt work for OSes like Windows where ECS init is not available.

The state persistence lets agent independently decide without relying on any other components' decision-making/state.

[singholt]

I am also thinking that perhaps it's safer to not ever change the "credential mode" of an existing instance, even if it's been idle for a while, do we know that IMDS will definitely be updated to provide the special cred endpoints on a long-running instance?

This is also a good callout. Currently, this change builds on the fact that once the agent advertises this capability, IMDS will be updated for new tasks. I do plan to cover this scenario in my end-to-end test plan!