SecuritySecurity

Part of the Cloud knowledge base — GCP deep dive. Complements DevOps Roadmap.

Overview

Google Cloud security is built on defense in depth and secure by default. Data is encrypted at rest and in transit automatically, IAM governs every API call, and a layered set of services lets you add stronger controls where you need them: managed keys (Cloud KMS), secrets (Secret Manager), context-aware access to apps (Identity-Aware Proxy), a security posture dashboard (Security Command Center), edge protection (Cloud Armor), data-exfiltration boundaries (VPC Service Controls), and supply-chain enforcement (Binary Authorization).

This page focuses on the data-protection and workload-security layer that sits on top of IAM and networking (covered in earlier pages).

Fundamentals

Default encryption at rest and in transit

• At rest: All customer data is encrypted by default with AES-256, using Google-managed keys via envelope encryption — no configuration needed. Data is chunked; each chunk gets its own data encryption key (DEK), and DEKs are wrapped by key encryption keys (KEKs) managed by Google’s central KMS.
• In transit: Traffic between Google data centers is encrypted automatically; traffic to Google Cloud services is protected with TLS. Application Layer Transport Security (ALTS) secures internal service-to-service calls.

You only add KMS when you need control over the keys (rotation policy, region residency, revocation, audit).

Cloud KMS — key rings, keys, CMEK, envelope encryption

Cloud KMS is a managed service to create and use cryptographic keys.

• Key ring — a regional (or global/multi-region) container that groups keys. Location is fixed at creation.
• Key (CryptoKey) — has a purpose (symmetric encrypt/decrypt, asymmetric sign, asymmetric decrypt, MAC) and one or more versions. Rotation creates a new primary version.
• Protection level — SOFTWARE, HSM (FIPS 140-2 Level 3, via Cloud HSM), or EXTERNAL (Cloud EKM, keys held by an external partner).

CMEK (Customer-Managed Encryption Keys) replaces the Google-managed KEK with a KMS key you own for a service (BigQuery, GCS, Compute disks, Pub/Sub, etc.). You keep control over rotation and can disable/destroy the key to render data unreadable. CSEK (Customer-Supplied) goes further — you provide raw key bytes and Google never stores them — but is rarely needed.

Envelope encryption is the pattern: encrypt data locally with a DEK, then call KMS to encrypt (wrap) that DEK with a KEK. Store the wrapped DEK next to the ciphertext; decrypt by asking KMS to unwrap the DEK. This keeps large payloads off the KMS request path while centralizing key control.

# Create a key ring and a rotating symmetric key
gcloud kms keyrings create app-keyring --location=us-central1

gcloud kms keys create data-key \
  --location=us-central1 --keyring=app-keyring \
  --purpose=encryption \
  --rotation-period=90d --next-rotation-time=$(date -u -d '+90 days' +%Y-%m-%dT%H:%M:%SZ)

# Encrypt / decrypt a file directly (small payloads)
gcloud kms encrypt \
  --location=us-central1 --keyring=app-keyring --key=data-key \
  --plaintext-file=secret.txt --ciphertext-file=secret.enc

gcloud kms decrypt \
  --location=us-central1 --keyring=app-keyring --key=data-key \
  --ciphertext-file=secret.enc --plaintext-file=-

Secret Manager

Secret Manager stores API keys, passwords, certificates, and other secrets with versioning, IAM access control, audit logging, optional CMEK, automatic replication policy (automatic or user-managed regions), and rotation notifications via Pub/Sub.

# Create a secret and add a version
printf 's3cr3t-value' | gcloud secrets create db-password \
  --replication-policy=automatic --data-file=-

# Grant a service account read access to just this secret
gcloud secrets add-iam-policy-binding db-password \
  --member="serviceAccount:app@PROJECT.iam.gserviceaccount.com" \
  --role="roles/secretmanager.secretAccessor"

# Access the latest version at runtime
gcloud secrets versions access latest --secret=db-password

Cloud Run, GKE, and Compute can mount secrets as files or inject them as environment variables, so apps never embed credentials.

Identity-Aware Proxy (IAP)

IAP enforces context-aware access control in front of applications and VMs — a zero-trust model where access is authenticated and authorized per-request instead of relying on network position (VPN).

• Sits in front of HTTPS load balancers, App Engine, and Cloud Run; also fronts SSH/RDP to VMs (TCP forwarding) so you can drop public IPs and bastion hosts.
• Checks the user’s Google identity + IAM role (roles/iap.httpsResourceAccessor) and, with Access Context Manager, device/location conditions.

# Tunnel SSH to a private VM through IAP (no external IP needed)
gcloud compute ssh my-vm --zone=us-central1-a --tunnel-through-iap

Security Command Center (SCC)

SCC is the central security and risk dashboard — asset inventory, misconfiguration and vulnerability findings, and threat detection.

Use Standard for baseline visibility; Premium/Enterprise for active threat detection, compliance mapping, and attack-path analysis.

Cloud Armor (WAF / DDoS)

Cloud Armor is Google’s WAF and DDoS protection at the global load-balancer edge.

• Security policies = ordered rules matching on IP/CIDR, geo, or preconfigured WAF rules (OWASP ModSecurity CRS for SQLi, XSS, LFI, RCE).
• Rate limiting (throttle / ban) per client for abuse and bot control.
• Adaptive Protection — ML-based detection of L7 DDoS attacks with suggested rules.
• Managed Protection Plus adds always-on DDoS response and attack analytics.

gcloud compute security-policies create web-waf --description="Edge WAF"
# Block a country and enable the SQLi preconfigured rule
gcloud compute security-policies rules create 1000 \
  --security-policy=web-waf \
  --expression="origin.region_code == 'KP'" --action=deny-403
gcloud compute security-policies rules create 2000 \
  --security-policy=web-waf \
  --expression="evaluatePreconfiguredExpr('sqli-v33-stable')" --action=deny-403

VPC Service Controls

VPC Service Controls (VPC-SC) create a service perimeter around managed Google APIs (BigQuery, GCS, etc.) to prevent data exfiltration. Even a caller with valid IAM credentials cannot move data outside the perimeter — mitigating stolen-credential and insider exfiltration.

• Perimeter — a set of projects whose protected services can only be reached from inside.
• Access levels (via Access Context Manager) — conditions (IP range, device, identity) that grant entry.
• Ingress/egress rules — controlled exceptions for legitimate cross-perimeter access.
• Run in dry-run mode first to log violations without blocking.

Binary Authorization

Binary Authorization is a deploy-time gate for GKE and Cloud Run that ensures only trusted, attested container images run. A policy requires images to be signed by trusted attestors (e.g., built by your CI, scanned, passed tests). Unsigned or unverified images are blocked. Combined with Artifact Analysis vulnerability scanning, it enforces a verifiable software supply chain.

Assured Workloads (brief)

Assured Workloads applies compliance controls (data residency, personnel access, key management) to a folder of projects to meet regimes like FedRAMP, CJIS, IL4/IL5, HIPAA, and regional sovereignty requirements — without you manually wiring each control. Useful for regulated/public-sector and sovereign-cloud workloads.

Key Concepts

CMEK vs CSEK vs Google-managed keys

Secret Manager vs KMS

They solve different problems: KMS manages keys used to encrypt/decrypt/sign; Secret Manager stores secret values (and uses encryption under the hood). Store a password in Secret Manager; use KMS to CMEK-encrypt a database. Don’t put raw application secrets directly in KMS.

Zero-trust access

IAP + Access Context Manager + VPC-SC together implement BeyondCorp zero-trust: identity- and context-aware access to apps, no reliance on network location, and a data perimeter around services. This replaces the old “trusted internal network + VPN” model.

Best Practices

1. Rely on default encryption; add CMEK only where compliance demands control. Rationale: everything is already AES-256 encrypted at rest — CMEK adds operational overhead and should be reserved for data needing rotation/revocation guarantees.

2. Store every secret in Secret Manager, never in code, images, or env files in git. Rationale: hard-coded credentials are the top leak vector; Secret Manager adds versioning, IAM, audit, and rotation.

3. Grant secretAccessor per-secret to per-workload service accounts. Rationale: least privilege limits a compromised workload to the exact secrets it needs, not the whole project.

4. Enable automatic key rotation in KMS. Rationale: periodic rotation limits the blast radius of a compromised key version and is required by many compliance frameworks.

5. Separate duties around KMS with distinct IAM roles. Rationale: split cryptoKeyEncrypterDecrypter (use) from cloudkms.admin (manage) so no single identity can both use and destroy keys.

6. Use envelope encryption for large application data. Rationale: encrypt bulk data locally with DEKs and only call KMS to wrap/unwrap them — avoids KMS rate limits and keeps payloads off the key-service path.

7. Front internal apps and SSH/RDP with IAP; remove public IPs. Rationale: context-aware, per-request auth via IAP eliminates bastions and internet-exposed management ports.

8. Turn on Security Command Center and triage findings continuously. Rationale: SCC surfaces misconfigurations and threats across the org; Premium adds active threat and attack-path detection for high-risk environments.

9. Put a Cloud Armor policy with the OWASP CRS in front of public HTTPS load balancers. Rationale: edge WAF + DDoS protection blocks common web attacks and volumetric floods before they reach your backends.

10. Add rate limiting and Adaptive Protection in Cloud Armor. Rationale: throttling and ML-based L7 DDoS detection defend against abuse and application-layer floods that simple ACLs miss.

11. Wrap sensitive data services in a VPC Service Controls perimeter (dry-run first). Rationale: prevents exfiltration even with valid stolen credentials; dry-run validates rules before you risk blocking legitimate traffic.

12. Enforce Binary Authorization on GKE/Cloud Run production. Rationale: only signed, attested, scanned images deploy — closing the supply-chain gap where a malicious or vulnerable image reaches prod.

13. Enable Artifact Analysis vulnerability scanning on all registries. Rationale: continuous CVE scanning of images feeds Binary Authorization and surfaces vulnerable dependencies before deploy.

14. Enable data-access audit logs for sensitive services. Rationale: admin-activity logs are on by default, but data-access logs (who read what) are opt-in and essential for investigations and compliance.

15. Use Assured Workloads for regulated/sovereign workloads. Rationale: it enforces residency, personnel, and key controls as guardrails rather than relying on manual, error-prone configuration.

16. Apply organization policy constraints as guardrails. Rationale: org policies (e.g., disable service account key creation, restrict resource locations, require CMEK, disable external IPs) prevent risky configurations org-wide before they happen.

References

• Encryption at rest in Google Cloud
• Encryption in transit in Google Cloud
• Cloud KMS documentation
• Customer-managed encryption keys (CMEK)
• Envelope encryption
• Secret Manager documentation
• Identity-Aware Proxy documentation
• BeyondCorp / zero trust
• Security Command Center documentation
• Cloud Armor documentation
• VPC Service Controls documentation
• Binary Authorization documentation
• Artifact Analysis (vulnerability scanning)
• Assured Workloads documentation
• Organization policy constraints