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?

MethodProblem
Hardcoded in source codeAnyone with code access can see the secret. Git history exposes it forever.
In a .env fileFile can be accidentally committed to Git or accessed by wrong person.
In VM environment variablesExposed to anyone with SSH access or if the instance is compromised.
Secret ManagerEncrypted 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

  1. Go to Security → Secret Manager
  2. Click Create Secret
  3. Enter a name (example: db-password)
  4. Enter the secret value
  5. 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

PracticeWhy It Matters
Use Principle of Least PrivilegeLimits damage if an account is compromised
Avoid using the Owner roleOwner can delete everything — use specific roles
Prefer service accounts over user accounts for appsService accounts have limited scope by design
Enable 2-Step Verification for all usersPrevents unauthorized access even if password is stolen
Rotate service account keys regularlyLimits damage if a key is exposed
Use Secret Manager for all credentialsPrevents 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.

Leave a Comment