# Secret Manager

> zop.dev writes generated credentials into Secret Manager from its modules (7 secrets per Cloud SQL instance, plus GKE platform secrets) and exposes direct secret CRUD through the provisioner's secret resource type. Access is scoped by namespace-level IAM bindings, and each secret version bills about 0.06 USD per month per replica location.

Source: https://zop.dev/integrations/provision/gcp/secret-manager
Updated: 2026-08-19

---

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

```text
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.