Sometimes you want to clone a private GitHub repository inside your Dockerfile’s image build process
and use it for your application build.
So you need to pass a GitHub PAT (Personal Access Token) during the image build to clone from GitHub.
I momentarily struggled with how to pass secrets from CircleCI’s Orb (aws-ecr),
so I’m documenting it here.
Prerequisites
- Docker Buildkit for building
- CircleCI 2.1
- aws-ecr: 8.2.1
The Solution
Let’s assume you have a Dockerfile like the one below.
It expects a secret (mypat) to be passed as a parameter during docker build.
FROM nginx:latest
RUN --mount=type=secret,id=mypat,uid=0 \
cat /run/secrets/mypat && \
TEST_ENV=$(cat /run/secrets/mypat)
# Use the TEST_ENV environment variable in subsequent build processes
In conclusion, you can call the aws-ecr build-and-push-image job/command like this:
- aws-ecr/build-and-push-image:
repo: "${AWS_RESOURCE_NAME_PREFIX}"
tag: "${CIRCLE_SHA1}"
extra-build-args: "--secret id=mypat,env=GITHUB_TOKEN"
The key point is the "extra-build-args" section.
This is where you pass additional parameters for the docker build command.
Reference: https://circleci.com/developer/ja/orbs/orb/circleci/aws-ecr#commands-build-and-push-image
With the env= part, you can pass the value of an environment variable from the container running CircleCI.
For example, you can set up GITHUB_TOKEN in CircleCI’s context and pass it as a secret (mypat).
Additional Note
Before Docker Engine 20.10.0, the only way to pass secrets was through files.
This article was very helpful in understanding this:
https://developer.feedforce.jp/entry/2021/03/15/102530
For example, on the CI side, you had to create a temporary file and pass it during docker build,
which was a roundabout approach.
echo $GITHUB_TOKEN > /home/circleci/project/mypat
docker build -t ${CIRCLE_SHA1}:latest --secret id=mypat,src=/home/circleci/project/mypat .
I was wondering how to adapt this approach when using the aws-ecr Orb for build/push. After some research, I found that since 20.10.0, you can pass secrets via environment variables like –secret id=my_env,env=MY_ENV, which is what I used.
If you’re still generating temporary files to create secrets,
this might be a good opportunity to refactor your approach.
