Utiliser des règles d'administration personnalisées

Les règles d'administration Google Cloud vous offrent un contrôle centralisé et automatisé sur les ressources de votre organisation. En tant qu'administrateur des règles d'administration, vous pouvez définir une règle d'administration, c'est-à-dire un ensemble de restrictions appelées Contraintes qui s'appliquent aux ressources Google Cloud et aux descendants de ces ressources dans la Hiérarchie des ressources Google Cloud. Vous pouvez appliquer des règles d'administration au niveau d'une organisation, d'un dossier ou d'un projet.

Les règles d'administration fournissent des contraintes prédéfinies pour divers services Google Cloud. Toutefois, si vous souhaitez exercer un contrôle plus précis et personnalisable sur les champs spécifiques qui sont restreints par vos règles d'administration, vous pouvez également créer des règles d'administration personnalisées.

Avantages

Vous pouvez utiliser des règles d'organisation personnalisées qui font référence à des attributs IAM pour contrôler la façon dont vos règles d'autorisation peuvent être modifiées. Plus précisément, vous pouvez contrôler les éléments suivants :

  • Qui peut se voir attribuer des rôles
  • Qui peut voir ses rôles révoqués
  • Quels rôles peuvent être accordés
  • Quels rôles peuvent être révoqués

Par exemple, vous pouvez empêcher l'attribution de rôles contenant le mot admin aux comptes principaux dont l'adresse e-mail se termine par @gmail.com.

Héritage des règles

Par défaut, les règles d'administration sont héritées par les descendants des ressources sur lesquelles vous les appliquez. Par exemple, si vous appliquez une stratégie au niveau d'un dossier, Google Cloud l'applique à tous les projets du dossier. Pour mieux comprendre ce comportement et savoir comment le modifier, consultez la page Comprendre le processus d'évaluation hiérarchique.

Tarifs

Le service de règles d'administration, y compris les règles d'administration prédéfinies et personnalisées, est proposé gratuitement.

Limites

Les règles d'administration personnalisées en mode dry run qui font référence à des attributs IAM présentent certaines limites. Plus précisément, les journaux d'audit des cas de non-respect impliquant la méthode setiamPolicy peuvent ne pas comporter les champs suivants :

  • resourceName
  • serviceName
  • methodName

Avant de commencer

  • Assurez-vous de connaître votre ID d'organisation.

  • Si vous souhaitez tester des règles d'administration personnalisées qui font référence à des ressources IAM, créez un projet. Le test de ces règles d'administration dans un projet existant peut perturber les workflows de sécurité.

    1. In the Google Cloud console, go to the project selector page.

      Go to project selector

    2. Select or create a Google Cloud project.

Rôles requis

Pour obtenir les autorisations nécessaires pour gérer les règles d'administration, demandez à votre administrateur de vous accorder les rôles IAM suivants :

Pour en savoir plus sur l'attribution de rôles, consultez la page Gérer l'accès aux projets, aux dossiers et aux organisations.

Ces rôles prédéfinis contiennent les autorisations requises pour gérer les règles d'administration. Pour connaître les autorisations exactes requises, développez la section Autorisations requises :

Autorisations requises

Les autorisations suivantes sont requises pour gérer les règles d'administration :

  • orgpolicy.constraints.list
  • orgpolicy.policies.create
  • orgpolicy.policies.delete
  • orgpolicy.policies.list
  • orgpolicy.policies.update
  • orgpolicy.policy.get
  • orgpolicy.policy.set
  • resourcemanager.projects.setIamPolicy

Vous pouvez également obtenir ces autorisations avec des rôles personnalisés ou d'autres rôles prédéfinis.

Créer une contrainte personnalisée

Une contrainte personnalisée est définie dans un fichier YAML, qui spécifie les ressources, méthodes, conditions et actions compatibles avec le service sur lequel vous appliquez la règle d'administration. Les conditions de vos contraintes personnalisées sont définies à l'aide du langage CEL (Common Expression Language). Pour en savoir plus sur la création de conditions dans des contraintes personnalisées à l'aide du CEL, consultez la section CEL de la page Créer et gérer des contraintes personnalisées.

Pour créer un fichier YAML afin de définir une contrainte personnalisée :

name: organizations/ORG_ID/customConstraints/CONSTRAINT_NAME
resourceTypes: iam.googleapis.com/AllowPolicy
methodTypes:
  METHOD_TYPE
condition: "CONDITION"
actionType: ACTION
displayName: DISPLAY_NAME
description: DESCRIPTION

Remplacez les éléments suivants :

  • ORG_ID : ID de votre organisation (par exemple, 123456789).

  • CONSTRAINT_NAME : nom souhaité pour votre nouvelle contrainte personnalisée. Une contrainte personnalisée doit commencer par custom. et ne peut inclure que des lettres majuscules, minuscules ou des chiffres, comme par exemple custom.denyProjectIAMAdmin. La longueur maximale de ce champ est de 70 caractères, sans compter le préfixe, comme par exemple organizations/123456789/customConstraints/custom.

  • METHOD_TYPE: type d'action que vous souhaitez appliquer à la contrainte. Si vous souhaitez que la contrainte s'applique lorsqu'un utilisateur tente d'accorder un rôle à un compte principal, utilisez les valeurs suivantes :

    - CREATE
- UPDATE

    Si vous souhaitez que la contrainte s'applique lorsqu'un utilisateur tente de révoquer le rôle d'un compte principal, utilisez la valeur suivante :

    - REMOVE_GRANT

  • CONDITION : condition CEL écrite pour une représentation d'une ressource de service compatible. Ce champ ne doit pas comporter plus de 2 000 caractères. Consultez la section Attributs compatibles pour en savoir plus sur les attributs disponibles pour l'écriture de conditions. Par exemple, resource.bindings.exists(binding, RoleNameMatches(binding.role, ['roles/resourcemanager.projectIamAdmin'])).

  • ACTION : action à effectuer si la condition est remplie. Peut être défini sur ALLOW ou DENY.

  • DISPLAY_NAME : nom convivial de la contrainte. Ce champ ne doit pas comporter plus de 200 caractères.

  • DESCRIPTION : Facultatif. Description conviviale de la contrainte, qui sera affichée dans un message d'erreur en cas de non-respect de la règle. Ce champ ne doit pas comporter plus de 2 000 caractères.

Pour en savoir plus sur la création d'une contrainte personnalisée, consultez la page Définir des contraintes personnalisées.

Configurer une contrainte personnalisée

Après avoir créé une contrainte personnalisée à l'aide de Google Cloud CLI, vous devez la configurer pour la rendre disponible pour les règles d'administration de votre organisation. Pour configurer une contrainte personnalisée, utilisez la commande gcloud org-policies set-custom-constraint : 
gcloud org-policies set-custom-constraint CONSTRAINT_PATH
 Remplacez CONSTRAINT_PATH par le chemin d'accès complet à votre fichier de contrainte personnalisée. Par exemple, /home/user/customconstraint.yaml. Une fois terminée, vos contraintes personnalisées seront considérées comme des règles d'administration disponibles dans votre liste de règles d'administration Google Cloud. Pour vérifier que la contrainte personnalisée existe, utilisez la commande gcloud org-policies list-custom-constraints : 
gcloud org-policies list-custom-constraints --organization=ORGANIZATION_ID
 Remplacez ORGANIZATION_ID par l'ID de votre ressource d'organisation. Pour en savoir plus, consultez la page Afficher les règles d'administration.

Appliquer une règle d'administration personnalisée

Vous pouvez appliquer une contrainte booléenne en créant une règle d'administration qui la référence et en appliquant cette règle d'administration à une ressource Google Cloud.

Console

Pour appliquer une contrainte booléenne, procédez comme suit :

  1. Dans la console Google Cloud, accédez à la page Règles d'administration.

    Accéder à la page Règles d'administration

  2. Cliquez sur le sélecteur de projets en haut de la page.
  3. Dans le sélecteur de projets, choisissez le projet pour lequel vous souhaitez définir la règle d'administration.
  4. Sélectionnez votre contrainte dans la liste sur la page Règles d'administration. La page Détails de la règle associée à cette contrainte doit s'afficher.
  5. Pour configurer la règle d'administration pour cette ressource, cliquez sur Gérer la règle.
  6. Sur la page Modifier la stratégie, sélectionnez Remplacer la stratégie parente.
  7. Cliquez sur Ajouter une règle.
  8. Sous Application, indiquez si l'application de cette règle d'administration doit être activée ou désactivée.
  9. Pour rendre la règle d'administration conditionnelle sur un tag, cliquez sur Ajouter une condition. Notez que si vous ajoutez une règle conditionnelle à une règle d'administration, vous devez ajouter au moins une règle inconditionnelle, sinon la règle ne pourra pas être enregistrée. Pour en savoir plus, consultez Définir une règle d'administration avec des tags.
  10. S'il s'agit d'une contrainte personnalisée, vous pouvez cliquer sur Tester les modifications pour simuler l'effet de cette règle d'administration. Pour en savoir plus, consultez la section Tester les modifications apportées aux règles d'administration à l'aide de Policy Simulator.
  11. Pour finaliser et appliquer la règle d'administration, cliquez sur Définir la règle. La prise en compte de la règle peut prendre jusqu'à 15 minutes.

gcloud

Pour créer une règle d'administration qui applique une contrainte booléenne, créez un fichier YAML de règle qui référence la contrainte : 

      name: projects/PROJECT_ID/policies/CONSTRAINT_NAME
      spec:
        rules:
        - enforce: true

Remplacez les éléments suivants :

  • PROJECT_ID : projet sur lequel vous souhaitez appliquer votre contrainte.
  • CONSTRAINT_NAME : nom que vous avez défini pour la contrainte personnalisée Par exemple, custom.denyProjectIAMAdmin.

Pour appliquer la règle d'administration contenant la contrainte, exécutez la commande suivante : 

    gcloud org-policies set-policy POLICY_PATH

Remplacez POLICY_PATH par le chemin d'accès complet au fichier YAML de votre règle d'administration. La prise en compte de la règle peut prendre jusqu'à 15 minutes.

Tester la règle d'administration personnalisée

Vous pouvez éventuellement tester la règle d'administration en la définissant, puis en essayant d'effectuer une action qu'elle devrait empêcher.

Cette section explique comment tester la contrainte de règle d'administration suivante :

name: organizations/ORG_ID/customConstraints/custom.denyProjectIAMAdmin
resourceTypes: iam.googleapis.com/AllowPolicy
methodTypes:
  - CREATE
  - UPDATE
condition:
  "resource.bindings.exists(
    binding,
    RoleNameMatches(binding.role, ['roles/resourcemanager.projectIamAdmin']) &&
    binding.members.exists(member,
      MemberSubjectMatches(member, ['user:EMAIL_ADDRESS'])
    )
  )"
actionType: DENY
displayName: Do not allow EMAIL_ADDRESS to be granted the Project IAM Admin role.

Pour tester cette contrainte personnalisée, procédez comme suit :

  • Copiez la contrainte dans un fichier YAML et remplacez les valeurs suivantes :

    • ORG_ID : ID numérique de votre organisation Google Cloud.
    • MEMBER_EMAIL_ADDRESS: adresse e-mail du compte principal que vous souhaitez utiliser pour tester la contrainte personnalisée. Tant que la contrainte est active, ce compte principal ne pourra pas se voir attribuer le rôle Administrateur IAM du projet (roles/resourcemanager.projectIamAdmin) sur le projet pour lequel la contrainte s'applique.

  • Configurez la contrainte personnalisée et appliquez-la au projet que vous avez créé pour tester la contrainte de règle d'administration personnalisée.

  • Essayez d'attribuer le rôle Administrateur IAM du projet (roles/resourcemanager.projectIamAdmin) au compte principal dont vous avez inclus l'adresse e-mail dans la contrainte personnalisée. Avant d'exécuter la commande, remplacez les éléments suivants :

    • PROJECT_ID : ID du projet Google Cloud dans lequel vous avez appliqué la contrainte
    • EMAIL_ADDRESS : adresse e-mail du compte principal que vous avez spécifié lorsque vous avez créé la contrainte de règle d'administration.
gcloud projects add-iam-policy-binding PROJECT_ID \
    --member=user:EMAIL_ADDRESS --role=roles/resourcemanager.projectIamAdmin

Le résultat est le suivant :

Operation denied by custom org policies: ["customConstraints/custom.denyProjectIAMAdmin": "EMAIL_ADDRESS can't be granted the Project IAM Admin role."]

Attributs compatibles avec Identity and Access Management

IAM accepte l'attribut resources.bindings. Cet attribut est renvoyé pour toutes les méthodes qui modifient la stratégie d'autorisation d'une ressource. Toutes ces méthodes se terminent par setIamPolicy.

L'attribut resource.bindings a la structure suivante, où BINDINGS est un tableau de liaisons de rôle qui ont été modifiées lors de la modification d'une règle d'administration :

{
  "bindings": {
    BINDINGS
  }
}

Chaque liaison dans resource.bindings a la structure suivante, où ROLE est le nom du rôle dans la liaison de rôle et MEMBERS est une liste d'identifiants des comptes principaux qui ont été ajoutés ou supprimés de la liaison de rôle :

{
  "role": "ROLE"
  "members": {
    MEMBERS
  }
}

Pour connaître les formats que peuvent avoir les identifiants des comptes principaux, consultez la section Identifiants des comptes principaux.

Vous ne pouvez évaluer l'attribut resource.bindings et ses champs qu'à l'aide des fonctions compatibles. Les autres opérateurs et fonctions, tels que ==, !=, in, contains, startsWith et endsWith, ne sont pas acceptés.

Fonctions compatibles

Vous pouvez utiliser les fonctions CEL suivantes pour évaluer les champs role et members des ressources binding. Lorsque vous utilisez ces fonctions, vous pouvez également utiliser les opérateurs logiques && (and) et || (or) pour écrire des conditions multiparties.

Fonction Description
RoleNameMatches(
  role,
  roleNames: list
)   bool

Renvoie true si le rôle role correspond exactement à au moins l'un des rôles listés dans roleNames.

Paramètres
role : rôle à évaluer.
roleNames : liste des noms de rôles à comparer.
Exemple

Renvoie true si le role dans le binding spécifié est roles/storage.admin ou roles/compute.admin: 

RoleNameMatches(binding.role, ['roles/storage.admin', 'roles/compute.admin'])
RoleNameStartsWith(
  role,
  rolePrefixes: list
)   bool

Renvoie true si le rôle role commence par au moins l'une des chaînes répertoriées dans rolePrefixes.

Paramètres
role : rôle à évaluer.
rolePrefixes : liste de chaînes à faire correspondre au début du rôle.
Exemple

Renvoie true si le role dans le binding spécifié commence par roles/storage : 

RoleNameStartsWith(binding.role, ['roles/storage'])
RoleNameEndsWith(
  role,
  roleSuffixes: list
)   bool

Renvoie true si le rôle role se termine par au moins l'une des chaînes répertoriées dans roleSuffixes.

Paramètres
role : rôle à évaluer.
roleSuffixes : liste de chaînes à faire correspondre à la fin du rôle.
Exemple

Renvoie true si le role dans le binding spécifié se termine par .admin : 

RoleNameEndsWith(binding.role, ['.admin'])
RoleNameContains(
  role,
  roleSubstrings: list
)   bool

Renvoie true si le rôle role contient au moins l'une des chaînes répertoriées dans roleSubstrings.

Paramètres
role : rôle à évaluer.
roleSubstrings : liste de chaînes à faire correspondre à n'importe quelle partie du rôle.
Exemple

Renvoie true si le role dans le binding spécifié contient la chaîne admin : 

RoleNameContains(binding.role, ['admin'])
MemberSubjectMatches(
  member,
  memberNames: list
)   bool

Renvoie true si le membre member correspond entièrement à au moins l'un des membres répertoriés dans memberNames.

Si l'identifiant de member est une adresse e-mail, cette fonction n'évalue que cette adresse e-mail. Elle n'évalue aucun alias pour cette adresse e-mail.

Paramètres
member : membre à évaluer.
memberNames : liste des noms de membres à comparer.
Exemple

Renvoie true si le membre member est rosario@example.com : 

MemberSubjectMatches(member, ['user:rosario@example.com'])
MemberSubjectEndsWith(
  member,
  memberSuffixes: list
)   bool

Renvoie true si le membre member se termine par au moins l'une des chaînes répertoriées dans memberSuffixes.

Si l'identifiant de member est une adresse e-mail, cette fonction n'évalue que cette adresse e-mail. Elle n'évalue aucun alias pour cette adresse e-mail.

Paramètres
member : membre à évaluer.
memberSuffixes : liste de chaînes à faire correspondre à la fin du nom du membre.
Exemple

Renvoie true si le membre member se termine par @example.com : 

MemberSubjectEndsWith(member, ['@example.com'])

Exemples de règles d'administration personnalisées pour des cas d'utilisation courants

Le tableau suivant fournit la syntaxe de certaines règles d'organisation personnalisées qui pourraient vous être utiles.

Les exemples suivants utilisent les macros CEL all et exists. Pour en savoir plus sur ces macros, consultez la section Macros.

Description Syntaxe de la contrainte
Bloquer la possibilité d'attribuer un rôle spécifique 
name: organizations/ORG_ID/customConstraints/custom.denyRole
resourceTypes: iam.googleapis.com/AllowPolicy
methodTypes:
  - CREATE
  - UPDATE
condition:
"resource.bindings.exists(
    binding,
    RoleNameMatches(binding.role, ['ROLE'])
  )"
actionType: DENY
displayName: Do not allow the ROLE role to be granted
Autoriser uniquement l'attribution de rôles spécifiques. 
name: organizations/ORG_ID/customConstraints/custom.specificRolesOnly
resourceTypes: iam.googleapis.com/AllowPolicy
methodTypes:
  - CREATE
  - UPDATE
condition:
  "resource.bindings.all(
    binding,
    RoleNameMatches(binding.role, ['ROLE_1', 'ROLE_2'])
  )"
actionType: ALLOW
displayName: Only allow the ROLE_1 role and ROLE_2 role to be granted
Empêcher l'attribution de rôles commençant par roles/storage.. 
name: organizations/ORG_ID/customConstraints/custom.dontgrantStorageRoles
resourceTypes: iam.googleapis.com/AllowPolicy
methodTypes:
  - CREATE
  - UPDATE
condition:
  "resource.bindings.exists(
    binding,
    RoleNameStartsWith(binding.role, ['roles/storage.'])
  )"
actionType: DENY
displayName: Prevent roles that start with "roles/storage." from being granted
Empêcher la révocation des rôles dont le nom contient admin. 
name: organizations/ORG_ID/customConstraints/custom.dontRevokeAdminRoles
resourceTypes: iam.googleapis.com/AllowPolicy
methodTypes:
  - REMOVE_GRANT
condition:
  "resource.bindings.exists(
    binding,
    RoleNameContains(binding.role, ['admin'])
  )"
actionType: DENY
displayName: Prevent roles with "admin" in their names from being revoked
N'autoriser que des comptes principaux spécifiques à se voir attribuer des rôles. 
name: organizations/ORG_ID/customConstraints/custom.allowSpecificPrincipals
resourceTypes: iam.googleapis.com/AllowPolicy
methodTypes:
  - CREATE
  - UPDATE
condition:
  "resource.bindings.all(
    binding,
    binding.members.all(member,
      MemberSubjectMatches(member, ['user:USER','serviceAccount:SERVICE_ACCOUNT'])
    )
  )"
actionType: ALLOW
displayName: Only allow roles to be granted to USER and SERVICE_ACCOUNT
Empêcher la révocation de rôles pour des comptes principaux spécifiques 
name: organizations/ORG_ID/customConstraints/custom.denyRemovalOfSpecificPrincipals
resourceTypes: iam.googleapis.com/AllowPolicy
methodTypes:
  - REMOVE_GRANT
condition:
  "resource.bindings.exists(
    binding,
    binding.members.exists(member,
      MemberSubjectMatches(member, ['user:USER_1','user:USER_2'])
    )
  )"
actionType: DENY
displayName: Do not allow roles to be revoked from USER_1 or USER_2
Empêcher l'attribution de rôles aux comptes principaux dont l'adresse e-mail se termine par @gmail.com 
name: organizations/ORG_ID/customConstraints/custom.dontGrantToGmail
resourceTypes: iam.googleapis.com/AllowPolicy
methodTypes:
  - CREATE
  - UPDATE
condition:
  "resource.bindings.exists(
    binding,
    binding.members.exists(member,
      MemberSubjectEndsWith(member, ['@gmail.com'])
    )
  )"
actionType: DENY
displayName: Do not allow members whose email addresses end with "@gmail.com" to be granted roles
N'autoriser que des rôles spécifiques à être accordés, et uniquement à des comptes principaux spécifiques. 
name: organizations/ORG_ID/customConstraints/custom.allowSpecificRolesAndPrincipals
resourceTypes: iam.googleapis.com/AllowPolicy
methodTypes:
  - CREATE
  - UPDATE
condition:
  "resource.bindings.all(
    binding,
    RoleNameMatches(binding.role, ['ROLE_1', 'ROLE_2'])  &&
    binding.members.all(member,
      MemberSubjectMatches(member, ['serviceAccount:SERVICE_ACCOUNT', 'group:GROUP'])
    )
  )"
actionType: ALLOW
displayName: Only allow ROLE_1 and ROLE_2 to be granted to SERVICE_ACCOUNT and GROUP
Empêcher l'attribution de rôles Cloud Storage à allUsers et allAuthenticatedUsers. 
name: organizations/ORG_ID/customConstraints/custom.denyStorageRolesForPrincipalAllUsers
methodTypes:
  - CREATE
  - UPDATE
condition:
  "resource.bindings.exists(
    binding,
    RoleNameStartsWith(binding.role, ['roles/storage.']) &&
    binding.members.exists(member,
      MemberSubjectMatches(member, ['allUsers', 'allAuthenticatedUsers'])
    )
  )"
actionType: DENY
displayName: Do not allow storage roles to be granted to allUsers or allAuthenticatedUsers

Étape suivante