Información sobre la evaluación jerárquica

Cuando defines una política de la organización en un recurso, todos los descendientes de ese recurso heredan la política de la organización de forma predeterminada. Si defines una política de organización en el recurso de tu organización, todos los recursos secundarios heredarán esas restricciones.

Puedes definir la misma política de organización con una configuración diferente en los recursos secundarios, que sobrescribirá o se combinará con la política heredada en función de las reglas de evaluación de la jerarquía y del tipo de restricción definido en la política de organización.

Antes de empezar

Jerarquía de ejemplo

En el siguiente diagrama de jerarquía de recursos, cada recurso define una política de organización que aplica una restricción gestionada antigua y determina si la política hereda la política de su recurso superior. Las formas de colores representan los valores que la política de la organización permite o deniega.

Diagrama de herencia

Una restricción es un tipo concreto de restricción que se aplica a un Google Cloud servicio o a una lista de Google Cloud servicios. En el ejemplo anterior, Constraint representa el valor predeterminado de la restricción, que define el comportamiento cuando la restricción no se define en una política de la organización. La restricción predeterminada de este ejemplo permite todos los valores de . Los nodos que hay debajo definen las políticas de la organización que anulan el valor predeterminado de la restricción permitiendo o denegando valores.

La política efectiva de cada nodo se evalúa en función de las reglas de herencia. Si no se define ninguna política de la organización, el recurso hereda el comportamiento predeterminado de la restricción. Si defines una política de organización, se usará esa política. En el ejemplo anterior, el nodo de organización define una política que permite el cuadrado rojo y el círculo verde.

Los recursos que se encuentran en la jerarquía situada debajo del nodo de organización se evalúan de la siguiente manera:

  1. Recurso 1 define una política que asigna el valor TRUE a inheritFromParent y permite diamante azul. La política del nodo de organización se hereda y se combina con la política definida en el recurso 1. La política efectiva se evalúa para permitir rojo cuadrado, verde círculo y diamante azul.

  2. Recurso 2 define una política que asigna el valor TRUE a inheritFromParent y deniega el círculo verde . Los valores de denegación siempre tienen prioridad durante la conciliación de políticas. La política del nodo de organización se hereda y se combina con la política definida en el recurso 2. La política efectiva evalúa para permitir solo el cuadrado rojo .

  3. Recurso 3 define una política que asigna el valor FALSE a inheritFromParent y permite el hexágono amarillo . La política del nodo de organización no se hereda, por lo que la política efectiva solo permite el hexágono amarillo .

  4. Resource 4 define una política que asigna el valor FALSE a inheritFromParent e incluye el valor restoreDefault. La política del nodo de organización no se hereda y se usa el comportamiento predeterminado de la restricción, por lo que la política efectiva permite todos los valores.

Reglas de evaluación de la jerarquía

Las siguientes reglas rigen cómo se evalúa una política de organización en un recurso determinado. Para definir una política de organización, necesitas el rol Administrador de políticas de organización.

Restricciones implementadas automáticamente

Si no se aplica una política de la organización, se hereda de su antecesor de nivel más bajo en el que se aplique una política de la organización. Si no se aplica ninguna política de la organización en ningún lugar de la jerarquía de ancestros, se aplica el comportamiento predeterminado gestionado por Google de la restricción.

Si el comportamiento predeterminado gestionado por Google de una restricción de política de la organización restringe una operación, esa operación se restringe aunque nunca hayas definido explícitamente una política de la organización. Para permitir esas operaciones, debes crear políticas de organización que anulen la política principal.

Para ver una lista de las restricciones de las políticas de organización que tienen un comportamiento predeterminado gestionado por Google que restringe las operaciones, consulta Restricciones de las políticas de organización.

Herencia

Un recurso que tiene una política de organización definida de forma predeterminada sustituye a cualquier política definida por sus recursos superiores en la jerarquía. Sin embargo, si un recurso tiene inheritFromParent = true, se hereda, se combina y se concilia la política efectiva del recurso superior para evaluar la política efectiva resultante. Por ejemplo:

  • Una carpeta deniega el valor projects/123.
  • Un proyecto de esa carpeta deniega el valor projects/456.

Las dos políticas se fusionan y, en este caso, dan como resultado una política efectiva que deniega tanto projects/123 como projects/456.

Heredar el comportamiento predeterminado

El comportamiento predeterminado nunca se combina. Cuando se define una política, siempre sustituye al comportamiento predeterminado. Por ejemplo:

  • El constraints/iam.allowServiceAccountCredentialLifetimeExtension está configurado como DENY de forma predeterminada a nivel de organización.
  • En esta restricción, un proyecto directamente subordinado a esa organización permite el valor SomeServiceAccount.

Como el comportamiento predeterminado nunca se combina y siempre se sustituye, se obtiene una política efectiva que permite SomeServiceAccount. Por el contrario, si la política se definiera explícitamente como DENY a nivel de organización, se aplicaría la regla "El valor DENY tiene prioridad" y la política efectiva sería DENY.

No permitir la herencia

Si un recurso tiene una política que incluye inheritFromParent = false, no hereda la política de la organización de su elemento superior. En su lugar, el recurso hereda el comportamiento predeterminado de la restricción, a menos que definas una política con valores permitidos o denegados.

Conciliar conflictos de políticas

Cuando un recurso hereda políticas de la organización, estas se combinan y se concilian con la política de la organización del recurso superior. Cuando se evalúan políticas de organización con reglas de lista, los valores de DENY siempre tienen prioridad. Por ejemplo:

  • Una carpeta deniega el valor projects/123.
  • Un proyecto de esa carpeta permite el valor projects/123.

Las políticas se combinan y el valor de DENY tiene prioridad. La política efectiva deniega todos los valores y se evalúa de la misma forma tanto si el recurso superior como si el inferior deniega el valor. Le recomendamos que no incluya un valor en las listas de elementos permitidos y denegados. Si lo haces, puede que sea más difícil entender tus políticas.

Las políticas de organización con reglas booleanas no se combinan ni se concilian. Si se especifica una política en un recurso, se usará el valor TRUE o FALSE para determinar la política efectiva. Por ejemplo:

  • Una carpeta define enforced: true para constraints/iam.managed.disableServiceAccountCreation.

  • Un proyecto de esa carpeta define enforced: false para constraints/iam.managed.disableServiceAccountCreation.

El valor enforced: true definido en la carpeta se ignora porque enforced: false se ha definido en el propio proyecto. La política de la organización no se aplica en ese proyecto.

Restablecer la política predeterminada

Al invocar RestoreDefault, la política de la organización usa el comportamiento predeterminado de la restricción para este recurso. Los recursos secundarios también heredan este comportamiento.