本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 继承示例
<a name="inheritance-examples"></a>

这些示例通过演示如何将父标签策略和子标签策略合并到某个账户的有效标签策略，来说明策略继承的工作原理。

这些示例假定您具有下图所示的组织结构。

![一个拥有一个根账户 OUs、两个账户和多个账户的组织。](http://docs.aws.amazon.com/zh_cn/organizations/latest/userguide/images/org-structure-inheritance.png)


**Topics**
+ [示例 1：允许子策略*仅* 覆盖标签值](#example-assign-operator)
+ [示例 2：将新值附加到继承的标签](#example-append-operator)
+ [示例 3：从继承标签中删除值](#example-remove-operator)
+ [示例 4：限制对子策略的更改](#example-restrict-child)
+ [示例 5：与子控制运算符的冲突](#multiple-same-node-operators)
+ [示例 6：在相同层次结构级别附加值的冲突](#multiple-same-node-values)

## 示例 1：允许子策略*仅* 覆盖标签值
<a name="example-assign-operator"></a>

以下标签策略定义了 `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：将新值附加到继承的标签
<a name="example-append-operator"></a>

在某些情况下，您可能希望为组织中的所有账户指定一个标签键以及可接受值的短列表。对于一个 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：从继承标签中删除值
<a name="example-remove-operator"></a>

在某些情况下，附加到组织的标签策略定义的标签值数量多于您希望账户使用的数量。此示例说明如何使用 `@@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：限制对子策略的更改
<a name="example-restrict-child"></a>

在某些情况下，您可能希望限制子策略中的更改。此示例说明如何使用子控制运算符来执行此操作。

此示例从新的组织根标签策略开始，并假定标签策略尚未附加到组织实体。

**策略 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：与子控制运算符的冲突
<a name="multiple-same-node-operators"></a>

附加到组织层次结构中同一级别的标签策略中可以存在子控制运算符。发生这种情况时，在合并策略以形成账户的有效策略时，使用允许运算符的交集。

假定策略 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：在相同层次结构级别附加值的冲突
<a name="multiple-same-node-values"></a>

您可以将多个标签策略附加到每个组织实体。执行此操作时，附加到同一组织实体的标签策略可能包含冲突的信息。将按照这些策略附加到组织实体的顺序来评估这些策略。要更改首先评估哪个策略，您可以分离策略，然后重新附加策略。

假定策略 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"
            ]
        }
    }
}
```