An OKE workload for the city’s 311 app needs a production API token. Developers propose checking a Kubernetes Secret YAML with the live token into the Helm chart repo. What is the correct production approach?
Select an answer to reveal the explanation.
Short Explanation
A Kubernetes Secret is a delivery tray inside the Pod; Vault is the locked cabinet that actually owns the password. Never photocopy the cabinet contents into git.
Full Explanation
Production API tokens for the city’s 311 OKE workload should live in OCI Vault as the source of truth. The workload authenticates with workload identity (or another documented principal), retrieves the current secret bundle, and may project those bytes into the process or a short-lived Kubernetes Secret generated at deploy/runtime—without committing live credentials to git. Vault retains rotation, access control, and audit; the cluster only consumes what it needs at runtime.
Committing a Kubernetes Secret YAML with the live token into the Helm chart repo fails because git history, forks, and CI logs become permanent leak channels, and Domain 2 Kubernetes objects are a delivery mechanism—not the only or preferred authoritative store on OKE. Embedding the token in a container image layer and relying on a private OCIR repository still exposes the secret to anyone who can pull the image and leaves rotation requiring rebuilds. Storing the token only in an Istio sidecar secret store because mesh is “required” for Vault access invents a dependency: service mesh is not a prerequisite for Vault retrieval with workload identity.
Exam caveat: a runtime-projected Kubernetes Secret can still be acceptable as a delivery tray if Vault remains authoritative and the chart never contains live production values. Operational check: scan the Helm repo and image history for plaintext tokens, confirm the ServiceAccount is bound by a workload-identity policy to read the Vault secret, and verify a Pod can retrieve or mount the current bundle after a Vault rotation without a git commit.