Google Secret Manager Security: IAM, Rotation, Logs

Putting a secret into Google Cloud Secret Manager only helps if the identities that can read it, the way it is rotated and the record of who read it are all under control. In many projects the payload is safely encrypted while Secret Accessor is granted at project level to every service account, rotation is a calendar reminder and nobody has switched on the logs that show each read. This guide covers how to secure Secret Manager as a store for non-human credentials: IAM design, workload authentication, rotation with Pub/Sub, CMEK, version handling, and detection from audit logs. It is written for cloud platform, DevOps and security engineers who own Google Cloud projects that hold API keys, database passwords, tokens and certificates.

This is an independent guide from NHI Mgmt Group, based on Google Cloud's public documentation as of November 2026. It is not sponsored or reviewed by Google. Product features change, so confirm settings against Google Cloud's current documentation.

Key takeaways

Bind access at the secret, not the project. Every Secret Manager role can be granted on an individual secret; a project-level Secret Accessor binding lets one workload read every other workload's credentials.
Secret Manager signals rotation, it does not rotate. At next_rotation_time it publishes a SECRET_ROTATE message to Pub/Sub; your own subscriber must create the new credential and version.
Turn on Data Access logs for AccessSecretVersion. Reads are DATA_READ events, so without Data Access audit logging you cannot tell who read a secret.
Pin versions and disable before destroying. Google recommends referencing a specific version rather than latest, and disabling a version for a while before destroying it, so changes can be tested and rolled back.
Remove the key that guards the vault. Authenticate workloads with attached service accounts, GKE Workload Identity or Workload Identity Federation instead of exported service account keys.

The Secret Manager model

Secret Manager stores secrets (a resource holding metadata such as labels, annotations, replication settings and the IAM policy) and secret versions (the actual payload, each with its own ID). Versions can be enabled, disabled or destroyed, and a secret can be rolled back to an earlier known-good version. Data is encrypted with AES-256 before it is written to disk and protected with TLS in transit. For the discipline behind it, see the Secrets Management Guide.

Global secrets: the default service, reachable from any region, with either automatic replication (Google chooses the regions, billed as one location) or user-managed replication (you choose the regions, billed per location).
Regional secrets: keep data in one location for residency or sovereignty requirements.
Location policy: where workloads have location requirements, enforce them with the organisation policy constraint constraints/gcp.resourceLocations. See the Google Cloud Organization Policy Guide.

IAM design for secrets

Secret Manager has six predefined roles. The split between managing a secret and reading its value is the most important design lever.

Role	Role ID	Payload access	Typical holder
Secret Manager Admin	`roles/secretmanager.admin`	Yes, plus IAM policy changes	Small platform team, ideally via just in time access
Secret Manager Editor	`roles/secretmanager.editor`	No; manages secrets and versions, views but cannot change IAM	Infrastructure-as-code pipeline
Secret Manager Secret Accessor	`roles/secretmanager.secretAccessor`	Yes, read only	The one workload service account that uses the secret
Secret Manager Viewer	`roles/secretmanager.viewer`	No; metadata and IAM policies	Auditors, inventory tools
Secret Manager Secret Version Adder	`roles/secretmanager.secretVersionAdder`	No; adds versions	Rotation function
Secret Manager Secret Version Manager	`roles/secretmanager.secretVersionManager`	No; adds, enables, disables, destroys versions	Rotation function that also retires old versions

Lowest level wins: Google's guidance is to apply permissions at the lowest level of the resource hierarchy. Grant Secret Accessor on the secret itself, not on the project or folder.
Separate projects: keep applications and environments (staging, production) in different projects so their bindings and quotas are isolated.
IAM Conditions: use date and time attributes for expiring or scheduled access, and resource attributes to restrict management to secrets with a name prefix or to one specific version. Conditions on a name prefix are useful when many services share a project.
Separation of duties: the writer of a secret (pipeline or rotation function) should not be the reader. A rotation function needs Secret Version Adder, not Secret Accessor, unless it must read the old value.
Restrict who can be added: the organisation policy constraint constraints/iam.allowedPolicyMemberDomains limits which identities can appear in secret IAM policies, which blocks accidental grants to outside accounts.
Elevate admin access just in time: Secret Manager Admin and Project IAM Admin are good candidates for entitlements. See the Google Cloud Privileged Access Manager Guide.
Find over-broad bindings: Google recommends IAM Recommender to spot bindings wider than what is used.

Authenticating workloads to Secret Manager

The credential that unlocks the store is itself a secret, so the aim is to have none. Google's best practices list Application Default Credentials backed by the metadata server on Google Cloud compute, Workload Identity on GKE, and Workload Identity Federation for workloads on AWS or Azure, and recommend these over exported service account keys. See the Secrets Zero Problem Guide.

Where the workload runs	How it authenticates	What to avoid
Compute Engine, Cloud Run, Cloud Functions, App Engine	Attached user-managed service account through the metadata server	Default compute service account with broad project roles
GKE	Workload Identity, one Kubernetes service account per workload	Node service account shared by every pod
AWS, Azure, CI systems with OIDC	Workload Identity Federation with attribute conditions on the pool provider	JSON service account keys stored as CI variables
Developer laptops	`gcloud auth application-default login` with the developer's own identity	Downloading a production service account key

See the Google Cloud Service Account Keys Security Guide and the Cloud Workload Identity Guide.

How the value reaches the code

Google advises against passing secrets through the file system or environment variables where it can be avoided, and recommends calling the API directly through client libraries, REST or gRPC. Secrets written to disk are exactly what T1552.001 Credentials In Files describes, and environment variables tend to leak into crash dumps, debug pages and child processes. Some serverless integrations do mount secrets as files or variables; where you use them, keep the runtime identity narrow. If you sync secrets into Kubernetes Secrets (for example with the Secret Manager add-on for GKE), the copy inherits Kubernetes access controls and encryption, so check RBAC and etcd encryption before you rely on it.

Rotation with Pub/Sub

A rotation schedule has two fields. rotation_period sets the interval, with a minimum of one hour. next_rotation_time sets the next event and must be at least five minutes in the future. When the time arrives Secret Manager publishes SECRET_ROTATE to the topics configured on the secret (up to 10) and moves next_rotation_time forward. Failed deliveries are retried for up to seven days and then the rotation is cancelled; a rotation is skipped if an earlier one is still in flight. For the patterns, see the Secrets Rotation Runbook Template.

Create the service agent: gcloud beta services identity create --service "secretmanager.googleapis.com" --project "PROJECT_ID" creates service-PROJECT_NUMBER@gcp-sa-secretmanager.iam.gserviceaccount.com.
Allow it to publish: grant Pub/Sub Publisher (roles/pubsub.publisher) on each topic.
Attach topics and schedule: add the topic and rotation period to the secret.
Write the subscriber: a Cloud Run service or function that, on SECRET_ROTATE, creates a new credential at the source (database user password, third-party API key), adds a new version with Secret Version Adder, tests it, then retires the old credential at the source.
Roll out: update applications that pin versions through your normal release process, then disable the old version and destroy it only after a waiting period.
Handle other events: the same topics carry SECRET_CREATE, SECRET_UPDATE, SECRET_DELETE, SECRET_VERSION_ADD, SECRET_VERSION_ENABLE, SECRET_VERSION_DISABLE, SECRET_VERSION_DESTROY, SECRET_VERSION_DESTROY_SCHEDULED and TOPIC_CONFIGURED. Google warns new types may be added, so the subscriber should ignore unknown types safely.

Choosing a strategy: for credentials your own systems issue (database users, internal signing keys), run two valid credentials in overlap so applications can move to the new version before the old one is revoked. For third-party keys with a single slot, schedule the change in a maintenance window and keep the previous version disabled, not destroyed, for fast rollback. Where a workload can use federated identity instead of a static secret, removing the secret beats rotating it; see Secret Rotation vs Secret Elimination. If a rotation breaks something, the Secret Rotation Outage Troubleshooting Guide covers diagnosis.

Versions, expiry and deletion

Pin versions: Google recommends referencing a specific version number rather than latest, so a bad value is caught in release testing and rolled back by redeploying.
Disable first: disable versions before destroying them or deleting secrets, and wait long enough to confirm nothing depends on them. A disabled version can be re-enabled; a destroyed one cannot be recovered.
Expiration: avoid expiry on production secrets unless permanent deletion is intended. Use it for temporary environments, and consider time-based IAM Conditions instead.
Inventory: use Cloud Asset Inventory to find secrets across the organisation and check rotation settings, encryption and location.
Quotas: estimate peak access, including bursts from deployments and autoscaling, and request quota increases before they cause outages.

Encryption with CMEK

Secret Manager encrypts each version with its own data encryption key, which is wrapped by a key encryption key per replica. By default Google manages the key encryption key. With customer-managed encryption keys (CMEK) you hold that key in Cloud KMS. See the Cloud KMS and Cloud HSM Guide.

Question	Google default encryption	CMEK
Who controls the key encryption key	Google	You, in Cloud KMS
Key location	Managed by Google	Automatic replication: key in `global`; user-managed replication: one key per replica location (Cloud EKM keys only with user-managed)
Setup	None	Grant the Secret Manager service agent `roles/cloudkms.cryptoKeyEncrypterDecrypter` on the key
Key rotation effect	Transparent	New versions use the new primary key version; old versions stay readable while their key versions stay enabled
Main risk	Less customer control over the key	Disabling the key blocks all reads and writes; destroying it makes data unrecoverable

When to choose CMEK: when a regulator or contract requires customer control of keys, when you want a kill switch over a set of secrets, or when you need key access logs separate from the secret store. Default encryption is reasonable for most workloads; the access controls above matter more than the key choice.

Access logging and detection

Secret Manager writes audit logs under secretmanager.googleapis.com. Admin Activity logs are always written; reads of payloads are Data Access logs, which must be enabled. Google recommends enabling Data Access logs for AccessSecretVersion, ideally at folder or organisation level. See the Google Cloud Audit Logs and Log Sinks Guide.

Method	Log type	Detection idea
AccessSecretVersion	Data Access (DATA_READ)	A principal reading a secret it has never read before; reads from a human identity in production; reads from unusual IP ranges or outside a workload's normal schedule
SetIamPolicy	Admin Activity	New Secret Accessor bindings, especially to users, groups or external domains
AddSecretVersion	Admin Activity	New versions from any identity other than the pipeline or rotation function
DisableSecretVersion, DestroySecretVersion, DeleteSecret	Admin Activity	Destructive changes outside change windows
ListSecrets, GetSecret	Data Access (ADMIN_READ)	Enumeration bursts across many projects by one principal

Bulk reads from the store map to T1555.006 Cloud Secrets Management Stores. Add a VPC Service Controls perimeter around projects holding secrets so stolen credentials cannot be used from outside your network.

Metrics that show it is working:

Project-level accessor bindings: number of Secret Accessor bindings above secret level, trending to zero.
Readers per secret: median and maximum principals that can read each secret.
Rotation coverage: share of secrets with a rotation schedule and a working subscriber, and age of the oldest enabled version.
Logging coverage: share of projects with Data Access logs on for Secret Manager.
Key-based access: AccessSecretVersion calls made with service account keys rather than attached or federated identities.

Common failure patterns

Project-wide Secret Accessor. One compromised service gives an attacker every credential in the project.
A service account key to read the vault. The JSON key ends up in a repository or CI variable and becomes the real secret.
Rotation schedule without a subscriber. SECRET_ROTATE messages are published and nobody acts on them, giving a false sense of rotation.
Always reading latest. A bad version goes live everywhere at once with no tested rollback.
Destroying instead of disabling. An old version still in use is destroyed and the service fails with no way back.
No Data Access logs. After an incident nobody can say which secrets were read.

Framework mapping

Framework	Reference	Secret Manager control
NIST SP 800-53 Rev. 5	IA-5 Authenticator Management	Storage, rotation and retirement of credentials
NIST SP 800-53 Rev. 5	AC-6 Least Privilege	Secret-level bindings, separated reader and writer roles
NIST SP 800-53 Rev. 5	SC-12 Cryptographic Key Establishment and Management, SC-28 Protection of Information at Rest	Envelope encryption, CMEK
NIST SP 800-53 Rev. 5	AU-12 Audit Record Generation	Data Access logs for AccessSecretVersion
NIST CSF 2.0	PR.AA-01, PR.AA-05, PR.DS-01, PR.PS-04	Managed machine credentials, least privilege, data at rest protection, logging
ISO/IEC 27001:2022	Annex A 5.17 Authentication information, 8.24 Use of cryptography	Handling of secrets and key management
MITRE ATT&CK	T1555.006 Cloud Secrets Management Stores, T1552.001 Credentials In Files	Detect bulk reads; avoid secrets in files and variables

Practitioner checklist

Move every Secret Accessor binding from project or folder level to the individual secret.
Give each workload its own service account and authenticate with attached identities, Workload Identity or Workload Identity Federation, not keys.
Separate writer roles (Secret Version Adder or Manager) from reader roles.
Enable Data Access audit logs for Secret Manager at folder or organisation level and send them to the SIEM.
Configure rotation schedules only where a tested Pub/Sub subscriber exists, and monitor for missed rotations.
Pin secret versions in deployments and roll changes through the release process.
Disable versions before destroying them, and keep a waiting period.
Apply constraints/iam.allowedPolicyMemberDomains, constraints/gcp.resourceLocations and a VPC Service Controls perimeter.
Decide CMEK per data class and document who can disable the key.

Google Secret Manager Security Guide: IAM, Rotation and Access Logging