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.
Exemplos
Exemplo 1: permitir que as políticas secundárias sejam substituídas 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" ] } } } }
Vamos supor que você deseje que os usuários na UO1 usem um valor de tag diferente para uma chave. Além disso, você deseja aplicar a política de tag a 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 operador @@assign e criar uma política de tag como a seguinte para anexar à UO1.
Política B — Política de tag da UO1
{ "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:
-
A política B substitui os dois valores de tag que foram especificados na política pai, a política A. O resultado é que
Sandboxé apenas o valor compatível para a chave de tagCostCenter. -
A adição de
enforced_forespecifica que a tagCostCenterdeve ser o valor de tag especificado em todos os recursos do Amazon RedShift e tabelas do Amazon DynamoDB.
Como mostrado no diagrama, a UO1 inclui duas contas: 111111111111 e 222222222222.
Política de tags efetiva resultante para contas 111111111111 e 222222222222
nota
Você não pode usar diretamente o conteúdo de uma política em vigor exibida como o conteúdo de uma nova política. A sintaxe não inclui os operadores necessários para controlar a mesclagem com outras políticas superiores e subordinadas. A exibição de uma política em vigor destina-se apenas à compreensão dos resultados da fusão.
{ "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" ] } } } }
Para este exemplo, anexe a política C à UO2. 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 tag da UO2 para valores anexos
{ "tags": { "costcenter": { "tag_key": { "@@assign": "CostCenter" }, "tag_value": { "@@append": [ "Marketing" ] }, "enforced_for": { "@@append": [ "redshift:*", "dynamodb:table" ] } } } }
Anexar a política C à UO2 tem os seguintes efeitos quando a política A e a política C são mescladas para formar a política de tags efetiva para uma conta:
-
Como a política C inclui o operador
@@append, ela permite adicionar, e não substituir, a lista de valores de tag aceitáveis especificados na Política A. -
Como na política B, a adição de
enforced_forespecifica que a tagCostCenterdeve ser usada como valor de tag especificado em todos os recursos do Amazon RedShift e tabelas do Amazon DynamoDB. Substituir (@@assign) e adicionar (@@append) terão o mesmo efeito se a política pai não incluir um operador de controle filho que restrinja o que uma política filho pode especificar.
Como mostrado no diagrama, a UO2 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
nota
Você não pode usar diretamente o conteúdo de uma política em vigor exibida como o conteúdo de uma nova política. A sintaxe não inclui os operadores necessários para controlar a mesclagem com outras políticas superiores e subordinadas. A exibição de uma política em vigor destina-se apenas à compreensão dos resultados da fusão.
{ "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:
-
Supondo que você executou todos os exemplos anteriores, as políticas B, C e C são políticas filho da A. A política B é anexada somente à UO1, portanto não tem efeito na conta 9999999999999.
-
Para a conta 9999999999999, o único valor aceitável para a chave de tag
CostCenteréSupport. -
A conformidade não é imposta para a chave de tag
CostCenter.
Nova política de tag eficaz para a conta 999999999999
nota
Você não pode usar diretamente o conteúdo de uma política em vigor exibida como o conteúdo de uma nova política. A sintaxe não inclui os operadores necessários para controlar a mesclagem com outras políticas superiores e subordinadas. A exibição de uma política em vigor destina-se apenas à compreensão dos resultados da fusão.
{ "tags": { "costcenter": { "tag_key": "CostCenter", "tag_value": [ "Support" ] } } }
Se posteriormente você adicionar mais contas à UO2, as políticas de tag 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:
-
A política F é uma política filho da Política E.
-
A política F tenta mudar o tratamento do caso, apesar de não ser possível. Isso ocorre porque a política E inclui o operador
"@@operators_allowed_for_child_policies": ["@@none"]para a chave de tag. -
No entanto, a política F pode anexar valores de tag para a chave. Isso ocorre porque a política E inclui
"@@operators_allowed_for_child_policies": ["@@append"]para o valor da tag.
Política efetiva para contas na UO
nota
Você não pode usar diretamente o conteúdo de uma política em vigor exibida como o conteúdo de uma nova política. A sintaxe não inclui os operadores necessários para controlar a mesclagem com outras políticas superiores e subordinadas. A exibição de uma política em vigor destina-se apenas à compreensão dos resultados da fusão.
{ "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.
nota
Você não pode usar diretamente o conteúdo de uma política em vigor exibida como o conteúdo de uma nova política. A sintaxe não inclui os operadores necessários para controlar a mesclagem com outras políticas superiores e subordinadas. A exibição de uma política em vigor destina-se apenas à compreensão dos resultados da fusão.
{ "tags": { "project": { "tag_key": "PROJECT", "tag_value": [ "Maintenance" ] } } }
