Vous pouvez définir une règle d'administration personnalisée sur les nœuds 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
Lisez la page Comprendre les contraintes pour en savoir plus sur ce qu'est une contrainte.
Lisez la Présentation du service des règles d'administration pour en savoir plus sur le fonctionnement des règles d'administration.
Exemple de hiérarchie
Dans le diagramme de hiérarchie des ressources ci-dessous, chaque nœud définit une règle d'administration personnalisée et définit s'il hérite de la règle de son nœud parent. Les formes colorées représentent les valeurs que la règle d'administration autorise ou refuse.
Une contrainte est une définition des comportements contrôlés par une règle d'administration. La contrainte dans l'exemple ci-dessus a un comportement par défaut qui autorise toutes les valeurs. Les nœuds situés en dessous définissent des règles personnalisées qui écrasent ce comportement 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 personnalisée n'est définie, le nœud héritera du comportement de contrainte par défaut. Si vous définissez une règle d'administration, votre règle personnalisée est utilisée à la place. Dans l'exemple ci-dessus, le nœud d'organisation définit une règle qui autorise le carré rouge et le cercle vert.
Les nœuds de ressources qui se trouvent dans la hiérarchie sous le nœud d'organisation sont évalués comme suit :
La ressource 1 définit une règle personnalisée qui définit
inheritFromParentsurTRUEet autorise le losange bleu. La règle du nœud d'organisation est héritée et fusionnée avec la règle personnalisée, et la règle en vigueur est évaluée pour autoriser le carré rouge, le cercle vert et le losange bleu.La ressource 2 définit une règle personnalisée qui définit
inheritFromParentsurTRUEet 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 personnalisée, et la règle en vigueur est évaluée pour autoriser uniquement le carré rouge.La ressource 3 définit une règle personnalisée qui définit
inheritFromParentsurFALSEet 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.La ressource 4 définit une règle personnalisée qui définit
inheritFromParentsurFALSEet inclut la valeurrestoreDefault. La règle du nœud d'organisation n'est pas héritée et le comportement de contrainte par défaut est utilisé. La règle en vigueur est évaluée pour tout autoriser.
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, un nœud de ressource hérite de son parent. Si le parent est le nœud d'organisation ou si le nœud parent n'a pas de règle d'administration, le comportement par défaut de la contrainte est appliqué.
Héritage
Un nœud de ressource pour lequel une règle d'administration est définie par défaut remplace toute règle définie par ses nœuds parents dans la hiérarchie. Toutefois, si un noeud de ressource a défini inheritFromParent = true, la règle en vigueur de la ressource parent 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 politiques sont fusionnées et aboutissent dans ce cas à une politique efficace qui refuse à la fois projects/123 et projects/456.
Interdire l'héritage
Si un noeud de hiérarchie de ressources a une règle qui inclut inheritFromParent = false, il n'hérite pas de la règle d'administration de son parent. Au lieu de cela, le nœud 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'un nœud enfant hérite de règles d'administration basées sur des contraintes de liste, les règles héritées sont fusionnées et réconciliées avec la règle d'administration du nœud. Dans l'évaluation des règles de liste, les valeurs DENY 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 le nœud parent ou enfant refuse la valeur. Il est préférable 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 dérivées de contraintes booléennes ne fusionnent pas et ne rapprochent pas les règles. Si une règle est spécifiée sur un nœud de ressource, cette valeur TRUE ou FALSE est utilisée pour déterminer la règle en vigueur. Exemple :
Un dossier définit
enforced: truepourconstraints/compute.disableSerialPortAccess.Un projet situé sous ce dossier définit
enforced: falsepourconstraints/compute.disableSerialPortAccess.
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'applique pas la contrainte pour ce projet.
Dérogation universelle
La définition d'une valeur DENY ALL universelle écrase tous les autres paramètres et refuse toutes les valeurs, y compris ALLOW ALL. Une valeur ALLOW ALL universelle autorise toute valeur non refusée par le nœud parent.
Rétablir la règle par défaut
Si vous invoquez RestoreDefault, la règle d'administration utilise le comportement par défaut de la contrainte pour ce nœud de hiérarchie de ressources. Les nœuds enfants héritent également de ce comportement.
