本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
继承示例
这些示例通过演示如何将父标签策略和子标签策略合并到某个账户的有效标签策略，来说明策略继承的工作原理。
这些示例假定您具有下图所示的组织结构。
示例 1：允许子策略仅 覆盖标签值
以下标签策略定义了 CostCenter 标签键和可接受的值，即 Development 和 Support。如果您将其附加到组织根，则标签策略对组织中的所有账户都有效。
策略 A – 组织根标签策略
{ "tags": { "costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@assign": [ "Development", "Support" ] } } } }
假定您希望 OU1 中的用户为某个键使用不同的标签值，并且您希望对特定资源类型强制使用此标签策略。由于策略 A 没有指定允许使用哪些子控制运算符，因此允许所有运算符。您可以使用 @@assign 运算符并创建类似于以下内容的标签策略，将其附加到 OU1。
策略 B – OU1 标签策略
{ "tags": { "costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@assign": [ "Sandbox" ] }, "enforced_for": { "@@assign": [ "redshift:*", "dynamodb:table" ] } } } }
在策略 A 和策略 B 合并以形成账户的有效标签策略时，为标签指定 @@assign 运算符会执行以下操作：
-
策略 B 覆盖在父策略（即策略 A）中指定的两个标签值。最终，
Sandbox成为了CostCenter标签键唯一的合规值。 -
添加
enforced_for以指定CostCenter标签必须是所有 Amazon Redshift 资源和 Amazon DynamoDB 表上的指定标签值。
如图所示，OU1 包括两个账户：111111111111 和 222222222222。
产生的账户 111111111111 和 222222222222 的有效标签策略
注意
您不能直接将显示的有效策略的内容用作新策略的内容。语法不包括控制与其他子策略和父策略合并所需的运算符。展示的有效政策只是为了了解合并的结果。
{ "tags": { "costcenter": { "tag_key": "CostCenter", "tag_value": [ "Sandbox" ], "enforced_for": [ "redshift:*", "dynamodb:table" ] } } }
示例 2：将新值附加到继承的标签
在某些情况下，您可能希望为组织中的所有账户指定一个标签键以及可接受值的短列表。对于一个 OU 中的账户，您可能希望允许只有这些账户在创建资源时才能指定的其他值。此示例指定如何使用 @@append 运算符来执行此操作。@@append 运算符是一个高级功能。
与示例 1 类似，此示例从用于组织根标签策略的策略 A 开始。
策略 A – 组织根标签策略
{ "tags": { "costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@assign": [ "Development", "Support" ] } } } }
对于此示例，将策略 C 附加到 OU2。此示例的区别在于，在策略 C 中使用 @@append 运算符会添加 而不是覆盖可接受值和 enforced_for 规则的列表。
策略 C – 用于附加值的 OU2 标签策略
{ "tags": { "costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@append": [ "Marketing" ] }, "enforced_for": { "@@append": [ "redshift:*", "dynamodb:table" ] } } } }
当策略 A 和策略 C 合并以形成账户的有效标签策略时，将策略 C 附加到 OU2 具有以下效果：
-
由于策略 C 包含
@@append运算符，它允许添加 而不是覆盖在策略 A 中指定的可接受标签值列表。 -
与在策略 B 中一样，添加
enforced_for以指定CostCenter标签必须用作所有 Amazon Redshift 资源和 Amazon DynamoDB 表上的指定标签值。如果父策略不包含限制子策略可指定值的子控制运算符，则覆盖 (@@assign) 和添加 (@@append) 具有相同的效果。
如图所示，OU2 包括一个账户：999999999999。策略 A 和策略 C 合并以便为账户 999999999999 创建有效标签策略。
适用于账户 999999999999 的有效标签策略
注意
您不能直接将显示的有效策略的内容用作新策略的内容。语法不包括控制与其他子策略和父策略合并所需的运算符。展示的有效政策只是为了了解合并的结果。
{ "tags": { "costcenter": { "tag_key": "CostCenter", "tag_value": [ "Development", "Support", "Marketing" ], "enforced_for": [ "redshift:*", "dynamodb:table" ] } } }
示例 3：从继承标签中删除值
在某些情况下，附加到组织的标签策略定义的标签值数量多于您希望账户使用的数量。此示例说明如何使用 @@remove 运算符修改标签策略。@@remove 是一项高级功能。
与其他示例类似，此示例从用于组织根标签策略的策略 A 开始。
策略 A – 组织根标签策略
{ "tags": { "costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@assign": [ "Development", "Support" ] } } } }
对于此示例，将策略 D 附加到账户 999999999999。
策略 D – 账户 999999999999 标签策略，用于删除值
{ "tags": { "costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@remove": [ "Development", "Marketing" ], "enforced_for": { "@@remove": [ "redshift:*", "dynamodb:table" ] } } } } }
当策略 A、策略 C 和策略 D 合并以形成有效标签策略时，将策略 D 附加到账户 999999999999 具有以下效果：
-
假设您执行了前面的所有示例策略 B、C，并且 C 是 A 的子策略。策略 B 仅附加到 OU1，因此它对账户 9999999999999 没有任何影响。
-
对于账户 9999999999999，
CostCenter标签键的唯一可接受值是Support。 -
不对
CostCenter标签键强制执行合规性。
适用于账户 999999999999 的新有效标签策略
注意
您不能直接将显示的有效策略的内容用作新策略的内容。语法不包括控制与其他子策略和父策略合并所需的运算符。展示的有效政策只是为了了解合并的结果。
{ "tags": { "costcenter": { "tag_key": "CostCenter", "tag_value": [ "Support" ] } } }
如果您以后向 OU2 添加更多账户，其有效标签策略将与账户 999999999999 不同。这是因为限制性更强的策略 D 仅在账户级别附加，而不附加到 OU。
示例 4：限制对子策略的更改
在某些情况下，您可能希望限制子策略中的更改。此示例说明如何使用子控制运算符来执行此操作。
此示例从新的组织根标签策略开始，并假定标签策略尚未附加到组织实体。
策略 E – 用于限制子策略中的更改的组织根标签策略
{ "tags": { "project": { "tag_key": { "@@operators_allowed_for_child_policies": ["@@none"], "@@assign": "Project" }, "tag_value": { "@@operators_allowed_for_child_policies": ["@@append"], "@@assign": [ "Maintenance", "Escalations" ] } } } }
将策略 E 附加到组织根时，该策略会阻止子策略更改 Project 标签键。但是，子策略可以覆盖或附加标签值。
假定您随后将以下策略 F 附加到 OU。
策略 F – OU 标签策略
{ "tags": { "project": { "tag_key": { "@@assign": "PROJECT" }, "tag_value": { "@@append": [ "Escalations - research" ] } } } }
合并策略 E 和策略 F 会对 OU 的账户产生以下效果：
-
策略 F 是策略 E 的子策略。
-
策略 F 尝试更改案例处理，但无法完成。这是因为策略 E 为标签键包含了
"@@operators_allowed_for_child_policies": ["@@none"]运算符。 -
但是，策略 F 可以为键附加标签值。这是因为策略 E 为标签值包含了
"@@operators_allowed_for_child_policies": ["@@append"]。
OU 中账户的有效策略
注意
您不能直接将显示的有效策略的内容用作新策略的内容。语法不包括控制与其他子策略和父策略合并所需的运算符。展示的有效政策只是为了了解合并的结果。
{ "tags": { "project": { "tag_key": "Project", "tag_value": [ "Maintenance", "Escalations", "Escalations - research" ] } } }
示例 5：与子控制运算符的冲突
附加到组织层次结构中同一级别的标签策略中可以存在子控制运算符。发生这种情况时，在合并策略以形成账户的有效策略时，使用允许运算符的交集。
假定策略 G 和策略 H 附加到组织根。
策略 G – 组织根标签策略 1
{ "tags": { "project": { "tag_value": { "@@operators_allowed_for_child_policies": ["@@append"], "@@assign": [ "Maintenance" ] } } } }
策略 H – 组织根标签策略 2
{ "tags": { "project": { "tag_value": { "@@operators_allowed_for_child_policies": ["@@append", "@@remove"] } } } }
在此示例中，位于组织根的一个策略定义只能附加标签键的值。附加到组织根的另一个策略允许子策略附加和删除值。为子策略使用这两个权限的交集。结果是子策略可以附加值，但不能删除值。因此，子策略可以将值附加到标签值的列表，但不能删除 Maintenance 值。
示例 6：在相同层次结构级别附加值的冲突
您可以将多个标签策略附加到每个组织实体。执行此操作时，附加到同一组织实体的标签策略可能包含冲突的信息。将按照这些策略附加到组织实体的顺序来评估这些策略。要更改首先评估哪个策略，您可以分离策略，然后重新附加策略。
假定策略 J 第一个附加到组织根，然后将策略 K 附加到组织根。
策略 J – 附加到组织根的第一个标签策略
{ "tags": { "project": { "tag_key": { "@@assign": "PROJECT" }, "tag_value": { "@@append": ["Maintenance"] } } } }
策略 K – 附加到组织根的第二个标签策略
{ "tags": { "project": { "tag_key": { "@@assign": "project" } } } }
在此示例中，标签键 PROJECT 在有效标签策略中使用，因为定义它的策略首先附加到组织根。
策略 JK – 账户的有效标签策略
账户的有效策略如下。
注意
您不能直接将显示的有效策略的内容用作新策略的内容。语法不包括控制与其他子策略和父策略合并所需的运算符。展示的有效政策只是为了了解合并的结果。
{ "tags": { "project": { "tag_key": "PROJECT", "tag_value": [ "Maintenance" ] } } }