(aws-ecs): pass a secret to ContainerImage's buildArgs

[fitzchak]

Currently it is possible to pass only strings to ContainerImage's buildArgs.
Feature request: Add an option to pass a secret to ContainerImage. This parameter can be called buildArgsSecrets or secrets as for QueueProcessingFargateService.

Use Case

I need to create a .ssh key on the machine at build time.

Proposed Solution

const image = ContainerImage.fromAsset('../project-processor', {
  buildArgsSecrets: {
    GIT_SSH_KEY: EcsSecret.fromSecretsManager(secret, 'gitSshKey'),
  }
});

const service = new QueueProcessingFargateService(this, 'QueueProcessingFargateService', {
  cluster,
  queue,
  image,
  secrets: {
    BOT_TOKEN: EcsSecret.fromSecretsManager(secret, 'botToken'),
  }
});

Dockerfile:

ARG GIT_SSH_KEY
RUN echo "${GIT_SSH_KEY}" > /root/.ssh/git_user_key

---

This is a 🚀 Feature Request

[dillon-odonovan]

I have a similar need. I'd like to have some Docker Lambda functions (.NET 5) and also have a need to pull in private packages from an internal repository. I'd prefer to have the packages restored during the Docker build, but I cannot find a way to securely provide the token to the Docker build step.

We're capable of achieving this by defining our own CodeBuild projects, retrieving the value from some secure location (e.g., SSM) and then providing that variable to Docker via --build-arg MY_ARG=$MY_SECRET where MY_SECRET is an environment variable on the build agent resolved from SSM.

In an attempt to provide an environment variable in a similar fashion but without the overhead of explicitly setting up a CodeBuild project, we tried to use a CDK Pipeline (pipelines/CodePipeline). This defines a CodeBuild project for us and nearly fits our needs. However, the build args are provided to Docker in quotes and so the reference is not expanded (--build-arg MY_ARG=$MY_SECRET (what we did ourselves) vs --build-arg 'MY_ARG=$MY_SECRET' (what CDK generates))

[whummer]

We have a similar use case - would be great to see this supported! 👍 The only workarounds currently seems to be to either:

1. use plaintext string build args (could be problematic from a security point of view)

2. pass the secret as a runtime parameter to the container, run some initialization logic using the secret on container startup (can have a significant performance impact, and jeopardize the stability of deployments)

Did anyone come across any other workarounds? @fitzchak @dillon-odonovan

If any of the maintainers could give us a hint where to start with this, we may be able to contribute a pull request, potentially. Thanks!

[markusl]

We have also a need for this. I originally opened #11623 which was closed as a duplicate of #10999 which is marked as resolved but I think the implementation is still missing.

This is a very essential step for most of our Docker builds where we need to fetch/authenticate to internal repositories.

[github-actions]

This issue has received a significant amount of attention so we are automatically upgrading its priority. A member of the community will see the re-prioritization and provide an update on the issue.

[matt-kunze-nutrien]

Just ran into a similar problem trying to use lambda.Code.fromDockerBuild(...) - being able to pass build args that originate from secrets would be valuable

[AjkayAlan]

We also have a similar need where we need to use have secrets injected via buildArgs (specifically, Artifactory credentials). The suggestions here are viable and would work for us as well. One other thought - Could the buildArgs value be optional? Something like:

readonly buildArgs?: {
    [key: string]: string | undefined;
};

If the value is undefined, CDK could pass the build args to the docker build command without those values, and rely on the local environment (see https://docs.docker.com/engine/reference/commandline/build/#set-build-time-variables---build-arg). This would allow folks to define and/or set those values on their continuous integration as environment variables, but not end up exposing/storing them in the cdk synth output.

[PeterBaker0]

Our team also has a need for this - in our case we want to install some libraries from a private git repository as part of the docker build for deploying a containerised lambda function. Doing so requires authenticating to the git repo with a token.

Seeing work on this feature would be great!

[NapalmCodes]

Similar need here as well. We have a container requiring AWS credentials for CodeArtifact authentication. An NPM tool is needed inside the built container.

[stocks29]

Similar need here. Would ideally like a build arg passed which references an environment variable in the build environment to provide credentials for a private package repo to our docker build process.

[veimox]

@AjkayAlan We have the same need so I just created an issue to track it as this is different from the need of this issue

[paula75]

Similar need, when i try to use docker image in lambda, I need to pass a token to dowload a private repository. I used a environment variable in cdk deploy, but the problem then is that if i go to CloudFormation i can see my credentials as a string in the template Metadata.

[alextriaca]

+1 for this on the lambda fromDockerBuild. We've just run into this after moving off our own custom compilation.