Securely store and manage API keys, passwords, certificates, and other sensitive data with automatic encryption and versioning.
What is Google Cloud Secret Manager?
Secret Manager is a fully managed service for storing and managing sensitive data. Instead of storing credentials in environment variables, config files, or source code, Secret Manager centralizes all secrets with automatic encryption, versioning, and audit logging. The service integrates seamlessly with Google Cloud services like Cloud Run, Cloud Functions, GKE, and Compute Engine via APIs, client libraries, or direct secret injection.
A core feature is automatic versioning. Each change to a secret creates a new version, while old versions are preserved for rollbacks. This enables secure secret rotation without downtime: new versions are deployed, old versions remain temporarily active for running processes, and after successful migration, old versions are disabled. Audit logging via Cloud Audit Logs records every secret access with timestamp, user, and service account for compliance and security monitoring.
Secret Manager offers flexible replication options: Automatic replication distributes secrets across all Google Cloud regions for high availability, while user-managed replication allows explicit region selection for data residency. IAM integration enables granular permissions per secret or secret version: a service can have read-only access to specific secrets, while secret rotation requires separate permissions. This implements the principle of least privilege at the secret level.
Common Use Cases
API Keys for External Services
Store API keys for services like Stripe, SendGrid, Twilio, or AWS in Secret Manager instead of environment variables. Cloud Run or Cloud Functions can load secrets at startup. For key rotation, create a new secret version, deploy the application, and disable the old version. Example: An e-commerce app stores Stripe API keys in Secret Manager to avoid key leaks in logs or Git.
Database Credentials for Cloud SQL
Cloud SQL Proxy uses IAM authentication, but for external databases or legacy systems, passwords are necessary. Secret Manager stores DB credentials securely. Applications load credentials at startup via the Secret Manager API. Password rotation occurs by generating new credentials in the DB, updating the secret, and restarting the application.
TLS Certificates and Private Keys
Store TLS certificates and private keys for load balancers, reverse proxies, or custom applications. Secret Manager supports binary secrets for certificate files. Certificate renewal creates a new secret version. Example: A GKE ingress loads TLS secrets from Secret Manager instead of Kubernetes secrets for centralized management.
Environment Variables for Cloud Run and Cloud Functions
Cloud Run and Cloud Functions can mount secrets as environment variables or volume mounts. Volume mounts are more secure as secrets don’t appear in logs. Secrets are automatically updated at container start, so secret rotation works without code changes. Example: A Cloud Function loads OAuth tokens from Secret Manager for API access.
OAuth Tokens and Service Account Keys
Store OAuth refresh tokens, service account keys, or API credentials for external cloud providers. Applications retrieve tokens from Secret Manager instead of storing them locally. In case of token compromise, it can be immediately disabled in Secret Manager without code deployment.
Best Practices
Use IAM for Granular Access Control
Grant Secret Manager permissions at the secret level, not at the project level. A service should only have read access to the secrets it needs. Use service accounts with minimal permissions. Example: A Cloud Function gets “roles/secretmanager.secretAccessor” only for its specific secret, not for all secrets in the project.
Implement Secret Rotation
Plan secret rotation from the start. Use Cloud Scheduler + Cloud Function for automatic rotation of DB passwords or API keys. Best practice is 90-day rotation for critical credentials. Old versions should be disabled after successful migration but not immediately deleted for rollback options.
Use User-Managed Replication for Compliance
For GDPR or other data residency requirements, use user-managed replication to explicitly store secrets only in EU regions. Automatic replication replicates globally, which can be problematic for some compliance requirements. User-managed replication provides full control over secret locations.
Monitor Secret Access with Audit Logs
Enable Cloud Audit Logs for Secret Manager and set alerts for abnormal access patterns. Unexpected secret access from new service accounts or unknown regions may indicate compromises. Use Log Analytics for trend analysis of secret usage.
Avoid Plain-Text Secrets in Logs
Configure applications so secrets never appear in logs. Use volume mounts instead of environment variables for Cloud Run, as environment variables are visible in “gcloud run describe”. Implement secret redaction in application logs.
Use Labels for Organization
Tag secrets with labels like “env=prod”, “service=api”, “type=db-password”. This facilitates IAM policies via label selectors and enables batch operations. Labels also help with cost tracking and secret inventory management.
Google Cloud Secret Manager Comparison
vs. AWS Secrets Manager: Both offer similar features (versioning, rotation, encryption). AWS Secrets Manager has native rotation support for RDS databases, while GCP rotation must be manually implemented. Pricing is similar, AWS charges slightly more per secret. GCP has simpler IAM integration with Google Cloud services.
vs. Azure Key Vault: Key Vault offers secrets, keys, and certificates in one service. Secret Manager focuses only on secrets, while Key Management Service manages separate keys. Azure offers Hardware Security Modules (HSM) for premium tier, GCP uses software encryption by default. Both meet enterprise compliance requirements.
vs. HashiCorp Vault: Vault is self-hosted with more features (dynamic secrets, PKI, encryption-as-a-service) but requires cluster management. Secret Manager is fully serverless without operational overhead. Vault is suitable for multi-cloud or on-premises, Secret Manager for Google Cloud-native workloads.
Integration with innFactory
As a Google Cloud partner, innFactory supports you in migrating from hard-coded secrets to Secret Manager, implementing secret rotation strategies, and integrating with CI/CD pipelines. We help with IAM setup, compliance audits, and secret lifecycle management for your Google Cloud workloads.
Contact us for consulting on Google Cloud Secret Manager and security best practices.
Available Tiers & Options
Standard
- Fully managed
- Automatic replication
- Audit logging integrated
- Costs per secret and access
- No on-premises option
Typical Use Cases
Technical Specifications
Frequently Asked Questions
What is Google Cloud Secret Manager?
Secret Manager is a fully managed service for securely storing, managing, and accessing sensitive data like API keys, passwords, and certificates. The service offers automatic versioning, audit logging, and integration with Google Cloud IAM for granular access controls.
How does Secret Manager differ from environment variables?
Environment variables are stored in plain text and visible in logs. Secret Manager automatically encrypts secrets, offers versioning, audit trails, and granular permissions. Secrets can be centrally rotated without redeploying applications. For production environments, Secret Manager is the secure standard.
How does secret versioning work?
Each change to a secret creates a new version. Old versions remain available for rollbacks. Applications can access specific versions or 'latest'. Disabled versions can no longer be retrieved but remain for audit purposes.
What does Secret Manager cost?
Secret Manager charges per active secret version (approx. $0.06 per month) and per 10,000 access operations (approx. $0.03). A secret with 5 active versions costs about $0.30 per month. Deleted secrets are automatically removed after 30 days and then incur no costs.
How do I automatically rotate secrets?
Secret Manager itself does not automatically rotate secrets. You must implement rotation via Cloud Functions, Cloud Scheduler, or external tools. Best practice is a Cloud Scheduler job that periodically generates new secrets, stores them in Secret Manager, and disables old versions.
Can I replicate secrets between regions?
Yes, Secret Manager offers automatic replication (across all regions) or user-managed replication (explicit region selection). User-managed replication enables data residency for compliance. Automatic replication is simpler, user-managed offers more control.
How do I integrate Secret Manager with Cloud Run?
Cloud Run can mount secrets as environment variables or as volume mounts. Volume mounts are more secure as secrets don't appear in logs. Define secrets in the Cloud Run service YAML or console, and Secret Manager delivers current values at container start.
What are best practices for secret naming?
Use consistent naming conventions like 'project-env-service-secrettype' (e.g., 'myapp-prod-api-stripe-key'). Avoid sensitive information in the secret name itself. Use labels for categorization (env=prod, service=api). This facilitates IAM policies and auditing.
Is Secret Manager GDPR compliant?
Yes, Secret Manager is available in EU regions and meets all GDPR requirements. With user-managed replication, you can ensure secrets are only stored in EU regions. Google Cloud offers comprehensive data protection controls and compliance certifications.
