Evaluación jerárquica

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

Puedes definir la misma política de organización con una configuración diferente en los recursos secundarios, que se sobrescribirá o se combinará con la política heredada en función de las reglas de evaluación jerárquica 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 heredada y define si la política hereda la política de su recurso principal. Las formas de colores representan los valores que la política de organización permite o deniega.

Diagrama de herencia

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

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

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

  1. El recurso 1 define una política que establece inheritFromParent en TRUE y permite el rombo azul. La política del nodo de la organización se hereda y se combina con la política definida en el recurso 1. La política en vigor permite el cuadrado rojo, el círculo verde y el rombo azul.

  2. El recurso 2 define una política que establece inheritFromParent en TRUE 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 la organización se hereda y se combina con la política definida en el recurso 2. La política en vigor solo permite el rojo cuadrado.

  3. El recurso 3 define una política que establece inheritFromParent en FALSE y permite el hexágono amarillo . La política del nodo de la organización no se hereda, por lo que la política en vigor solo permite el hexágono amarillo.

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

Reglas de evaluación jerárquica

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, debes tener el rol de administrador de políticas de organización.

Restricciones aplicadas automáticamente

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

Si el comportamiento predeterminado de una restricción de política de organización gestionado por Google restringe una operación, esa operación se restringe aunque nunca hayas definido explícitamente una política de 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 políticas de organización que tienen un comportamiento predeterminado gestionado por Google que restringe las operaciones, consulta el artículo Restricciones de 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 principales en la jerarquía. Sin embargo, si un recurso tiene inheritFromParent = true, se hereda, se combina y se concilia la política en vigor del recurso principal para evaluar la política en vigor resultante. Por ejemplo:

  • Una carpeta deniega el valor projects/123.
  • Un proyecto que está debajo de esa carpeta deniega el valor projects/456.

Las dos políticas se combinan y, en este caso, dan como resultado una política en vigor 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 a cualquier comportamiento predeterminado. Por ejemplo:

  • La restricción constraints/iam.allowServiceAccountCredentialLifetimeExtension se establece en DENY de forma predeterminada a nivel de organización.
  • En el caso de esta restricción, un proyecto que está directamente debajo de esa organización permite el valor SomeServiceAccount.

Como el comportamiento predeterminado nunca se combina y siempre se sustituye, esto da como resultado una política en vigor que permite SomeServiceAccount. En cambio, si la política se hubiera definido explícitamente en DENY a nivel de organización, se aplicaría la regla "El valor DENY tiene prioridad" y la política en vigor sería DENY.

Inhabilitar la herencia

Si un recurso tiene una política que incluye inheritFromParent = false, no hereda la política de organización de su recurso principal. 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 organización, las políticas heredadas se combinan y se concilian con la política de organización del recurso principal. Al evaluar políticas de organización con reglas de lista, los valores DENY siempre tienen prioridad. Por ejemplo:

  • Una carpeta deniega el valor projects/123.
  • Un proyecto que está debajo de esa carpeta permite el valor projects/123.

Las políticas se combinan y el valor DENY tiene prioridad. La política en vigor deniega todos los valores y se evalúa de la misma manera, independientemente de si el recurso principal o el secundario deniega el valor. Te recomendamos que no incluyas un valor en las listas de permitidos y denegados. Si lo haces, puede que te resulte más difícil entender tus políticas.

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

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

  • Un proyecto que está debajo de esa carpeta establece enforced: false para constraints/iam.managed.disableServiceAccountCreation.

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

Restablecer la política predeterminada

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