Access control

Identity and Access Management (IAM) roles prescribe how you can use the Secret Manager API. Below is a list of each IAM role available for Secret Manager and the capabilities granted to that role.

ロール 役職 説明 権限 最下位のリソース
roles/secretmanager.admin Secret Manager 管理者 Secret Manager リソースを管理するための完全アクセス権。
  • resourcemanager.projects.get
  • resourcemanager.projects.list
  • secretmanager.*
シークレット
roles/secretmanager.secretAccessor Secret Manager のシークレット アクセサー シークレットのペイロードへのアクセスを許可します。
  • resourcemanager.projects.get
  • resourcemanager.projects.list
  • secretmanager.versions.access
シークレット
roles/secretmanager.secretVersionAdder Secret Manager のシークレット バージョンの追加 既存のシークレットにバージョンを追加できます。
  • resourcemanager.projects.get
  • resourcemanager.projects.list
  • secretmanager.versions.add
シークレット
roles/secretmanager.secretVersionManager Secret Manager のシークレット バージョンのマネージャー シークレットの作成と既存のシークレット バージョンの管理を許可します。
  • resourcemanager.projects.get
  • resourcemanager.projects.list
  • secretmanager.versions.add
  • secretmanager.versions.destroy
  • secretmanager.versions.disable
  • secretmanager.versions.enable
  • secretmanager.versions.get
  • secretmanager.versions.list
シークレット
roles/secretmanager.viewer Secret Manager 閲覧者 すべての Secret Manager リソースのメタデータを表示できます。
  • resourcemanager.projects.get
  • resourcemanager.projects.list
  • secretmanager.locations.*
  • secretmanager.secrets.get
  • secretmanager.secrets.getIamPolicy
  • secretmanager.secrets.list
  • secretmanager.versions.get
  • secretmanager.versions.list
シークレット

Principle of least privilege

When you follow the principle of least privilege, you grant the minimum level of access to resources required to perform a given task. For example, if a member needs access to a single secret, do not give that member access to other secrets or all secrets in the project or organization. If a member only needs to read a secret, don't grant that member the ability to modify the secret.

You can use IAM to grant IAM roles and permissions at the level of the Google Cloud secret, project, folder, or organization. Always apply permissions at the lowest level in the resource hierarchy.

This table shows the effective capabilities of a service account, based on the level 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

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

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

IAM conditions

IAM Conditions allow you to define and enforce conditional, attribute-based access control for some Google Cloud resources, including Secret Manager resources.

In Secret Manager, you can enforce conditional access based 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 the Conditions overview.

What's next?