Comprendre le processus d'évaluation hiérarchique

Lorsque vous définissez une règle d'administration sur une ressource, tous les descendants de cette ressource héritent de la règle d'administration par défaut. Si vous définissez une règle d'administration sur votre ressource d'organisation, toutes les ressources enfants héritent de ces restrictions.

Vous pouvez définir la même règle d'administration avec une configuration différente sur les ressources enfants, ce qui écrasera ou fusionnera avec la règle héritée en fonction des règles d'évaluation de la hiérarchie.

Avant de commencer

Exemple de hiérarchie

Dans le diagramme de hiérarchie des ressources ci-dessous, chaque ressource définit une règle d'administration et définit si elle hérite de la règle de sa ressource parente. Les formes colorées représentent les valeurs que la règle d'administration autorise ou refuse.

Schéma de l'héritage

Une contrainte est une définition des comportements contrôlés par une règle d'administration. Dans l'exemple précédent, la contrainte représente la valeur par défaut de la contrainte, qui définit le comportement en l'absence de règle d'administration pour la contrainte. Dans cet exemple, la contrainte par défaut autorise toutes les valeurs . Les nœuds situés en dessous définissent des règles d'administration qui remplacent la valeur par défaut de la contrainte en autorisant ou en refusant des valeurs.

La règle en vigueur sur chaque nœud est évaluée en fonction des règles d'héritage. Si aucune règle d'administration n'est définie, la ressource hérite du comportement de contrainte par défaut. Si vous définissez une règle d'administration, votre règle est utilisée à la place. Dans l'exemple précédent, le nœud d'organisation définit une règle qui autorise le carré rouge et le cercle vert .

Les ressources qui se trouvent dans la hiérarchie sous le nœud d'organisation sont évaluées comme suit :

  1. La ressource 1 définit une règle qui définit inheritFromParent sur TRUE et autorise le losange bleu . La règle du nœud d'organisation est héritée et fusionnée avec la règle définie sur Ressource 1. La règle en vigueur est évaluée pour autoriser le carré rouge , le cercle vert et le losange bleu .

  2. La ressource 2 définit une règle qui définit inheritFromParent sur TRUE et refuse le cercle vert . Les valeurs de refus ont toujours la priorité lors de la réconciliation des règles. La règle du nœud d'organisation est héritée et fusionnée avec la règle définie sur la ressource 2. La règle en vigueur est évaluée pour n'autoriser que le carré rouge .

  3. La ressource 3 définit une règle qui définit inheritFromParent sur FALSE et autorise l'hexagone jaune . La règle du nœud d'organisation n'est pas héritée. Par conséquent, la règle en vigueur n'autorise que l'hexagone jaune .

  4. La ressource 4 définit une règle qui définit inheritFromParent sur FALSE et inclut la valeur restoreDefault. La règle du nœud d'organisation n'est pas héritée et le comportement de contrainte par défaut est utilisé. Par conséquent, la règle en vigueur autorise toutes les valeurs .

Règles d'évaluation hiérarchique

Les règles suivantes régissent la manière dont une règle d'administration est évaluée sur une ressource donnée. Vous devez disposer du rôle d'administrateur de règle d'administration pour définir cette dernière.

Aucune règle d'administration définie

Si vous ne définissez pas de règle d'administration, une ressource hérite de son ancêtre le plus proche pour lequel une règle est définie. Si aucune règle n'est définie dans la hiérarchie d'ancêtre, le comportement par défaut de la contrainte est appliqué.

Héritage

Une ressource dont la règle d'administration est définie par défaut remplace toute règle définie par ses ressources parentes dans la hiérarchie. Toutefois, si une ressource a défini inheritFromParent = true, la règle en vigueur de la ressource parente est héritée, fusionnée et réconciliée pour évaluer la règle en vigueur qui en résulte. Exemple :

  • Un dossier refuse la valeur projects/123.
  • Un projet situé sous ce dossier refuse la valeur projects/456.

Les deux règles sont fusionnées et aboutissent dans ce cas à une règle en vigueur qui refuse à la fois projects/123 et projects/456.

Hériter du comportement par défaut

Le comportement par défaut n'est jamais fusionné. Lorsqu'une règle est définie, elle remplace toujours tout comportement par défaut. Exemple :

  • constraints/iam.allowServiceAccountCredentialLifetimeExtension est défini par défaut sur DENY au niveau de l'organisation.
  • Pour cette contrainte, un projet directement sous cette organisation autorise la valeur SomeServiceAccount.

Étant donné que le comportement par défaut n'est jamais fusionné et toujours remplacé, la règle effective autorise SomeServiceAccount. En revanche, si la règle était explicitement définie sur DENY au niveau de l'organisation, la règle "La valeur DENY prévaut" s'appliquerait et la règle en vigueur serait DENY.

Interdire l'héritage

Si une ressource a une règle qui inclut inheritFromParent = false, elle n'hérite pas de la règle d'administration de son parent. Au lieu de cela, la ressource hérite du comportement par défaut de la contrainte, sauf si vous définissez une règle avec des valeurs autorisées ou refusées.

Réconcilier les conflits de règles

Lorsqu'une ressource hérite de règles d'administration, celles-ci sont fusionnées et réconciliées avec la règle d'administration de la ressource parente. Lors de l'évaluation des règles d'administration avec des règles de liste, les valeurs DENY ont toujours la priorité. Exemple :

  • Un dossier refuse la valeur projects/123.
  • Un projet situé sous ce dossier autorise la valeur projects/123.

Les règles sont fusionnées et la valeur DENY est prioritaire. La règle en vigueur refuse toutes les valeurs et détermine de la même manière si la ressource parente ou enfant refuse la valeur. Nous vous recommandons de ne pas inclure de valeur dans les listes autorisées et refusées. Cela peut rendre plus difficile la compréhension de vos règles.

Les règles d'administration avec des règles booléennes ne fusionnent pas et ne rapprochent pas les règles. Si une règle est spécifiée sur une ressource, la règle en vigueur est déterminée à l'aide de cette valeur TRUE ou FALSE. Exemple :

  • Un dossier définit constraints/iam.managed.disableServiceAccountCreation sur enforced: true.

  • Un projet situé sous ce dossier définit constraints/iam.managed.disableServiceAccountCreation sur enforced: false.

La valeur enforced: true définie sur le dossier est ignorée, car la valeur enforced: false est définie sur le projet lui-même. La règle d'administration n'est pas appliquée à ce projet.

Rétablir la règle par défaut

Si vous appelez RestoreDefault, la règle d'administration utilise le comportement par défaut de la contrainte pour cette ressource. Les ressources enfants héritent également de ce comportement.