Service

ECS

API Action / Feature

RegisterTaskDefinition / RunTask: support containerDefinitions[].secrets (the Secret object: name + valueFrom), and inject the resolved values as environment variables when launching task containers.

Today the secrets field is dropped on register (not parsed, not stored, not returned by describe) and never resolved at launch, so containers started against Floci come up without the env vars their task definition declares via secrets.

AWS Documentation

• ContainerDefinition: https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_ContainerDefinition.html
• Secret: https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_Secret.html
• Secrets Manager env vars: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/secrets-envvar-secrets-manager.html
• SSM Parameter Store env vars: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/secrets-envvar-ssm-paramstore.html

valueFrom accepts a Secrets Manager secret full ARN, or an SSM parameter (name when same-region, or full ARN). Secrets Manager also supports a selector suffix on the ARN: ...:secret:name-AbCdEf:json-key:version-stage:version-id.

Why is this needed?

Real task definitions pull config/credentials through secrets rather than plain environment. When emulating against Floci, those containers launch with the env vars missing, so the app under test can't start or misbehaves. Plain environment already works end to end; secrets is the remaining gap for running realistic task definitions locally.

There's an in-tree precedent for the resolution itself: CodeBuildRunner.buildEnvList(...) resolves both sources locally via SsmService.getParameter(name, region) and SecretsManagerService.getSecretValue(secretId, versionId, versionStage, region). ECS launch (EcsContainerManager.buildEnvVars(...)) can resolve through the same local services rather than adding HTTP hops.

Rough scope:

• Parse / store / round-trip secrets on the container definition (describe returns the references, not resolved values, matching AWS).
• Resolve to env vars at launch, with the existing RunTask containerOverrides environment still winning on a name collision.
• Initial resolution: SSM parameter name or full ARN, and Secrets Manager full ARN resolving to SecretString. The Secrets Manager :json-key:version-stage:version-id selector suffix needs parsing beyond what CodeBuild does today (it passes the whole valueFrom as the secret id). Happy to include it or defer it, your call.

One design question

Behavior when a referenced secret/parameter can't be resolved. AWS doesn't silently start the container with the var omitted; the unresolved reference surfaces as a task launch / resource-initialization failure. Floci's existing CodeBuildRunner instead swallows it (debug-log and continue). @hectorvent, for ECS do you want to fail the launch (and if so, as a RunTask error vs a started-then-stopped task in the current local launch model), or keep CodeBuild's lenient skip-and-continue for local-dev convenience?

Are you willing to contribute a PR?

• Yes
• No