Secrets in cdkd local run-task

cdkd local run-task fetches every entry in a container's Secrets once, at startup, and sets each one as an environment variable in the container. This is what ECS does when it starts the task.

taskDef.addContainer('web', {
  image: ecs.ContainerImage.fromAsset('app'),
  secrets: {
    DB_PASSWORD: ecs.Secret.fromSecretsManager(dbSecret, 'password'),
  },
});

cdkd local run-task MyStack/TaskDef --from-state

ecs.Secret.fromSecretsManager(dbSecret) synthesizes a reference to the secret's ARN, so the command needs --from-state or --from-cfn-stack to learn the ARN. Environment variables and secrets covers that step.

Which ValueFrom forms are fetched

After references are resolved, cdkd fetches each Secrets[].ValueFrom according to its form:

When a secret cannot be fetched

The run stops, and the error names the container and the secret. Fix your credentials or the IAM policy and run the command again.

How the value reaches the container

cdkd passes the value to docker run through the environment of the docker run process, so the value does not appear on a command line.

The exception is finch on macOS and Windows, where cdkd refuses to run a task that has secrets.

Secret names that are not forwarded

cdkd drops a secret, with a warning naming it, when the secret's name would change how the container client itself behaves. A secret named DOCKER_HOST, for example, would point the client at another Docker daemon, which would let a template redirect it. If the container needs such a secret, rename it.

Two kinds of name are dropped. The first is a name that is empty or contains = or a NUL character. The second is a name, in any letter case, that the container client (Docker, podman, nerdctl, finch) or one of its credential helpers reads:

Related

• cdkd local run-task: the worked example and the options
• Value resolution in local execution: how --from-state and --from-cfn-stack resolve a secret's ARN