This page describes the Identity and Access Management (IAM) roles you can use toconfigure Secret Manager. Roles limit a principal's ability toaccess resources. Always grant the minimum set of permissions required toperform a given task.

Secret Manager roles

Following are the IAM roles that are associated withSecret Manager. To learn how to grant, change, or revoke access to resources usingIAM roles, seeGranting, changing, and revoking access to resources.

Important: To use Secret Manager with workloads running on Compute Engine or Google Kubernetes Engine, the underlying instance or node must have thecloud-platform OAuth scope. Seeaccessing the Secret Manager API for more information.

Role	Permissions
Secret Manager Admin (roles/secretmanager.admin) Full access to administer Secret Manager resources. Lowest-level resources where you can grant this role: Secret	cloudkms.keyHandles.* cloudkms.keyHandles.create cloudkms.keyHandles.get cloudkms.keyHandles.list cloudkms.operations.get cloudkms.projects.showEffectiveAutokeyConfig resourcemanager.projects.get resourcemanager.projects.list secretmanager.* secretmanager.locations.get secretmanager.locations.list secretmanager.secrets.create secretmanager.secrets.createTagBinding secretmanager.secrets.delete secretmanager.secrets.deleteTagBinding secretmanager.secrets.get secretmanager.secrets.getIamPolicy secretmanager.secrets.list secretmanager.secrets.listEffectiveTags secretmanager.secrets.listTagBindings secretmanager.secrets.setIamPolicy secretmanager.secrets.update secretmanager.versions.access secretmanager.versions.add secretmanager.versions.destroy secretmanager.versions.disable secretmanager.versions.enable secretmanager.versions.get secretmanager.versions.list
Secret Manager Secret Accessor (roles/secretmanager.secretAccessor) Allows accessing the payload of secrets. Lowest-level resources where you can grant this role: Secret	resourcemanager.projects.get resourcemanager.projects.list secretmanager.versions.access
Secret Manager Secret Version Adder (roles/secretmanager.secretVersionAdder) Allows adding versions to existing secrets. Lowest-level resources where you can grant this role: Secret	resourcemanager.projects.get resourcemanager.projects.list secretmanager.versions.add
Secret Manager Secret Version Manager (roles/secretmanager.secretVersionManager) Allows creating and managing versions of existing secrets. Lowest-level resources where you can grant this role: Secret	resourcemanager.projects.get resourcemanager.projects.list secretmanager.versions.add secretmanager.versions.destroy secretmanager.versions.disable secretmanager.versions.enable secretmanager.versions.get secretmanager.versions.list
Secret Manager Viewer (roles/secretmanager.viewer) Allows viewing metadata of all Secret Manager resources Lowest-level resources where you can grant this role: Secret	resourcemanager.projects.get resourcemanager.projects.list secretmanager.locations.* secretmanager.locations.get secretmanager.locations.list secretmanager.secrets.get secretmanager.secrets.getIamPolicy secretmanager.secrets.list secretmanager.secrets.listEffectiveTags secretmanager.secrets.listTagBindings secretmanager.versions.get secretmanager.versions.list

Principle of least privilege

When you follow the principle of least privilege, you grant the minimum level ofaccess to resources required to perform a given task. For example, if aprincipal needs access to a single secret, don't give that principal access toother secrets or all secrets in the project or organization. If a principal onlyneeds to read a secret, don't grant that principal the ability to modify thesecret.

You can useIAM to grant IAMroles and permissions at the level of the Google Cloud secret, project,folder, or organization. Always apply permissions at the lowest level in theresource hierarchy.

The following table shows the effective capabilities of a service account, based on thelevel of the resource hierarchy where the Secret Manager Secret Accessor role(roles/secretmanager.secretAccessor) is granted.

Resource hierarchy	Capability
Secret	Access only that secret
Project	Access all secrets in the project
Folder	Access all secrets in all projects in the folder
Organization	Access all secrets in all projects in the organization

The roleroles/owner includes the`secretmanager.versions.access` permission, but theroles/editorandroles/viewer do not.

If a principal only needs to access a single secret's value, don't grant thatprincipal the ability to accessall secrets. For example, you can grant aservice account the Secret Manager Secret Accessor role(roles/secretmanager.secretAccessor) on a single secret.

If a principal only needs to manage a single secret, don't grant that principalthe ability to manage all secrets. For example, you can grant a serviceaccount the Secret Manager Admin role (roles/secretmanager.admin) on a single secret.

IAM conditions

IAM Conditionsallow you to define and enforce conditional, attribute-based access control forsome Google Cloud resources, including Secret Managerresources.

In Secret Manager, you can enforce conditional accessbased on the following attributes:

• Date/time attributes: Use to set expirable, scheduled, or limited-duration access to Secret Manager resources. For example, you could allow a user to access a secret until a specified date.
• Resource attributes: Use to configure conditional access based on a resource name, resource type, or resource service attributes. In Secret Manager, you can use attributes of secrets and secret versions to configure conditional access. For example, you can allow a user to manage secret versions only on secrets that begin with a specific prefix, or allow a user to access only a specific secret version.

For more information about IAM Conditions, see theConditions overview.

What's next

• Learn how tomanage access to secrets.
• Learn how to apply theprinciple of least privilegewhen managing Secret Manager resources bycreating and managing custom roles.
• Learn aboutIAM Conditions.