Cheat notes · Module 10 · Operate and grow

Secrets and identity

A five-minute review for when you have done this module and want it back in your head. Open the full module for the steps and the lab, or the full text to print.

The idea

The External Secrets setup from the Argo CD course, at fleet scale: the baseline renders a store into every product namespace on every cluster, production stores log in with workload identity instead of a password, and SSO groups mapped to projects limit each team to its own apps.

Remember

SecretStore per namespace: the baseline chart renders one in every product namespace (how to reach the vault), per environment. Only that namespace can use it, so there is no conditions list to keep. The platform owns it.
Same ExternalSecret as in Argo CD: the product team commits it next to the app; only secretStoreRef changes, to the namespaced store product-secrets.
Workload identity: on AKS, EKS and GKE the operator authenticates to the vault as a cloud identity bound to its ServiceAccount. No static credentials anywhere.
SSO and RBAC in Argo CD: admin.enabled: "false", logins through oidc.config, and policy.csv mapping a group to a role limited to checkout/*.
The fake provider keeps values in the SecretStore itself, so they are in Git. It exists to show the flow on kind; never use it for real secrets.

Pitfalls

An ExternalSecret for a key the store does not have: the ExternalSecret is Degraded and no Secret appears. The team's file was right; the platform adds the key. Make "add a secret to the store" a request with an owner.
Choosing secrets encrypted into Git for a fleet because they look simpler: key rotation across twenty clusters is where they stop being simple.

Commands

`kubectl --context kind-dev -n checkout get externalsecret,secret checkout-db`	`SecretSynced`, and the Secret it created
`kustomize build product-deployments/checkout/dev \| grep -A3 'kind: ExternalSecret'`	Check the ExternalSecret is in the render
`kubectl -n NS annotate externalsecret NAME force-sync=$(date +%s) --overwrite`	Ask External Secrets to sync now

An ExternalSecret

apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
  name: checkout-db
spec:
  refreshInterval: 1h
  secretStoreRef: { kind: SecretStore, name: product-secrets }
  target: { name: checkout-db }       # the Kubernetes Secret to create
  data:
    - secretKey: password
      remoteRef: { key: db-password }  # the key in the store

Test yourself

Answer in your head first, then open the answer.

What does an ExternalSecret in Git contain?

A reference: which key in which store becomes which Kubernetes Secret. No value.

What replaces static cloud credentials for the External Secrets operator?

Workload identity bound to its ServiceAccount.

How does team-checkout get access to only its own Applications in Argo CD?

SSO groups mapped to a role scoped to project checkout.

Where module 10 leaves you: checkout-dev has a Secret, checkout-db, created from a store the baseline rendered. Git holds only references, never values. You know how production swaps the stand-in store for a vault per environment, reached with workload identity.