Google Secret Manager
Google Secret Manager centrally stores sensitive runtime values such as API tokens, database passwords, and certificates. It combines versioning with IAM so services can fetch only the secrets they actually need.
▶Architecture Diagram
🔗 RelationshipDashed line animations indicate the flow direction of data or requests
Applications need database passwords, API tokens, and certificates, but scattering them across repos and environment files makes exposure and change management painful. Secret rotation often turns into a redeployment problem.
When a database password leaked in a commit, rotating it meant redeploying dozens of services manually because each had its own copy in environment files or deployment configs. There was no central record of which services used which secrets, so even confirming the blast radius took hours. Secret Manager emerged to centralize secret storage so that rotation updates one place and every service picks up the new value on its next fetch.
Secret Manager stores secrets by name and version, and services fetch the version they need at runtime. IAM policies restrict access, and you can publish new versions without changing every consumer at once.
Secret Manager and Cloud KMS are often used together, but Secret Manager stores the readable secret values applications need while Cloud KMS manages encryption keys. If the problem is runtime injection, Secret Manager is central; if the problem is encryption operations, KMS is central.
A strong fit when runtimes need centrally managed passwords and tokens with controlled rotation. It does not replace systems for encrypting user data or managing key lifecycles.