Install a Private Go Module in a Dockerfile Without Leaking Credentials

Your team's Go app depends on git.corp/mycompany/logger, a module hosted on the company's private Git server. To download it, the build needs the credentials stored in ~/app/.netrc.

A teammate wrote a Dockerfile that copies the .netrc file into the image, downloads the dependencies, and then deletes the file with RUN rm -f /root/.netrc. Does deleting the file actually protect the credentials?

Start by inspecting the project:

cat ~/app/Dockerfile
cat ~/app/go.mod
cat ~/app/.netrc

You'll also see corp-ca.crt in the project. It's the public certificate of the company's internal certificate authority, which the build needs to trust git.corp over HTTPS. It isn't a secret.

Step 1: Build and push the insecure image

Build the app using the original, unmodified Dockerfile, then push the image:

docker build -t registry.iximiuz.com/my-app:insecure ~/app/

docker push registry.iximiuz.com/my-app:insecure

Step 2: Fix the credential leak

The checker found the token in an image layer, even though .netrc is no longer visible in the container's filesystem. Anyone who can pull this image could recover the token and use it to access the company's private repositories.

Update ~/app/Dockerfile so that:

1. The app still builds and runs, including downloading the private module during docker build.
2. The credentials are never written to any image layer, including intermediate layers retained in the build cache.

Build the fixed image, tag it as registry.iximiuz.com/my-app:v1.0.0, and push it:

docker push registry.iximiuz.com/my-app:v1.0.0

The original Dockerfile copies .netrc into an image layer. Deleting the file later doesn't remove it from that layer. A multi-stage build can keep the credentials out of the final image, but they may still leak through the build cache.

The safe approach is to use a Docker build secret, which makes .netrc available during go mod download without storing it in a layer.

Why deleting .netrc isn't enough

The original Dockerfile downloads the private Go module and then removes the credentials:

COPY .netrc /root/.netrc

RUN go mod download

RUN rm -f /root/.netrc

The file is gone from the running container, but the earlier COPY layer still contains it. Docker layers are immutable. A later RUN rm only records the deletion and doesn't change the layer that added the file.

Since the original Dockerfile has a single stage, that layer ends up in the pushed image. Anyone who can pull the image can inspect its layers and recover .netrc.

Why a multi-stage build may not be enough either

A Go app doesn't need the Go toolchain to run, so a multi-stage build is a natural improvement. Compile the app in one stage, then copy only the binary into the final image:

FROM golang:1.27 AS build

COPY corp-ca.crt /usr/local/share/ca-certificates/corp-ca.crt
RUN update-ca-certificates

ENV GOPRIVATE=git.corp

WORKDIR /src
COPY go.mod go.sum ./

COPY .netrc /root/.netrc
RUN go mod download

COPY *.go ./
RUN CGO_ENABLED=0 go build -o /my-app .

FROM gcr.io/distroless/static-debian13
COPY --from=build /my-app /my-app
CMD ["/my-app"]

The final image contains only the app binary. That solves the final-image leak. However, COPY .netrc /root/.netrc still creates a layer in the build stage, and BuildKit can retain that layer in its build cache.

This matters especially in CI, where builds often run on fresh machines. To speed up later builds, CI pipelines may export their cache to a container registry. With mode=max, the export also includes the layers of the intermediate build stages.

Here is how you can see the leak in a remote build cache.

Build and push the multi-stage image, exporting the cache to the same registry:

docker buildx build \
    --cache-to type=registry,ref=registry.iximiuz.com/cache:my-app,mode=max,image-manifest=true \
    --push \
    -t registry.iximiuz.com/my-app:multi-stage \
    ~/app/

The registry.iximiuz.com/my-app:multi-stage image doesn't contain .netrc, but the registry.iximiuz.com/cache:my-app artifact does. Although it's stored separately from the app image, its layers are still ordinary registry blobs.

You can inspect them using crane and jq:

REPO=registry.iximiuz.com/cache
CACHE=$REPO:my-app

for digest in $(crane manifest "$CACHE" | jq -r '.layers[].digest'); do
    crane blob "$REPO@$digest" | tar -xzO root/.netrc 2>/dev/null
done

The loop downloads each cache layer and tries to extract root/.netrc. Most layers don't contain it, so they produce no output. But the layer created by COPY .netrc /root/.netrc reveals the credentials:

machine git.corp
login installer
password <access-token>

Anyone with permission to pull registry.iximiuz.com/cache:my-app can do the same. Using the default mode=min would avoid exporting intermediate-stage layers, but it wouldn't protect the local cache, and relying on a particular cache-export setting is fragile.

Mount .netrc as a build secret

Docker can mount a secret into a single RUN step without including it in the resulting layer. Here, go mod download can read /root/.netrc, but neither the image nor an exported build cache stores the file.

1. Rewrite the Dockerfile

Replace ~/app/Dockerfile with:

FROM golang:1.27 AS build

COPY corp-ca.crt /usr/local/share/ca-certificates/corp-ca.crt
RUN update-ca-certificates

ENV GOPRIVATE=git.corp

WORKDIR /src
COPY go.mod go.sum ./

RUN --mount=type=secret,id=netrc,target=/root/.netrc,required=true \
    go mod download

COPY *.go ./
RUN CGO_ENABLED=0 go build -o /my-app .

FROM gcr.io/distroless/static-debian13
COPY --from=build /my-app /my-app
CMD ["/my-app"]

Instead of COPY .netrc, the RUN --mount=type=secret instruction temporarily mounts the file at the path where Go expects it. The downloaded modules can still be cached, but .netrc itself isn't written to a layer. required=true makes the build fail if the secret wasn't provided.

The other parts stay the same: GOPRIVATE=git.corp tells Go to fetch the private module directly, and corp-ca.crt lets the build trust the company's Git server. The CA certificate is public and is safe to copy into the image.

2. Build and push the fixed image

Pass .netrc to the build using --secret:

docker build \
    --secret id=netrc,src="$HOME/app/.netrc" \
    -t registry.iximiuz.com/my-app:v1.0.0 \
    ~/app/

docker push registry.iximiuz.com/my-app:v1.0.0

The id=netrc value must match in the build command and the Dockerfile. The src option points to the file on the host, and target specifies where it's mounted inside the build step.

To confirm that the remote cache is safe too, rerun the docker build --cache-to command with the fixed Dockerfile, pull the cache blobs, and scan them for secrets.