Google Cloud Secret Manager vs Keeper Secrets Manager

Google Cloud Secret Manager

Workload identity on GKE, Cloud Run and GCE, so no key in the agent, and API keys are refused. Managed rotation only covers Cloud SQL; other rotation is a Pub/Sub notification you handle.

Keeper Secrets Manager

Each client device signs requests with its own key, is locked to an IP address by default and can be revoked alone, and secrets decrypt only on the client. The add-on has no public price, no request limits were found in the reviewed documentation, and a person must create the application and device in the vault.

Google Cloud Secret Manager

1. Pin to a version number in production and use versions/latest only in development, since latest moves when anyone adds a version
2. Grant roles/secretmanager.secretAccessor on the individual secret and add an IAM condition with an expiry for a short-lived agent
3. Turn on Data Access audit logs for secretmanager.googleapis.com if you need a record of each read
4. Read once per run and cache; accesses past 10,000 a month are metered
5. Use a regional secret (projects/*/locations/*/secrets/*) when the data must stay in one place, and note the higher write quota there

Keeper Secrets Manager

1. Ask the vault owner for a new device on an application that holds only the folders the task needs. Use the Base64 configuration, not the first one-time token
2. Run commands under ksm exec so secrets arrive as environment variables and stay out of the model's context
3. Expect HTTP 403 with {"error":"throttled"} under load. The Python SDK retries five times from 11 seconds, so allow for long waits
4. A device is locked to the IP address it first connects from unless it was created with --unlock-ip. Check this before running from a dynamic address
5. Leave --auto-approve off on the MCP server. It removes confirmation for deletes and for unmasking values