Contrôle des accès avec IAM

Cette page décrit les rôles IAM (Identity and Access Management) que vous pouvez utiliser pour configurer Secret Manager. Les rôles limitent la capacité d'un compte principal à accéder aux ressources. Accordez toujours l'ensemble minimal d'autorisations requis pour pour effectuer une tâche donnée.

Rôles du Gestionnaire de secrets

Voici les rôles IAM associés Secret Manager. Pour savoir comment accorder, modifier ou révoquer l'accès aux ressources à l'aide de les rôles IAM, consultez Accorder, modifier et révoquer les accès à des ressources

Role Permissions

(roles/secretmanager.admin)

Full access to administer Secret Manager resources.

Lowest-level resources where you can grant this role:

  • Secret

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

(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

(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

(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

(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

Principe du moindre privilège

Lorsque vous suivez le principe du moindre privilège, vous accordez le niveau minimal d'accès aux ressources nécessaire pour effectuer une tâche donnée. Par exemple, si un principal a besoin d'accéder à un seul secret, ne lui accordez pas d'autres secrets ou tous les secrets du projet ou de l’organisation. Si un compte principal a uniquement besoin de lire un secret, ne lui accordez pas la possibilité de le modifier.

Utilisez IAM pour accorder des rôles et des autorisations IAM au niveau du secret, du projet, du dossier ou de l'organisation Google Cloud. Accordez toujours les autorisations au niveau le plus bas de la hiérarchie des ressources.

Le tableau suivant présente les capacités effectives d'un compte de service, en fonction du niveau de la hiérarchie des ressources auquel le rôle "Accesseur de secrets" de Secret Manager (roles/secretmanager.secretAccessor) est accordé.

Hiérarchie des ressources Capacité
Secret Accéder uniquement à ce secret
Projet Accéder à tous les secrets du projet
Dossier Accéder à tous les secrets de tous les projets du dossier
Organisation Accéder à tous les secrets de tous les projets de l'organisation

Le rôle roles/owner inclut l'autorisation "secretmanager.versions.access", contrairement aux rôles roles/editor et roles/viewer.

Si un compte principal a uniquement besoin d'accéder à la valeur d'un seul secret, ne lui accordez pas la possibilité d'accéder à tous les secrets. Par exemple, vous pouvez attribuer le rôle "Accesseur de secrets" de Secret Manager (roles/secretmanager.secretAccessor) à un compte de service sur un seul secret.

Si un compte principal ne doit gérer qu'un seul secret, ne lui accordez pas la possibilité de gérer tous les secrets. Par exemple, vous pouvez attribuer le rôle "Administrateur de Secret Manager" (roles/secretmanager.admin) à un compte de service sur un seul secret.

Conditions IAM

Conditions IAM vous permettent de définir et d'appliquer contrôle des accès conditionnel et basé sur des attributs pour certaines ressources Google Cloud, y compris Secret Manager, ressources.

Dans Secret Manager, vous pouvez appliquer un accès conditionnel en fonction des attributs suivants :

  • Attributs de date/heure: Permet de définir une date d'expiration, une planification ou une durée limitée aux ressources Secret Manager. Par exemple, vous pouvez autoriser un utilisateur à accéder à un secret jusqu'à une date donnée.
  • Attributs de ressource: Permet de configurer un accès conditionnel en fonction d'un nom de ressource, d'un type de ressource, ou les attributs de service de ressources. Dans Secret Manager, vous pouvez utiliser les attributs d'un secret et des versions d'un secret pour configurer un accès conditionnel. Pour Par exemple, vous pouvez autoriser un utilisateur à gérer les versions des secrets uniquement commencer par un préfixe spécifique, ou autoriser un utilisateur à accéder uniquement à un secret spécifique version.

Pour en savoir plus sur les conditions IAM, consultez Présentation des conditions

Étape suivante