Cloud Secrets Management — AWS Secrets Manager, Azure Key Vault & GCP Secret Manager

In this tutorial, you'll learn about Cloud Secrets Management. We cover key concepts, practical examples, and best practices to help you understand and apply this topic effectively.

Cloud secrets management stores, rotates, and audits access to database credentials, API keys, and service account tokens using managed services like AWS Secrets Manager, Azure Key Vault, and GCP Secret Manager.

What You Will Learn

How to migrate secrets from configuration files to cloud secret stores, configure automatic rotation, enforce fine-grained access controls, and audit every secret retrieval.

Why It Matters

Hardcoded secrets are the most common Cloud Security finding. A single leaked API key in a GitHub Repository can lead to account compromise. Cloud secret managers encrypt secrets at rest and in transit and rotate them automatically.

Real-World Use

DodaZIP stores its database credentials in AWS Secrets Manager with automatic rotation every 30 days. Applications retrieve secrets at startup using the IAM role attached to the EC2 instance. No developer ever sees a production database password.

Secrets Management Flow

flowchart LR
  App[Application] -->|1. Request secret| SM[Secrets Manager]
  SM -->|2. Check IAM permissions| IAM["IAM / Access Policy"]
  IAM -->|3. Allow| SM
  SM -->|4. Decrypt with KMS| KMS[KMS Key]
  KMS -->|5. Plaintext| SM
  SM -->|6. Return secret| App
  
  subgraph Rotation
    Lambda[Rotation Lambda]
    SM -->|Invoke| Lambda
    Lambda -->|Update| SM
  end
  
  style SM fill:#f90,color:#fff

AWS Secrets Manager

AWS Secrets Manager rotates secrets automatically and integrates with RDS, Redshift, and DocumentDB.

# Create a secret for an RDS database
aws secretsmanager create-secret \
  --name prod/rds/orders-db \
  --description "Production orders database credentials" \
  --secret-string '{"username":"dbadmin","password":"TempPass123!"}' \
  --kms-key-id alias/aws/secretsmanager

# Configure automatic rotation every 30 days
aws secretsmanager rotate-secret \
  --secret-id prod/rds/orders-db \
  --rotation-rules '{"AutomaticallyAfterDays": 30}'

# Retrieve the secret from an application
aws secretsmanager get-secret-value \
  --secret-id prod/rds/orders-db \
  --query SecretString --output text
# Output:
# {"username":"dbadmin","password":"RotatedPass456!"}

# List secrets with rotation status
aws secretsmanager list-secrets \
  --query 'SecretList[*].[Name,LastRotatedDate,RotationEnabled]' \
  --output table
# Output:
# ------------------------------------------------
# | prod/rds/orders-db | 2026-06-24 | True      |
# | dev/rds/test-db    | 2026-05-20 | True      |
# | prod/api/external   | None       | False     |
# ------------------------------------------------

Azure Key Vault

Key Vault stores secrets, keys, and certificates with fine-grained access policies.

# Create a Key Vault for secrets
az keyvault create \
  --name prod-secrets \
  --resource-group prod-rg \
  --sku Standard \
  --enable-rbac-authorization true \
  --soft-delete-retention-days 90

# Add a secret
az keyvault secret set \
  --vault-name prod-secrets \
  --name db-password \
  --value "Sup3rS3cr3t!"

# Set an access policy for an application
az keyvault set-policy \
  --name prod-secrets \
  --spn <app-client-id> \
  --secret-permissions get list

# Retrieve the secret
az keyvault secret show \
  --vault-name prod-secrets \
  --name db-password \
  --query value --output tsv
# Output:
# Sup3rS3cr3t!

GCP Secret Manager

Secret Manager stores secrets with version history and IAM-based access control.

# Enable Secret Manager API
gcloud services enable secretmanager.googleapis.com

# Create a secret
gcloud secrets create prod-db-password \
  --replication-policy automatic \
  --labels env=prod,service=orders

# Add a secret version
echo -n "MyS3cr3tP@ss" | \
  gcloud secrets versions add prod-db-password \
  --data-file=-

# Grant access to a service account
gcloud secrets add-iam-policy-binding prod-db-password \
  --member "serviceAccount:orders-sa@my-project.iam.gserviceaccount.com" \
  --role "roles/secretmanager.secretAccessor"

# Access the latest version
gcloud secrets versions access latest \
  --secret=prod-db-password
# Output:
# MyS3cr3tP@ss

Secret Rotation Strategies

Automated rotation requires a rotation function. AWS provides pre-built Lambda functions for RDS. Azure and GCP use custom logic or scheduled workflows.

Common Mistakes

1. Hardcoding secrets in application code: Secrets in code end up in version control, logs, and error messages. Always use a managed secret store.
2. No automatic rotation: Secrets that never rotate are valuable targets. Rotate every 30-90 days depending on sensitivity.
3. Overly permissive secret access: Granting a service account access to all secrets in a vault violates Least Privilege. Scope access to individual secrets.
4. Storing secrets in plaintext during deployment: Deployment pipelines that pass secrets as environment variables expose them. Use CI/CD secret variables or fetch from the cloud at runtime.
5. Not enabling audit logging: Without audit logs, you cannot detect unauthorized secret access. Enable CloudTrail, Azure Monitor, or GCP Audit Logs for all secret operations.

Practice Questions

1. What is the difference between AWS Secrets Manager and Parameter Store?
2. How does Azure Key Vault enforce access control with RBAC?
3. What GCP Secret Manager feature tracks changes to secrets over time?
4. Why should automatic rotation be enabled for production secrets?
5. How can you audit secret access across all three cloud providers?

Challenge

Implement a secrets management Strategy for a three-tier application. Store the database password in AWS Secrets Manager, the API key in Azure Key Vault, and the service account key in GCP Secret Manager. Configure automatic rotation for the database password. Write application code (pseudo or real) that retrieves each secret at startup using the environment's IAM role. Verify retrieval works and audit the access logs.

FAQ