Propagation des modifications d'accès

Dans IAM, les modifications d'accès, telles que l'attribution d'un rôle ou le refus d'une autorisation, sont cohérentes à terme. Cela signifie que l'application des modifications d'accès prend du temps dans le système. En attendant, les modifications d’accès récentes risquent de ne pas être appliquées partout. Par exemple, les comptes principaux peuvent toujours utiliser un rôle récemment révoqué ou une autorisation récemment refusée. Ils peuvent également ne pas être en mesure d'utiliser un rôle récemment attribué ou une autorisation qui leur était refusée avant.

Le temps nécessaire à la modification d'un accès dépend de la manière dont vous effectuez la modification d'accès:

Méthode Examples Temps de propagation

Modifier une stratégie

Modifiez l'accès d'un compte principal en modifiant une stratégie d'autorisation ou de refus.

Lorsque vous modifiez des stratégies, vous ne pouvez pas dépasser les limites du nombre de comptes principaux autorisés dans une stratégie.

  • Vous modifiez la stratégie d'autorisation de votre organisation pour accorder à un compte principal le rôle d'administrateur de l'organisation (roles/resourcemanager.organizationAdmin).
  • Vous modifiez une stratégie de refus au niveau de l'organisation pour refuser à un compte principal l'autorisation cloudresourcemanager.googleapis.com/projects.setIamPolicy.
Généralement 2 minutes, potentiellement 7 minutes ou plus

Modifier l'appartenance à un groupe

Modifiez l'accès d'un compte principal en l'ajoutant ou en le supprimant d'un groupe Google inclus dans une stratégie d'autorisation ou de refus.

  • Vous disposez du groupe org-admins@example.com qui se voit attribuer le rôle d'administrateur de l'organisation sur votre organisation. Vous ajoutez un compte principal au groupe pour lui attribuer le rôle d'administrateur de l'organisation.
  • Vous disposez d'un groupe eng@example.com qui ne dispose pas de l'autorisation cloudresourcemanager.googleapis.com/projects.setIamPolicy au niveau de l'organisation. Vous ajoutez un compte principal au groupe pour lui refuser l'autorisation cloudresourcemanager.googleapis.com/projects.setIamPolicy.
Généralement plusieurs minutes, potentiellement plusieurs heures ou plus

Modifier l'appartenance à un groupe imbriqué

Modifiez l'accès d'un compte principal en l'ajoutant ou en le supprimant d'un groupe imbriqué dont le groupe parent est inclus dans une stratégie d'autorisation ou de refus.

  • Vous disposez du groupe admins@example.com qui se voit attribuer le rôle Lecteur de tags (roles/resourcemanager.tagViewer) sur votre organisation. Ce groupe est composée d'un certain nombre d'autres groupes, y compris org-admins@example.com. Ajoutez un compte principal au groupe org-admins@example.com pour lui attribuer le rôle de lecteur de tags.
  • Vous disposez d'un groupe eng@example.com qui ne dispose pas de l'autorisation cloudresourcemanager.googleapis.com/projects.setIamPolicy au niveau de l'organisation. Ce groupe est composée d'un certain nombre d'autres groupes, y compris eng-prod@example.com. Vous ajoutez un compte principal au groupe eng-prod@example.com pour lui refuser l'autorisation cloudresourcemanager.googleapis.com/projects.setIamPolicy.
Généralement plusieurs minutes, potentiellement plusieurs heures ou plus

Gardez également à l'esprit les informations suivantes sur la propagation des changements d'appartenance de groupe :

  • En général, l'ajout d'un compte principal à un groupe se propage plus rapidement que la suppression d'un compte principal d'un groupe.
  • En général, les modifications apportées aux appartenances à un groupe se propagent plus rapidement que les modifications apportées aux appartenances à un groupe imbriqué.

Vous pouvez utiliser ces estimations de temps de propagation pour vous guider lors des modifications d'accès de vos comptes principaux.