Introduction

If a Docker container runs on a Google Compute Engine VM, the recommended authentication method is usually not copying a JSON key into the image. The better approach is to attach a service account to the VM and let the application use Application Default Credentials from the metadata server.

Why Metadata-Based Authentication Is Preferred

A service-account key file is a long-lived credential. If you bake it into an image or mount it carelessly, you create extra rotation, leakage, and distribution problems. On GCE, the platform already exposes short-lived access tokens for the VM's attached service account through the metadata server.

Google client libraries know how to use that automatically through Application Default Credentials, often called ADC.

Recommended Setup on GCE

The secure pattern is:

1. Create or choose a dedicated service account.
2. Grant it only the roles the workload needs.
3. Attach that service account to the GCE VM.
4. Run the container without embedding key files.
5. Use Google client libraries normally inside the container.

From inside the container, the code usually does not need any special path configuration if it can reach the metadata server.

Example with Python

The Python client library can obtain credentials automatically.

1from google.cloud import storage
2
3client = storage.Client()
4buckets = list(client.list_buckets())
5
6for bucket in buckets:
7    print(bucket.name)

When this code runs inside a container on a properly configured GCE VM, storage.Client() can resolve credentials from ADC and talk to Google Cloud Storage without a JSON key file.

What Must Be True for This to Work

The VM needs a service account attached, and that service account needs the right IAM roles. The VM also needs API access scopes that do not block the required services, especially on older instance configurations.

Inside the container, outbound access to the metadata server must be available. In most ordinary Docker-on-GCE setups, that works automatically because the container shares the host network path to the metadata endpoint.

Avoid Putting Keys in the Image

A Dockerfile like this is the pattern you should avoid:

COPY service-account.json /app/service-account.json
ENV GOOGLE_APPLICATION_CREDENTIALS=/app/service-account.json

It works technically, but it turns the image into a secret distribution vehicle. Anyone with the image may gain access to that credential unless you wrap the whole process in very careful controls.

If you must use a key outside GCE or in local development, mount it at runtime instead of baking it into the image.

Local Development Versus Production

It is normal for local development to use a different authentication flow than production. For example, on a laptop you might set GOOGLE_APPLICATION_CREDENTIALS to a local file or use gcloud auth application-default login.

In production on GCE, prefer the attached service account and metadata-backed ADC. The application code can stay the same while the environment determines how credentials are resolved.

Debugging Credential Resolution

If authentication fails inside the container, check the environment in this order:

1. Does the VM have the expected service account attached?
2. Does that service account have the required IAM roles?
3. Can the container reach the metadata server?
4. Is some incorrect GOOGLE_APPLICATION_CREDENTIALS value overriding ADC?

A broken environment variable is a common cause of confusion because it can force the library to use a missing or invalid key file instead of the metadata-based identity.

Common Pitfalls

The most common mistake is storing a service-account key in the image for convenience. That creates an avoidable secret-management problem.

Another issue is granting the VM's service account broad project-wide roles when the container needs only one narrow permission set. Use least privilege.

Developers also sometimes forget that IAM roles and legacy API scopes both matter on some GCE setups. Correct IAM alone is not always enough if scopes are restricted.

Summary

• On GCE, prefer the VM's attached service account and Application Default Credentials.
• Do not bake JSON service-account keys into the Docker image.
• Let Google client libraries fetch short-lived credentials from the metadata server.
• Give the attached service account only the roles the workload actually needs.
• Use key files only for environments where metadata-based credentials are unavailable.