Introduction

Cloning a private Git repository during a Docker build is possible, but the main challenge is not the git clone command itself. The real problem is avoiding credential leakage into image layers, build logs, or the final runtime image. The safest modern pattern is to use Docker BuildKit with an SSH mount or secret mount instead of embedding keys in ARG or ENV.

Use BuildKit SSH Forwarding

If your repository is accessed over SSH, BuildKit can forward your local SSH agent into the build step without copying the private key into the image.

1# syntax=docker/dockerfile:1.6
2
3FROM alpine:3.20 AS source
4
5RUN apk add --no-cache git openssh-client
6RUN mkdir -p -m 0700 /root/.ssh && ssh-keyscan github.com >> /root/.ssh/known_hosts
7
8WORKDIR /src
9RUN --mount=type=ssh git clone [email protected]:example/private-repo.git .
10
11FROM alpine:3.20
12WORKDIR /app
13COPY --from=source /src /app
14CMD ["ls", "-la", "/app"]

Build it like this:

docker build --ssh default -t private-repo-image .

This keeps the key outside the image layers. The forwarded SSH agent is available only during that specific build step.

Use a Secret for Token-Based HTTPS Access

If your platform uses HTTPS with a personal access token, use a BuildKit secret rather than a build argument.

1# syntax=docker/dockerfile:1.6
2
3FROM alpine:3.20 AS source
4RUN apk add --no-cache git
5
6WORKDIR /src
7RUN --mount=type=secret,id=git_token \
8    GIT_TOKEN="$(cat /run/secrets/git_token)" && \
9    git clone "https://${GIT_TOKEN}@github.com/example/private-repo.git" .
10
11FROM alpine:3.20
12COPY --from=source /src /app
13WORKDIR /app
14CMD ["ls", "-la"]

Build command:

printf '%s' "$GITHUB_TOKEN" | docker build \
  --secret id=git_token,src=/dev/stdin \
  -t private-repo-image .

This is still sensitive, but it is much safer than ARG GIT_TOKEN, which can end up in build history or layer metadata.

Do Not Bake Credentials into the Final Image

A multi-stage build is important even if the clone step itself is secure. It keeps Git metadata, package-manager residue, and any temporary auth setup out of the runtime image.

Good pattern:

• first stage: install Git and fetch source
• second stage: copy only the needed project files

Avoid patterns like this:

ARG SSH_KEY
RUN echo "$SSH_KEY" > /root/.ssh/id_rsa

That leaves secrets in the build graph and often in image history too. Even if you later delete the file, the earlier layer still exists.

Decide Whether the Clone Belongs in the Dockerfile at All

Sometimes the cleanest answer is not to clone inside the Docker build. In CI, it is often better to check out the repository before docker build and pass the working tree as the build context.

Example:

git clone [email protected]:example/private-repo.git
cd private-repo
docker build -t app-image .

This avoids build-time Git auth entirely and makes the Dockerfile simpler. Cloning inside the Dockerfile is most useful when the build itself intentionally pulls a second private dependency repository.

Common Pitfalls

• Passing SSH keys or tokens through ARG or ENV leaks secrets into image history.
• Forgetting to enable BuildKit makes --mount=type=ssh and secrets unavailable.
• Copying .git and credentials into the final runtime image exposes unnecessary metadata.
• Using ssh-keyscan without understanding host trust can weaken supply-chain hygiene if you accept the wrong host key.
• Cloning in the Dockerfile when CI could provide the source tree directly adds complexity for no benefit.

Summary

• Prefer BuildKit SSH mounts or secret mounts for private Git access during Docker builds.
• Use multi-stage builds so auth tooling and temporary files do not reach the final image.
• Never bake credentials into ARG, ENV, or committed Dockerfiles.
• Consider cloning outside Docker when the repository itself is the primary build context.
• Treat build-time Git authentication as a security problem first and a Docker problem second.