GCP Secret Manager
Secret Manager is GCP's service for storing, accessing, and managing sensitive configuration data — like API keys, database passwords, TLS certificates, and OAuth tokens. Instead of hardcoding secrets in application code or storing them in environment variable files, Secret Manager provides a secure, audited, centralized vault.
Imagine a company's safe deposit box. Sensitive documents (secrets) are locked inside the box. Only employees with the right key (IAM permissions) can open it. Every access is recorded (audit log). The safe is managed by a professional vault company (Google) — nobody has to build the safe themselves.
Why Not Store Secrets in Code?
| Method | Problem |
|---|---|
| Hardcoded in source code | Anyone with code access can see the secret. Git history exposes it forever. |
| In a .env file | File can be accidentally committed to Git or accessed by wrong person. |
| In VM environment variables | Exposed to anyone with SSH access or if the instance is compromised. |
| Secret Manager | Encrypted at rest and in transit. Access controlled by IAM. Every access is logged. |
Key Concepts
Secret
A secret is a named container for a piece of sensitive data. A secret by itself does not contain the actual value — versions do.
Secret Version
Each change to a secret's value creates a new version. Old versions are retained and can be accessed or rolled back. Versions have states: enabled, disabled, or destroyed.
Secret: "db-password" ├── Version 1: "OldPassword@2023" (disabled) ├── Version 2: "NewPassword@2024" (enabled ← current) └── Version 3: "RotatedPwd@2024" (enabled ← latest)
Creating and Using Secrets
Via Console
- Go to Security → Secret Manager
- Click Create Secret
- Enter a name (example:
db-password) - Enter the secret value
- Click Create Secret
Via Cloud Shell
# Create a secret echo -n "MySuperSecretPassword!" | \ gcloud secrets create db-password --data-file=- # Add a new version to an existing secret echo -n "NewSecretPassword@2024" | \ gcloud secrets versions add db-password --data-file=- # Access the latest version gcloud secrets versions access latest --secret=db-password # List all versions of a secret gcloud secrets versions list db-password
Access from Python Application
from google.cloud import secretmanager
def get_secret(project_id, secret_id, version="latest"):
client = secretmanager.SecretManagerServiceClient()
name = f"projects/{project_id}/secrets/{secret_id}/versions/{version}"
response = client.access_secret_version(request={"name": name})
return response.payload.data.decode("UTF-8")
# Usage
db_password = get_secret("my-project", "db-password")
print("Password retrieved securely") # Never print the actual password!
Secret Rotation
Regular secret rotation is a security best practice — replacing an old secret with a new one to limit exposure if a secret is compromised. Secret Manager supports automated rotation through Pub/Sub notifications.
Rotation Flow:
Cloud Scheduler (every 90 days)
│
▼
Cloud Function: rotate-db-password
│
├── 1. Generate new strong password
├── 2. Update database to accept new password
├── 3. Add new version to Secret Manager
└── 4. Disable old version
GCP Security Services Overview
Cloud Armor
Cloud Armor is GCP's Web Application Firewall (WAF) and DDoS protection service. It sits in front of the load balancer and blocks malicious traffic before it reaches the application.
Internet Traffic
│
▼
Cloud Armor (WAF rules applied here)
│
├── Block IPs from known bad actors
├── Block SQL injection attempts
├── Block XSS attack patterns
├── Allow only specific countries
└── Rate limiting (block if > 100 req/min per IP)
│
▼ (clean traffic only)
Load Balancer → Backend VMs
# Create a Cloud Armor security policy gcloud compute security-policies create my-waf-policy \ --description="Block known bad IPs and SQL injection" # Add a rule to block a specific IP range gcloud compute security-policies rules create 1000 \ --security-policy=my-waf-policy \ --action=deny-403 \ --src-ip-ranges=192.168.0.0/16 # Attach the policy to a backend service gcloud compute backend-services update my-backend \ --security-policy=my-waf-policy \ --global
VPC Service Controls
VPC Service Controls creates an invisible security perimeter around GCP services within a project. Even if someone steals IAM credentials, they cannot access data from outside the defined perimeter. This prevents data exfiltration.
Security Perimeter: "sensitive-data-perimeter" ┌────────────────────────────────────────────────────┐ │ Allowed inside perimeter: │ │ - Project: data-analytics │ │ - BigQuery dataset: customer_data │ │ - Cloud Storage: sensitive-bucket │ │ │ │ External access blocked ✗ │ │ (even with valid IAM credentials from outside) │ └────────────────────────────────────────────────────┘
Binary Authorization
Binary Authorization enforces that only trusted container images can be deployed to GKE. Every image must be cryptographically signed before deployment. Unsigned images are automatically rejected.
Developer builds container image
│
▼
Container image signed by authorized key
│
▼
Binary Authorization policy check at deploy time
│
Signed? ──Yes──▶ Deployment allowed ✓
│
No──▶ Deployment blocked ✗
Security Command Center
Security Command Center (SCC) is GCP's central dashboard for security findings across all projects. It continuously scans for vulnerabilities, misconfigurations, and threats like:
- Publicly exposed Cloud Storage buckets
- VMs with open firewall ports to the internet
- Accounts with Owner role that should not have it
- SQL injection vulnerabilities in web applications
- Cryptomining malware running on VMs
IAM Best Practices for Security
| Practice | Why It Matters |
|---|---|
| Use Principle of Least Privilege | Limits damage if an account is compromised |
| Avoid using the Owner role | Owner can delete everything — use specific roles |
| Prefer service accounts over user accounts for apps | Service accounts have limited scope by design |
| Enable 2-Step Verification for all users | Prevents unauthorized access even if password is stolen |
| Rotate service account keys regularly | Limits damage if a key is exposed |
| Use Secret Manager for all credentials | Prevents accidental exposure of passwords in code |
Key Takeaways
- Secret Manager securely stores API keys, passwords, and certificates with version history.
- Secrets are encrypted at rest and in transit — every access is audit-logged via IAM.
- Cloud Armor protects applications from DDoS attacks and web exploits like SQL injection.
- VPC Service Controls creates a perimeter to prevent data exfiltration even with stolen credentials.
- Binary Authorization ensures only signed container images run on GKE.
- Security Command Center provides a centralized view of security risks across all GCP resources.
