Secret Manager

Google Secret Manager keeps credentials out of source code and pod specs. zop.dev writes generated database and platform credentials here and manages secrets directly through its provisioner API.

Secrets from the API and from other modules

Secret Manager secrets created directly via the provisioner API, plus auto-generated entries from other modules (seven secrets per Cloud SQL instance, GKE platform secrets), with namespace-level IAM bindings so workloads can read only their own secrets.

Payloads you set, passwords GCP generates

secret payloads via the provisioner's secret resource type; Cloud SQL provisioning auto-generates the password into Secret Manager.

Workload Identity bindings decide who reads what

Namespace Workload Identity bindings control which service accounts may access which secrets.

Seven secrets per database, typed by no one

Provisioning a Cloud SQL instance writes 7 entries here automatically, and the GKE platform adds its own. Passwords are generated during provisioning and land directly in the store. No human sees them, so no terminal history, chat log, or sticky note ever holds one. Reading the Secret Manager inventory is effectively reading the platform’s provisioning history, which makes an entry that matches nothing in the platform worth investigating rather than ignoring. The secret resource type covers the deliberate remainder: API keys and third-party credentials managed through the same machinery instead of ad-hoc console entries.

Reads are scoped by namespace bindings

Access goes through namespace-level IAM bindings tied to Workload Identity: a workload reads the secrets bound to its namespace and nothing beyond. The failure this forecloses is the shared-vault anti-pattern, where every workload can technically read every credential and one SSRF bug turns a single compromised pod into a credential harvest. Here the bindings make the reachable set per-workload and auditable: “what could this pod have read” has a short, checkable answer.

Versions are immutable and each one bills

Secret Manager never edits a value. Every rotation adds an immutable version, and each active version bills about 0.06 USD per month per replica location, plus per-10,000 access operations. The money is trivial; the signal is not. Old versions that are never disabled remain readable forever, so a rotation that only adds a version has not actually revoked anything. What makes rotation real is completing the loop: add, migrate readers, then disable or destroy the old version. The version list is where to verify it happened.