Ejemplos de herencia

Estos ejemplos muestran cómo la herencia de políticas funciona al mostrar que las políticas de etiquetas principales y secundarias se fusionan en una política de etiquetas en vigor para una cuenta.

En los ejemplos se supone que tiene la estructura de organización que se muestra en el siguiente diagrama.

Ejemplo 1: Permitir que las políticas secundarias sobrescriban solo valores de etiquetas

La siguiente política de etiquetas define la clave de etiquetas CostCenter y dos valores aceptables, Development y Support. Si asocia una política de etiquetas a la raíz de la organización, la política de etiquetas se encuentra en vigor para todas las cuentas en la organización.

Política A: política de etiqueta raíz de la organización

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

Suponga que desea que los usuarios en OU1 utilicen un valor de etiqueta diferente para una clave y desea aplicar la política de etiquetas para tipos de recursos específicos. Dado que la política A no especifica qué operadores de control secundarios están permitidos, todos los operadores están permitidos. Puede utilizar el operador @@assign y crear una política de etiquetas como la siguiente para asociar a OU1.

Política B: política de etiqueta OU1

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

Al especificar el operador @@assign para la etiqueta, se hace lo siguiente cuando la política A y la B se fusionan para formar la política de etiquetas en vigor para una cuenta:

• La política B sobrescribe los dos valores de etiquetas que se especificaron en la política principal, la política A. El resultado es que Sandbox es el único valor compatible para la clave de etiquetas CostCenter.

• La adición de enforced_for especifica que la etiqueta CostCenter debe utilizar el valor de etiquetas especificado en todos los recursos de Amazon Redshift y las tablas de Amazon DynamoDB.

Como se muestra en el diagrama, OU1 incluye dos cuentas: 111111111111 y 222222222222.

Política de etiquetas en vigor resultante para las cuentas 111111111111 y 222222222222

nota

No puede utilizar directamente el contenido de una política efectiva mostrada como contenido de una nueva política. La sintaxis no incluye los operadores necesarios para controlar la fusión con otras políticas secundarias y primarias. La presentación de una política eficaz solo tiene por objeto comprender los resultados de la fusión.

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

Ejemplo 2: Agregar nuevos valores a las etiquetas heredadas

Puede haber casos en los que desee que todas las cuentas de su organización especifiquen una clave de etiquetas con una breve lista de valores aceptables. Para las cuentas de una unidad organizativa, es posible que desee permitir un valor adicional que solo puedan especificar esas cuentas al crear recursos. En este ejemplo se especifica cómo hacerlo mediante el operador @@append. El operador @@append es una característica avanzada.

Al igual que el ejemplo 1, este ejemplo comienza con la política A para la política de etiquetas de la raíz de la organización.

Política A: política de etiqueta raíz de la organización

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

Para este ejemplo, asocie la política C a OU2. La diferencia en este ejemplo es que el uso del operador @@append en la política C agrega, en lugar de sobrescribir, la lista de valores aceptables y la regla enforced_for.

Política C: política de etiqueta OU2 para anexar valores

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

La asociación de la política C a OU2 tiene los siguientes efectos cuando las políticas A y C se fusionan para formar la política de etiquetas en vigor para una cuenta:

• Dado que la política C incluye al operador @@append, permite agregar, no sobrescribir, la lista de valores de etiquetas aceptables especificados en la política A.

• Al igual que en la política B, la adición de enforced_for especifica que la etiqueta CostCenter se debe utilizar como valor de etiquetas especificado en todos los recursos de Amazon Redshift y tablas de Amazon DynamoDB. La sobrescritura (@@assign) y la adición (@@append) tienen el mismo efecto si la política principal no incluye un operador de control secundario que restringe lo que puede especificar una política secundaria.

Como se muestra en el diagrama, OU2 incluye una cuenta: 999999999999. Las políticas A y C se fusionan para crear la política de etiquetas en vigor para la cuenta 999999999999.

Política de etiquetas en vigor para la cuenta 999999999999

nota

No puede utilizar directamente el contenido de una política efectiva mostrada como contenido de una nueva política. La sintaxis no incluye los operadores necesarios para controlar la fusión con otras políticas secundarias y primarias. La presentación de una política eficaz solo tiene por objeto comprender los resultados de la fusión.

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

Ejemplo 3: Eliminar los valores de etiquetas heredadas

Puede haber casos en los que la política de etiquetas asociada a la organización defina más valores de etiquetas de los que desea utilizar una cuenta. En este ejemplo se explica cómo revisar una política de etiquetas mediante el operador @@remove. @@remove es una característica avanzada.

Al igual que otros ejemplos, este ejemplo comienza con la política A para la política de etiquetas de la raíz de la organización.

Política A: política de etiqueta raíz de la organización

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

Para este ejemplo, asocie la política D a la cuenta 999999999999.

Política D: política de etiqueta de la cuenta 999999999999 para eliminar valores

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

La asociación de la política D a la cuenta 999999999999 tiene los siguientes efectos cuando las políticas A, C y D se fusionan para formar la política de etiquetas en vigor:

• Suponiendo que haya llevado a cabo todos los ejemplos anteriores, las políticas B, C y D son políticas secundarias de la política A. La política B solo se asocia a OU1, por lo que no tiene ningún efecto en la cuenta 9999999999999.

• Para la cuenta 9999999999999, el único valor aceptable para la clave de etiquetas CostCenter es Support.

• La conformidad no se aplica para la clave de etiquetas CostCenter.

Nueva política de etiquetas en vigor para la cuenta 999999999999

nota

No puede utilizar directamente el contenido de una política efectiva mostrada como contenido de una nueva política. La sintaxis no incluye los operadores necesarios para controlar la fusión con otras políticas secundarias y primarias. La presentación de una política eficaz solo tiene por objeto comprender los resultados de la fusión.

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

Si posteriormente agrega más cuentas a OU2, sus políticas de etiquetas en vigor serían diferentes para la cuenta 999999999999. Esto se debe a que la política D más restrictiva solo se asocia a la cuenta y no a la unidad organizativa.

Ejemplo 4: Restringir los cambios en las políticas secundarias

Puede haber casos en los que desee restringir los cambios en las políticas secundarias. En este ejemplo se explica cómo hacerlo mediante los operadores de control secundarios.

Este ejemplo comienza con una nueva política de etiquetas de la raíz de la organización y se supone que las políticas de etiquetas aún no se asocian a las entidades de la organización.

Política E: política de etiqueta raíz de la organización para restringir los cambios en las políticas secundarias

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

Cuando se asocia la política E a la raíz de la organización, la política impide que las políticas secundarias cambien la clave de la etiqueta Project. Sin embargo, las políticas secundarias pueden sobrescribir o anexar valores de etiquetas.

Supongamos que, a continuación, asocia la siguiente política F a una unidad organizativa.

Política F: política de etiqueta de unidad organizativa

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

La fusión de las políticas E y F tiene los siguientes efectos en las cuentas de la unidad organizativa:

• La política F es una política secundaria de la política E.

• La política F intenta cambiar el tratamiento del caso, pero no puede. Esto se debe a que la política E incluye el operador "@@operators_allowed_for_child_policies": ["@@none"] para la clave de etiqueta.

• Sin embargo, la política F puede añadir los valores de etiquetas para la clave. Esto se debe a que la política E incluye "@@operators_allowed_for_child_policies": ["@@append"] para el valor de etiqueta.

Política en vigor para las cuentas en la unidad organizativa

nota

No puede utilizar directamente el contenido de una política efectiva mostrada como contenido de una nueva política. La sintaxis no incluye los operadores necesarios para controlar la fusión con otras políticas secundarias y primarias. La presentación de una política eficaz solo tiene por objeto comprender los resultados de la fusión.

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

Ejemplo 5: Conflictos con los operadores de control secundarios

Los operadores de control secundarios pueden existir en políticas de etiquetas asociadas al mismo nivel en la jerarquía de la organización. Cuando eso sucede, se utiliza la intersección de los operadores permitidos cuando las políticas se fusionan para formar la política efectiva para las cuentas.

Supongamos que las políticas G y H se asocian a la raíz de la organización.

Política G: política de etiqueta raíz de la organización 1

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

Política H: política de etiqueta raíz de la organización 2

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

En este ejemplo, una política en la raíz de la organización define que los valores de la clave de etiquetas solo se pueden anexar. La otra política asociada a la raíz de la organización permite que las políticas secundarias anexen y eliminen valores. La intersección de estos dos permisos se utiliza para las políticas secundarias. El resultado es que las políticas secundarias pueden anexar valores, pero no eliminar valores. Por lo tanto, la política secundaria puede anexar un valor a la lista de valores de etiquetas, pero no puede eliminar el valor Maintenance.

Ejemplo 6: Conflictos al anexar valores en el mismo nivel de jerarquía

Puede asociar varias políticas de etiquetas a cada entidad de la organización. Al hacerlo, las políticas de etiqueta asociadas a la misma entidad de la organización podrían incluir información conflictiva. Las políticas se evalúan en función del orden en que se asociaron a la entidad de la organización. Para cambiar la política que se evalúa primero, puede asociar una política y, a continuación, volver a asociarla.

Supongamos que la política J se asocia primero a la raíz de la organización y, a continuación, la política K se asocia a la raíz de la organización.

Política J: primera política de etiquetas adjunta al nodo raíz de la organización

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

Política K: segunda política de etiquetas adjunta al nodo raíz de la organización

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

En este ejemplo, la clave de etiquetas PROJECT se utiliza en la política de etiquetas en vigor porque la política que la definió se asoció primero a la raíz de la organización.

Política JK: política de etiquetas en vigor para la cuenta

La política en vigor para la cuenta es la siguiente.

nota

No puede utilizar directamente el contenido de una política efectiva mostrada como contenido de una nueva política. La sintaxis no incluye los operadores necesarios para controlar la fusión con otras políticas secundarias y primarias. La presentación de una política eficaz solo tiene por objeto comprender los resultados de la fusión.

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