Exemple 1 : Autoriser les stratégies enfants à remplacer uniquement les valeurs de balise Exemple 2 : Ajouter de nouvelles valeurs aux balises héritées Exemple 3 : Supprimer des valeurs de balises héritées Exemple 4 : Restreindre les modifications dans les politiques enfants Exemple 5 : Conflits avec les opérateurs de contrôle enfants Exemple 6 : Conflits liés à l'ajout de valeurs au même niveau de hiérarchie

Exemples d'héritages

Ces exemples illustrent le fonctionnement de l'héritage de politiques. Ils indiquent comment les politiques de balises parentes et enfants sont fusionnées en une politique de balises effective pour un compte.

Les exemples supposent que vous disposez de la structure d'organisation présentée dans le diagramme suivant.

Une organisation dotée d'une racine, de deux OUs et de plusieurs comptes.

Exemples

Exemple 1 : Autoriser les stratégies enfants à remplacer uniquement les valeurs de balise
Exemple 2 : Ajouter de nouvelles valeurs aux balises héritées
Exemple 3 : Supprimer des valeurs de balises héritées
Exemple 4 : Restreindre les modifications dans les politiques enfants
Exemple 5 : Conflits avec les opérateurs de contrôle enfants
Exemple 6 : Conflits liés à l'ajout de valeurs au même niveau de hiérarchie

Exemple 1 : Autoriser les stratégies enfants à remplacer uniquement les valeurs de balise

La politique de balises suivante définit la clé de balise CostCenter et deux valeurs admises : Development et Support. Si vous l'attachez à la racine de l'organisation, la politique de balises s'applique à tous les comptes de l'organisation.

Politique A : politique d'identifications attachée à la racine de l'organisation


{
    "tags": {
        "costcenter": {
            "tag_key": {
                "@@assign": "CostCenter"
            },
            "tag_value": {
                "@@assign": [
                    "Development",
                    "Support"
                ]
            }
        }
    }
}

Supposons que vous souhaitiez que les OU1 utilisateurs utilisent une valeur de balise différente pour une clé et que vous souhaitiez appliquer la politique de balise pour des types de ressources spécifiques. Étant donné que la politique A ne spécifie pas les opérateurs de contrôle enfants qui sont autorisés, tous les opérateurs sont autorisés. Vous pouvez utiliser l'@@assignopérateur et créer une politique de balises telle que la suivante à laquelle vous pouvez vous associerOU1.

Stratégie B — politique des OU1 balises


{
    "tags": {
        "costcenter": {
            "tag_key": {
                "@@assign": "CostCenter"
            },
            "tag_value": {
                "@@assign": [
                    "Sandbox"
                ]
            },
            "enforced_for": {
                "@@assign": [
                    "redshift:*",
                    "dynamodb:table"
                ]
            }
        }
    }
}

La spécification de l'opérateur @@assign pour la balise entraîne le résultat suivant lorsque la politique A et la politique B fusionnent pour constituer la politique de balises effective d'un compte :

La politique B remplace les deux valeurs de balise spécifiées dans la politique parente (la politique A). Le résultat est que Sandbox est la seule valeur conforme pour la clé de balise CostCenter.
L'ajout de enforced_for indique que la balise CostCenter doit être la valeur de balise spécifiée sur toutes les ressources Amazon Redshift et les tables Amazon DynamoDB.

Comme le montre le diagramme, OU1 inclut deux comptes : 111111111111 et 222222222222.

Stratégie de balise effective obtenue pour les comptes 111111111111 et 222222222222

Note

Vous ne pouvez pas utiliser directement le contenu d'une politique effective affichée comme contenu d'une nouvelle politique. La syntaxe n'inclut pas les opérateurs nécessaires pour contrôler la fusion avec d'autres politiques enfants et parentes. L'affichage d'une politique effective n'a pour but que de comprendre les résultats de la fusion.


{
    "tags": {
        "costcenter": {
            "tag_key": "CostCenter",
            "tag_value": [
                "Sandbox"
            ],
            "enforced_for": [
                "redshift:*",
                "dynamodb:table"
            ]
        }
    }
}

Exemple 2 : Ajouter de nouvelles valeurs aux balises héritées

Dans certains cas, vous souhaitez que tous les comptes de votre organisation spécifient une clé de balise avec une courte liste de valeurs admises. Pour les comptes d'une unité d'organisation, vous souhaiterez peut-être autoriser une valeur supplémentaire que seuls ces comptes peuvent spécifier lors de la création de ressources. Cet exemple spécifie la procédure à suivre à l'aide de l'opérateur @@append. L'opérateur @@append est une fonction avancée.

Comme pour l'exemple 1, cet exemple commence par la politique A comme politique de balises attachée à la racine de l'organisation.

Politique A : politique d'identifications attachée à la racine de l'organisation


{
    "tags": {
        "costcenter": {
            "tag_key": {
                "@@assign": "CostCenter"
            },
            "tag_value": {
                "@@assign": [
                    "Development",
                    "Support"
                ]
            }
        }
    }
}

Pour cet exemple, attachez la politique C àOU2. La différence dans cet exemple est que l'utilisation de l'opérateur @@append dans la politique C ajoute des valeurs à la liste des valeurs admises ainsi que la règle enforced_for plutôt que d'écraser la liste.

Stratégie C — politique de OU2 balises pour l'ajout de valeurs


{
    "tags": {
        "costcenter": {
            "tag_key": {
                "@@assign": "CostCenter"
            },
            "tag_value": {
                "@@append": [
                    "Marketing"
                ]
            },
            "enforced_for": {
                "@@append": [
                    "redshift:*",
                    "dynamodb:table"
                ]
            }
        }
    }
}

L'association de la politique C à OU2 a les effets suivants lorsque la politique A et la politique C fusionnent pour former la politique de balises effective pour un compte :

Étant donné que la politique C inclut l'opérateur @@append, elle permet d'ajouter des valeurs à la liste des valeurs de balise admises spécifiées dans la politique A (plutôt que d'écraser la liste).
Comme dans la politique B, l'ajout de enforced_for indique que la balise CostCenter doit être utilisée comme valeur de balise spécifiée sur toutes les ressources Amazon Redshift et les tables Amazon DynamoDB. L'écrasement (@@assign) et l'ajout (@@append) ont le même effet si la politique parente n'inclut pas d'opérateur de contrôle enfant qui limite les valeurs qu'une politique enfant peut spécifier.

Comme le montre le schéma, OU2 inclut un compte : 999999999999. La politique A et la politique C fusionnent pour créer la politique de balises effective du compte 999999999999.

Stratégie de balise effective pour le compte 999999999999

Note


{
    "tags": {
        "costcenter": {
            "tag_key": "CostCenter",
            "tag_value": [
                "Development",
                "Support",
                "Marketing"
            ],
            "enforced_for": [
                "redshift:*",
                "dynamodb:table"
            ]
        }
    }
}

Exemple 3 : Supprimer des valeurs de balises héritées

Dans certains cas, la politique de balises attachée à l'organisation peut définir plus de valeurs de balise que vous ne souhaitez qu'un compte en utilise. Cet exemple décrit comment réviser une politique de balise à l'aide de l'opérateur @@remove. @@remove est une fonction avancée.

Comme pour les autres exemples, cet exemple commence par la politique A comme politique de balises attachée à la racine de l'organisation.

Politique A : politique d'identifications attachée à la racine de l'organisation


{
    "tags": {
        "costcenter": {
            "tag_key": {
                "@@assign": "CostCenter"
            },
            "tag_value": {
                "@@assign": [
                    "Development",
                    "Support"
                ]
            }
        }
    }
}

Pour cet exemple, attachez la politique D au compte 999999999999.

Politique D : politique d'identifications attachée au compte 999999999999 pour supprimer des valeurs


{
    "tags": {
        "costcenter": {
            "tag_key": {
                "@@assign": "CostCenter"
            },
            "tag_value": {
                "@@remove": [
                    "Development",
                    "Marketing"
                ],
                "enforced_for": {
                    "@@remove": [
                        "redshift:*",
                        "dynamodb:table"
                    ]
                }
            }
        }
    }
}

L'attachement de la politique D au compte 999999999999 a les effets suivants lorsque la politique A, la politique C et la politique D fusionnent pour constituer la politique de balises effective :

En supposant que vous ayez suivi tous les exemples précédents, les politiques B, C et C sont des politiques secondaires de A. La politique B est uniquement attachée àOU1, elle n'a donc aucun effet sur le compte 9999999999999.
Pour le compte 9999999999999, la seule valeur admise pour la clé de balise CostCenter est Support.
La conformité n'est pas appliquée pour la clé de balise CostCenter.

Nouvelle stratégie de balise effective pour le compte 999999999999

Note


{
    "tags": {
        "costcenter": {
            "tag_key": "CostCenter",
            "tag_value": [
                "Support"
            ]
        }
    }
}

Si vous ajoutez ultérieurement d'autres comptesOU2, leurs politiques en matière de balises en vigueur seront différentes de celles du compte 999999999999. En effet, la politique D plus restrictive n'est attachée qu'au niveau du compte et pas à l'unité d'organisation.

Exemple 4 : Restreindre les modifications dans les politiques enfants

Vous souhaiterez peut-être, dans certains cas, restreindre les modifications apportées dans les politiques enfants. Cet exemple décrit la procédure à suivre à l'aide d'opérateurs de contrôle enfants.

Cet exemple commence par une nouvelle politique de balises attachée à la racine de l'organisation et suppose que les politiques de balises ne sont pas encore attachées aux entités d'organisation.

Politique E : politique de balises attachée à la racine de l'organisation pour restreindre les modifications apportées dans les politiques enfants


{
    "tags": {
        "project": {
            "tag_key": {
                "@@operators_allowed_for_child_policies": ["@@none"],
                "@@assign": "Project"
            },
            "tag_value": {
                "@@operators_allowed_for_child_policies": ["@@append"],
                "@@assign": [
                    "Maintenance",
                    "Escalations"
                ]
            }
        }
    }
}

Lorsque vous attachez la politique E à la racine de l'organisation, elle empêche les politiques enfants de modifier la clé de balise Project. Les politiques enfants peuvent cependant remplacer ou ajouter des valeurs de balise.

Supposons que vous attachez ensuite la politique F suivante à une unité d'organisation.

Politique F : politique d'identifications attachée à une unité organisationnelle


{
    "tags": {
        "project": {
            "tag_key": {
                "@@assign": "PROJECT"
            },
            "tag_value": {
                "@@append": [
                    "Escalations - research"
                ]
            }
        }
    }
}

La fusion de la politique E et de la politique F a les effets suivants sur les comptes de l'unité d'organisation :

La politique F est une politique enfant de la politique E.
La politique F tente de modifier le traitement de la casse, mais elle ne le peut pas. En effet, la politique E inclut l'opérateur "@@operators_allowed_for_child_policies": ["@@none"] pour la clé de balise.
La politique F peut cependant ajouter des valeurs de balises pour la clé. En effet, la politique E inclut "@@operators_allowed_for_child_policies": ["@@append"] comme valeur de balise.

Stratégie effective pour les comptes de l'unité organisationnelle

Note


{
    "tags": {
        "project": {
            "tag_key": "Project",
            "tag_value": [
                "Maintenance",
                "Escalations",
                "Escalations - research"
            ]
        }
    }
}

Exemple 5 : Conflits avec les opérateurs de contrôle enfants

Des opérateurs de contrôle enfants peuvent figurer dans des politiques de balises attachées au même niveau dans la hiérarchie de l'organisation. Dans ce cas, l'intersection des opérateurs autorisés est utilisée lorsque les politiques fusionnent pour constituer la politique effective des comptes.

Supposons que la politique G et la politique H sont attachées à la racine de l'organisation.

Politique G : politique d'identifications 1 attachée à la racine de l'organisation


{
    "tags": {
        "project": {
            "tag_value": {
                "@@operators_allowed_for_child_policies": ["@@append"],
                "@@assign": [
                    "Maintenance"
                ]
            }
        }
    }
}

Politique H : politique d'identifications 2 attachée à la racine de l'organisation


{
    "tags": {
        "project": {
            "tag_value": {
                "@@operators_allowed_for_child_policies": ["@@append", "@@remove"]
            }
        }
    }
}

Dans cet exemple, une politique attachée à la racine de l'organisation définit que les valeurs de la clé de balise peuvent uniquement être complétées. L'autre politique attachée à la racine de l'organisation permet aux politiques enfants d'ajouter et de supprimer des valeurs. L'intersection de ces deux autorisations est utilisée pour les politiques enfants. Le résultat est que les politiques enfants peuvent ajouter des valeurs, mais pas les supprimer. Par conséquent, la politique enfant peut ajouter une valeur à la liste des valeurs de balise, mais ne peut pas supprimer la valeur Maintenance.

Exemple 6 : Conflits liés à l'ajout de valeurs au même niveau de hiérarchie

Vous pouvez attacher plusieurs politiques de balises à chaque entité d'organisation. Lorsque vous effectuez cette opération, les politiques de balises attachées à la même entité d'organisation peuvent inclure des informations conflictuelles. Ces politiques sont évaluées en fonction de l'ordre dans lequel elles ont été attachées à l'entité d'organisation. Pour changer l'ordre d'évaluation des politiques, vous pouvez détacher une politique, puis la rattacher.

Supposons que la politique J est attachée à la racine de l'organisation en premier, puis que la politique K est attachée à la racine de l'organisation.

PolitiqueJ : première politique d'identifications attachée à la racine de l'organisation


{
    "tags": {
        "project": {
            "tag_key": {
                "@@assign": "PROJECT"
            },
            "tag_value": {
                "@@append": ["Maintenance"]
            }
        }
    }
}

Politique K : deuxième politique d'identifications attachée à la racine de l'organisation


{
    "tags": {
        "project": {
            "tag_key": {
                "@@assign": "project"
            }
        }
    }
}

Dans cet exemple, la clé de balise PROJECT est utilisée dans la politique de balises effective car la politique qui l'a définie a été attachée à la racine de l'organisation en premier.

Politique JK : politique d'identifications effective du compte

La politique effective du compte est la suivante.

Note


{
    "tags": {
        "project": {
            "tag_key": "PROJECT",
            "tag_value": [
                "Maintenance"
            ]
        }
    }
}

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Opérateurs d'héritage

Politiques de sauvegarde