Lesson 10 · Identity, secrets & operations

KMS & secrets

The keys behind SOPS decryption and binauthz attestation — provisioned as code, granted to identities.

Your win: explain what Cloud KMS provides and read the two keyrings this repo creates in Terraform — the SOPS keys that decrypt secrets (C3) and the attestor keys that sign images (C5) — and how each ties to the Workload Identity of Lesson 9.

KMS — keys you never hold

Cloud KMS is GCP's key-management service: it creates and stores encryption keys, and performs encrypt/decrypt/sign operations for you — the key material never leaves KMS.¹ You don't get the key; you get permission to use it (an IAM role). That's the pattern: a KMS keyring holds keys, and IAM grants an identity the encrypter/decrypter/signer role.

Keyring #1 — SOPS decryption (Course 3)

Anchor — the SOPS keys Recall Course 3: secrets are SOPS-encrypted in git, and the Go app decrypts them in-process — with no key file, using its Workload Identity. Here's the key it uses. modules/kms-key/kms.tf creates a google_kms_key_ring (:21-25) and per-service google_kms_crypto_keys (:27), then grants each service's GSA the decrypter role (:87-96). Live keyring name is backend-services (live/kms-key/staging-manabie-online/terragrunt.hcl:69), with one key per stag-<service>. So the chain is: SOPS-encrypted file → mounted → app authenticates via Workload Identity (Lesson 9) → KMS decrypts because that GSA has the decrypter role → plaintext, in-process. Every link is Terraform.

Why this is the good way to do secrets The secret ciphertext is in git (reviewable, versioned); the key is in KMS (never exported); who can decrypt is an IAM grant to a Workload-Identity-backed GSA (no static credential anywhere). Rotate the key in KMS, revoke a grant, and you've changed access without touching the app. That's the SOPS-in-app story (C3) with its foundation finally visible.

Keyring #2 — binauthz attestation (Course 5)

Anchor — the attestor keys Course 5's binary authorization signs an attestation on every image. The signing key is a different keyring: binauthz-attestors, created by modules/binary-authorization-attestor — live at live/stag-manabie/binary-authorization-attestor/terragrunt.hcl:16-34 (attestor stag-deploy, key algorithm EC_SIGN_P256_SHA256, signer prod-build-bot — the CI bot from Lesson 9). So the "sign-and-create attestation" step in the build (C5) uses this KMS signing key, held by an identity provisioned here. Encryption (SOPS) and signing (binauthz) are both KMS, different keyrings, different grantees.

Cloud KMS

Keyrings, keys, symmetric encrypt/decrypt vs asymmetric sign, and IAM on keys.

→ cloud.google.com — Cloud KMS
→ In-repo: modules/kms-key/kms.tf, modules/binary-authorization-attestor/

Check yourself (from memory)

Q1. With Cloud KMS, an identity gets…

Key material never leaves KMS; you're granted an IAM role (encrypter/decrypter/signer) to use it.

Q2. The app decrypts a SOPS secret because its GSA has…

Ciphertext in git → app authenticates via Workload Identity (L9) → KMS decrypts because the GSA is granted decrypter on the `backend-services` key.

Q3. The binauthz signing key lives in the keyring…

A separate keyring for signing (attestor stag-deploy, signer prod-build-bot). backend-services is the SOPS decryption keyring.

KMS — the two keyrings and how each ties to Workload Identity.

recall, then click to reveal

CLOUD KMS = creates/stores keys + does encrypt/decrypt/sign; key material NEVER leaves KMS — you get an IAM ROLE to use it (keyring → keys → grant). TWO keyrings here: (1) SOPS decryption (C3) — modules/kms-key/kms.tf, keyring backend-services, per-service key, each service's GSA granted DECRYPTER (:87-96). Chain: ciphertext in git → app auth via Workload Identity (L9) → KMS decrypts (GSA has decrypter) → in-process plaintext, no key file. (2) binauthz signing (C5) — modules/binary-authorization-attestor, keyring binauthz-attestors, attestor stag-deploy, EC_SIGN_P256_SHA256, signer prod-build-bot. Encryption vs signing, two keyrings, two grantees — all Terraform.

Want to see how key rotation works, or why signing uses an asymmetric key while SOPS uses a symmetric one? Ask me.

1. GCP — Cloud KMS; in-repo modules/kms-key/kms.tf.