Google Cloud services
18 / 24
Google Cloud

Encryption & Secrets — Cloud KMS & Secret Manager

Encrypt with managed keys, keep credentials out of code, and authenticate workloads without any key at all.

Everything in GCP is encrypted at rest by default with Google-managed keys. KMS is for when you need control over the key.

A vault that will not hand over the master key but will lock and unlock your own box on request — and a staff pass system so nobody carries a key to the building at all.

Key Concepts

1
    Google-managed (default)  nothing to do, no control
    CMEK                      your key in Cloud KMS, your rotation
                              and your ability to disable it
    CSEK / External           key outside Google entirely
2
CMEK is the one that matters for compliance. Because you can disable the key, you can make the data unreadable — which is the control auditors are really asking about.
3
Envelope encryption is the mechanism.
    KMS wraps a data encryption key (DEK)
      -> the DEK encrypts your data locally
      -> only the wrapped DEK is stored beside the ciphertext
4
Your data never travels to KMS; only a small key does.
5
Key rotation is scheduled, and old versions are retained so existing ciphertext stays readable. Destroying a version is deliberately slow — a 24-hour minimum — because it is irreversible.
6
Secret Manager stores the values.
    versions      every write is a new version; pin or use "latest"
    replication   automatic, or restricted to chosen regions for
                  data residency
    IAM per secret  Secret Manager Secret Accessor, scoped to one
7
Reference, do not copy. Cloud Run and Cloud Functions can mount a secret as a file or expose it as an environment variable resolved at deploy, so it never sits in your configuration or image.
8
The identity story is the strong part. A workload runs as a service account and calls APIs with a token the platform issues — no key file anywhere.
9
    on GKE     Workload Identity maps a Kubernetes SA to a Google SA
    on Cloud Run / GCE  the attached service account, automatically
    outside GCP  Workload Identity Federation exchanges a GitHub
                 or AWS token for a short-lived Google one
10
Service account key files are the thing to avoid. They are long-lived credentials that get committed, and Workload Identity Federation exists precisely so CI systems never need one. Organisation Policy can block their creation entirely.
11
What the interviewer is probing.1. "What does CMEK give you over Google-managed keys?" Probing: the control that matters for audit. Stalls: "Better encryption." Moves up: the same encryption, but you control rotation and can disable the key — which makes the data unreadable, and that is what auditors are asking about.
12
2. "Explain envelope encryption." Probing: the mechanism. Stalls: "KMS encrypts everything." Moves up: KMS wraps a data key, the data key encrypts the data locally, and only the wrapped key is stored — the data never travels to KMS.
13
3. "How do you stop service account keys existing at all?" Probing: the org policy. Stalls: "Tell people not to." Moves up: constraints/iam.disableServiceAccountKeyCreation, with Workload Identity Federation for external callers.
14
4. "What is the risk of pinning a secret to 'latest'?" Probing: versioning. Stalls: "None, it is current." Moves up: a bad version rolls out instantly everywhere; pinning a version makes the change deliberate.
Use cases:cloud-kmssecret-managercmekworkload-identityfederation