We are currently using Google Cloud and are concerned about the security risks of long-lived service account keys. Our security policy mandates key rotation every 90 days, but doing this manually for dozens of microservices in our Jenkins pipeline is becoming a nightmare. Is there a way to automate this within the Google Cloud ecosystem, or should we be moving toward "Keyless" authentication? How would that work with external CI/CD tools that are not hosted on GCP?
3 answers
The industry best practice is to move away from static keys entirely and use Workload Identity Federation. This allows your external CI/CD runners (like Jenkins or GitHub Actions) to swap a short-lived OIDC token for a temporary Google Cloud access token. This effectively makes your pipeline "keyless," as there are no JSON files to leak or rotate. If you must use keys, you can use a Cloud Function triggered by a Cloud Scheduler job to generate a new key, upload it to Secret Manager, and delete the old one. However, the Federation approach is significantly more secure and eliminates the management overhead you are currently facing.
Are you using HashiCorp Vault to manage these secrets, or are you relying solely on Google Cloud Secret Manager for your environment variables?
If you stay with static keys, ensure you are using Cloud Logging to track when they are used. This helps identify if an old key is still active somewhere it shouldn't be.
I totally agree with Jennifer. Setting up an alert for "Service Account Key Usage" in Cloud Monitoring was the only way we caught an old developer's laptop still hitting our API.
Steven, we are currently using Secret Manager. We found that by using the "GCP Secrets Engine" in Vault, we can generate dynamic service account keys that expire automatically after 24 hours. This means even if a key is intercepted, it becomes useless almost immediately. We then use the Google Cloud SDK within our pipeline to pull these dynamic credentials at runtime. It has completely transformed our "Identity and Access Management" strategy, moving us closer to a true Zero Trust architecture for our deployment workflows.