As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Exemplos de herança

Estes exemplos mostram como a herança de política funciona ao exibir como as políticas de tag pai e filho são mescladas em uma política de tag efetiva para uma conta.

Os exemplos assumem que você tem a estrutura de organização exibida no diagrama a seguir.

Exemplo 1: permitir que políticas filho substituam apenas valores de tag

A política de tags a seguir define a chave de tag CostCenter e dois valores aceitáveis, Development e Support. Se você anexá-la à raiz da organização, a política de tag estará em vigor para todas as contas na organização.

Política A — Política de tag da raiz da organização

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

Suponha que você queira que os usuários usem OU1 um valor de tag diferente para uma chave e imponha a política de tags para tipos de recursos específicos. Como a política A não especifica quais operadores de controle filho são permitidos, todos os operadores são permitidos. Você pode usar o @@assign operador e criar uma política de tag como a seguinte para anexar OU1.

Política B — política de OU1 tags

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

Isto é o que acontece ao especificar o operador @@assign para a tag quando a política A e a política B são mescladas para formar a política de tag efetiva para uma conta:

Conforme mostrado no diagrama, OU1 inclui duas contas: 111111111111 e 2222222222.

Política de tags efetiva resultante para contas 111111111111 e 222222222222

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

Exemplo 2: anexar novos valores a tags herdadas

Pode haver casos em que você deseja que todas as contas da organização especifiquem uma chave de tag com uma pequena lista de valores aceitáveis. Para contas em uma UO, convém permitir um valor adicional que somente essas contas possam especificar ao criar recursos. Este exemplo especifica como fazer isso usando o operador @@append. O operador @@append é um recurso avançado.

Como o exemplo 1, este exemplo começa com a política A para a política de tag da raiz da organização.

Política A — Política de tag da raiz da organização

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

Neste exemplo, anexe a política C OU2 a. A diferença neste exemplo é que o uso do operador @@append na política C adiciona, em vez de substituir, a lista de valores aceitáveis e a regra enforced_for.

Política C — política de OU2 tags para anexar valores

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

Anexar a política C à OU2 tem os seguintes efeitos quando a política A e a política C se fundem para formar a política de tags efetiva para uma conta:

Conforme mostrado no diagrama, OU2 inclui uma conta: 999999999999. A política A e a política C são mescladas para criar a política de tag efetiva para a conta 999999999999.

Política de tag efetiva para a conta 999999999999

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

Exemplo 3: remover valores de tags herdadas

Pode haver casos em que a política de tag anexada à organização defina mais valores de tag do que aqueles você deseja que uma conta use. Este exemplo explica como revisar uma política de tag usando o operador @@remove. O @@remove é um recurso avançado.

Como os outros exemplos, este exemplo começa com a política A para a política de tag da raiz da organização.

Política A — Política de tag da raiz da organização

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

Para este exemplo, anexe a política D à conta 999999999999.

Política D — Política de tag da conta 999999999999 para remoção de valores

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

A anexação da política D à conta 999999999999 tem os efeitos a seguir quando as políticas A, C e D se mesclam para formar a política de tags efetiva:

Nova política de tag eficaz para a conta 999999999999

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

Se você adicionar mais contas posteriormente OU2, suas políticas de tags efetivas serão diferentes das da conta 999999999999. Isso ocorre porque a política mais restritiva D é anexada apenas no nível da conta, e não à UO.

Exemplo 4: restringir alterações às políticas filho

Pode haver casos em que você queira restringir as alterações nas políticas filho. Este exemplo explica como fazer isso usando operadores de controle filho.

Este exemplo começa com uma nova política de tag da raiz da organização e assume que as políticas de tag ainda não estão anexadas a entidades da organização.

Política E: política de tag da raiz da organização para restringir alterações em políticas subordinadas

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

Quando você anexa a política E à raiz da organização, ela impede que as políticas filho alterem a chave de tag Project. No entanto, as políticas filho podem substituir ou anexar valores de tag.

Vamos supor que depois você anexe a seguinte política F a uma UO.

Política F — Política de tag da UO

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

Mesclar as políticas E e F tem os seguintes efeitos nas contas da UO:

Política efetiva para contas na UO

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

Exemplo 5: conflitos com operadores de controle filho

Os operadores de controle filho podem existir em políticas de tag anexadas no mesmo nível na hierarquia da organização. Quando isso acontece, a interseção dos operadores permitidos é usada quando as políticas se mesclam para formar a política efetiva das contas.

Suponha que as políticas G e H estão anexadas à raiz da organização.

Política G — Política de tag da raiz da organização 1

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

Política H — Política de tag da raiz da organização 2

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

Neste exemplo, uma política na raiz da organização define que os valores da chave de tag só podem ser anexados. A outra política anexada à raiz da organização permite que as políticas filho anexem e removam valores. A interseção dessas duas permissões é usada para políticas filho. O resultado é que as políticas filho podem anexar valores, mas não remover valores. Portanto, a política filho pode anexar um valor à lista de valores de tag, mas não pode remover o valor Maintenance.

Exemplo 6: conflitos com a anexação de valores no mesmo nível de hierarquia

Você pode anexar várias políticas de tag a cada entidade da organização. Quando você fizer isso, as políticas de tag anexadas à mesma entidade da organização podem incluir informações conflitantes. As políticas são avaliadas com base na ordem em que foram anexadas à entidade da organização. Para alterar qual política é avaliada primeiro, você pode desanexar uma política e reanexá-la.

Suponha que a política J tenha sido a primeira a ser anexada à raiz da organização, e a política K tenha sido a segunda.

Política J — Primeira política de tag anexada à raiz da organização

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

Política K — Segunda política de tag anexada à raiz da organização

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

Neste exemplo, a chave de tag PROJECT é usada na política de tag efetiva porque a política que a definiu foi anexada à raiz da organização primeiro.

Política JK — Política de tag em vigor para a conta

A política efetiva para a conta é a seguinte.

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