GCP Secret Manager中安全获取服务账号凭证的最佳实践咨询

First off, let’s start with the most critical GCP security best practice: avoid long-lived service account keys whenever you can. They introduce unnecessary attack surfaces, so prioritizing solutions that eliminate the need for these keys entirely should be your first goal. Here are your top options, ordered by security and maintainability:

1. Use Workload Identity (for apps running on GCP services) #

If your application is deployed on GCP-managed services like GKE, Cloud Run, Cloud Functions, or Compute Engine, Workload Identity is the gold standard. It lets you link a GCP service account directly to your workload, so your app automatically authenticates to GCP services (including Secret Manager) without needing to store or load any service account key files.

How to implement this: #

• GKE: Enable Workload Identity on your cluster, create a Kubernetes service account (KSA), bind it to a GCP service account (GSA) with permissions like roles/secretmanager.secretAccessor, and configure your deployment to use the KSA. Your app inherits the GSA’s permissions automatically—no GOOGLE_APPLICATION_CREDENTIALS required.
• Cloud Run: When deploying, specify the target service account with the --service-account flag. Cloud Run handles authentication for you, so your app can use the Secret Manager client library directly without key files.
• Compute Engine: Attach the service account to your VM instance at creation. The VM pulls credentials from the metadata server automatically, so the client library works out of the box.

This approach completely removes the need to manage service account keys, aligning perfectly with GCP’s security guidelines. For prod/dev separation, just use distinct GSAs for each environment.

2. Mount Secret Manager Secrets as Volumes (for GKE) #

If you’re on GKE and still need access to a service account key file (though Workload Identity is strongly preferred), use the Secret Manager CSI Driver to mount the secret directly as a file in your pod. This avoids manual curl downloads and ensures the secret is only accessible to the pod that needs it.

Steps to set this up: #

1. Install the Secret Manager CSI Driver on your GKE cluster.
2. Create a SecretProviderClass resource that references your service account secret in Secret Manager.
3. Update your pod deployment to use the CSI driver and mount the secret as a file at the path your app expects (e.g., /secrets/prod-service-account.json).
4. Set GOOGLE_APPLICATION_CREDENTIALS=/secrets/prod-service-account.json in your container’s environment variables.

The CSI driver handles secure secret retrieval at pod startup, so you don’t have to mess with curl commands or access tokens in your Dockerfile.

3. Simplified Curl + Script Approach (for non-GCP environments) #

If your app runs outside GCP (e.g., on-prem or another cloud) and you can’t use Workload Identity, you can streamline the curl method you mentioned. Using jq to parse the response and handle base64 decoding makes this far cleaner than manual bash work.

Example script (save as fetch-service-account.sh): #

#!/bin/bash

# Configure your GCP details
PROJECT_ID="your-project-id"
SECRET_ID="prod-service-account-key"
VERSION_ID="latest" # Use a specific version for stability if needed

# Fetch a short-lived access token (ensure gcloud is authenticated with a service account that can access the secret)
ACCESS_TOKEN=$(gcloud auth print-access-token)

# Retrieve the secret, decode it, and save to a temporary file
curl -s "https://secretmanager.googleapis.com/v1/projects/$PROJECT_ID/secrets/$SECRET_ID/versions/$VERSION_ID:access" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" | \
jq -r '.payload.data' | base64 --decode > /tmp/service-account.json

# Export the environment variable for your app
export GOOGLE_APPLICATION_CREDENTIALS="/tmp/service-account.json"

Tips for this approach: #

• Use a dedicated service account for this script with minimal permissions (only roles/secretmanager.secretAccessor for the target secret).
• In Docker, add this script to your image and run it as part of your entrypoint before starting the server.
• Avoid hardcoding gcloud credentials—use short-lived tokens or authenticate via Cloud Build workload identity if building images in GCP.

Key Takeaway #

Whenever possible, eliminate service account keys entirely using Workload Identity or attached service accounts for GCP resources. This is the most secure and low-maintenance path. If you must use a key, mounting it via the CSI driver (for GKE) or using a streamlined script (for non-GCP) are far better than ad-hoc curl commands in your Dockerfile.

内容的提问来源于stack exchange，提问作者Shobit Jain