Políticas de Límite de Acceso de las Principales

Las políticas de Límite de Acceso de la Entidad (PAB) te permiten definir los recursos a los que pueden acceder las entidades.

Otras políticas relacionadas con el acceso, como las políticas de permiso y de denegación, se adjuntan a los recursos. Estas políticas definen quién puede acceder al recurso al que están asociadas. En cambio, las políticas de límite de acceso de las principales se adjuntan a los conjuntos de principales y controlan lo que pueden hacer las principales del conjunto.

Por ejemplo, puedes usar políticas de límite de acceso de la principal para evitar que tus principales accedan a recursos en otras organizaciones, lo que puede ayudar a prevenir ataques de phishing o robo de datos.

Cómo funcionan las políticas de Límite de Acceso de las Entidades

De forma predeterminada, las principales son aptas para acceder a cualquier recurso Cloud de Confiance by S3NS . Esto significa que, si una política de permiso otorga a una principal acceso a un recurso y no hay políticas de denegación que bloqueen ese acceso, la principal puede acceder al recurso.

Con las políticas de Límite de Acceso de las Entidades, puedes definir los recursos a los que puede acceder una entidad. Si una principal no es apta para acceder a un recurso, su acceso a ese recurso se limita, independientemente de los roles que se le hayan otorgado. Para obtener más información sobre cómo usar las políticas de Límite de Acceso de la Principal para definir los recursos a los que puede acceder una principal, consulta Cómo definir los recursos aptos.

Las políticas de Límite de Acceso de las Entidades solo bloquean los intentos de acceso que involucran permisos admitidos. Si una política de límite de acceso de la principal no puede bloquear un permiso, las principales son aptas para usar ese permiso para acceder a cualquier recurso, independientemente de las políticas a las que estén sujetas. Para obtener más información, consulta Permisos que pueden bloquear las políticas de límite de acceso de la entidad.

Casos de uso

Las políticas de Límite de Acceso de las Entidades son útiles en situaciones como las siguientes:

  • Cómo evitar que los principales accedan a recursos que no son tuyos
  • Mantener ciertos tipos de principales, como las cuentas de servicio, limitados a ciertos proyectos

Para ver ejemplos detallados de cómo puedes usar las políticas de Límite de Acceso de las Entidades en situaciones como estas, consulta Ejemplos de casos de uso de las políticas de Límite de Acceso de las Entidades.

Componentes de la política de Límite de Acceso de la Principal

Las políticas de Límite de Acceso de las Entidades constan de reglas individuales. Cada regla define un conjunto de recursos a los que pueden acceder las entidades. Cada política puede tener hasta 500 reglas.

Las políticas también contienen otra información, incluidos metadatos y detalles de configuración. Para obtener más información, consulta Estructura de una política de Límite de Acceso de la Principal.

Después de crear una política de Límite de Acceso a la Principal, debes crear vinculaciones de políticas para aplicar esa política a conjuntos de principales. Todas las entidades principales de esos conjuntos de entidades principales están sujetas a esa política de límite de acceso de la entidad principal, lo que significa que pueden acceder a los recursos que se enumeran en la política. Puedes vincular una política de Límite de acceso a la principal a cualquier cantidad de conjuntos de principales.

Puedes crear hasta 1,000 políticas de límite de acceso de las principales en tu organización.

Permisos que bloquean las políticas de Límite de Acceso de las Entidades

Las Políticas de Límite de Acceso de las Entidades pueden bloquear todos los permisos incluidos en la versión de aplicación de la política. Si una política de límite de acceso de la principal puede bloquear un permiso, puede impedir que las principales no aptas usen ese permiso para acceder a los recursos.

Cuando creas una política, especificas su versión de aplicación. Cuando se actualiza la versión de aplicación de la política, se actualizan los permisos que esta puede bloquear. Para obtener una lista completa de los permisos que bloquea cada versión de aplicación de la política, consulta la referencia de la versión de aplicación de la política.

Si una política de Límite de Acceso de la Principal no puede bloquear un permiso, la política no tendrá ningún efecto sobre si las principales pueden usar el permiso. En otras palabras, IAM no puede aplicar la política para los intentos de acceso que involucran ese permiso.

Por ejemplo, imagina que a una principal, Lee (lee@example.com), se le otorga el rol de desarrollador de Dataflow (roles/dataflow.developer). Este rol incluye el permiso dataflow.googleapis.com/jobs.snapshot, que le permite a Lee tomar instantáneas de los trabajos de Dataflow. Lee también está sujeto a una política de límite de acceso de la entidad que lo hace no apto para acceder a recursos fuera de example.com. Sin embargo, si esa política de límite de acceso de la principal no puede bloquear el permiso dataflow.jobs.snapshot, Lee aún puede tomar instantáneas de trabajos de Dataflow en organizaciones fuera de example.com.

Administra las versiones de aplicación de políticas

Periódicamente, IAM agrega nuevas versiones de aplicación que pueden bloquear permisos adicionales. Cada nueva versión también puede bloquear todos los permisos de la versión anterior.

Para bloquear los permisos en una nueva versión de aplicación de la política, debes actualizar tus políticas de Límite de Acceso de la Principal para usar la versión nueva.

Si deseas que la versión de aplicación de una política se actualice automáticamente a medida que se lancen versiones nuevas, puedes usar el valor latest cuando crees la política. Sin embargo, no recomendamos usar este valor, ya que podría provocar que las entidades principales pierdan el acceso a los recursos de forma inesperada.

Las políticas que usan latest para el número de versión usan la versión de aplicación predeterminada. Por lo general, la versión de aplicación predeterminada es la más reciente. Sin embargo, una nueva versión puede tardar hasta 4 semanas en convertirse en la versión de aplicación predeterminada. Para saber qué versión de aplicación es la predeterminada, consulta la referencia de la versión de aplicación.

La versión de aplicación predeterminada también se usa para las políticas nuevas de Límite de Acceso de la Entidad que no especifican un número de versión.

Define los recursos aptos

Las entidades pueden verse afectadas por cualquier cantidad de políticas de Límite de Acceso a la Principal o estar sujetas a ellas. En conjunto, estas políticas definen los recursos a los que la entidad principal puede acceder.

Las políticas de Límite de Acceso de las Entidades son aditivas. Esto significa que los recursos a los que una entidad puede acceder son la unión de todos los recursos de todas las políticas de límite de acceso de la entidad a las que está sujeta. En otras palabras, si una sola política de Límite de Acceso de la Principal hace que una principal sea apta para acceder a un recurso, entonces es apta para acceder al recurso, independientemente de las demás políticas de Límite de Acceso de la Principal a las que esté sujeta.

Si una principal no está sujeta a ninguna política de Límite de Acceso de las Entidades, es apta para acceder a cualquier Cloud de Confiance recurso.

En las siguientes secciones, se describe cómo personalizar el conjunto de recursos a los que puede acceder una principal.

Agrega recursos aptos

Existen varias formas de hacer que una principal sea apta para acceder a un recurso al que no puede acceder:

Cómo quitar recursos aptos

Existen varias formas de hacer que una principal no sea apta para acceder a un recurso al que sí puede acceder.

Primero, busca todas las políticas de Límite de Acceso de la Principal a las que está sujeta la principal y que incluyen el recurso. Según las políticas que encuentres, puedes realizar una de las siguientes acciones:

  • Si la entidad no está sujeta a ninguna política de Límite de Acceso de las Entidades, crea una nueva política de Límite de Acceso de las Entidades que incluya solo los recursos a los que quieres que la entidad pueda acceder. Luego, vincula esa política a un conjunto de principales que contenga al principal.

    Después de aplicar la política, la principal pasa de ser apta para acceder a todos los recursos a solo ser apta para acceder a los recursos que se indican en la política.

  • Si la principal ya está sujeta a una o más políticas de Límite de Acceso de las Entidades, debes asegurarte de que ninguna de las políticas de Límite de Acceso de las Entidades a las que está sujeta incluya el recurso. Para obtener instrucciones paso a paso, consulta Reduce los recursos a los que pueden acceder las principales.

    Durante este proceso, debes asegurarte de que la principal siempre esté sujeta a al menos una política de Límite de Acceso de la Principal. De lo contrario, es posible que la principal se vuelva apta para acceder a todos los recursos.

Políticas de Límite de Acceso de las Entidades y recursos almacenados en caché

Algunos Cloud de Confiance by S3NS servicios almacenan en caché los recursos visibles públicamente. Por ejemplo, Cloud Storage almacena en caché los objetos que son de lectura pública.

Si una política de límite de acceso de la principal puede impedir que las principales no aptas vean un recurso visible públicamente depende de si el recurso está almacenado en caché:

  • Si el recurso está almacenado en caché, las políticas de Límite de Acceso de las Entidades no pueden impedir que las entidades vean el recurso.
  • Si el recurso no se almacena en caché, el límite de acceso de la entidad impide que las entidades no aptas vean el recurso.

En todos los casos, las políticas de Límite de Acceso de las Principales siguen impidiendo que las principales no aptas modifiquen o borren recursos visibles públicamente.

Evaluación de la política de Límite de Acceso de la Entidad Principal

Cuando una principal intenta acceder a un recurso, IAM evalúa las políticas de límite de acceso de la principal pertinentes para determinar si se debe bloquear el intento de acceso. Una política es pertinente si la principal que intenta acceder está sujeta a ella.

Las políticas de Límite de Acceso de las Principales solo pueden bloquear o no bloquear el acceso, pero no pueden otorgarlo. Solo las políticas de permisos pueden otorgar acceso a los recursos a las principales. Para obtener información sobre cómo los diferentes tipos de políticas afectan el acceso de las principales a los recursos, consulta Tipos de políticas.

IAM no bloquea el acceso si se cumple alguna de las siguientes condiciones:

  • La entidad principal no está sujeta a ninguna política de Límite de Acceso de la Entidad Principal.
  • Las políticas de límite de acceso de la entidad pertinentes no pueden bloquear el permiso en la solicitud.
  • Una política de límite de acceso de la entidad hace que la entidad sea apta para acceder al recurso.

IAM bloquea el acceso si la principal está sujeta a al menos una política de Límite de Acceso de las Entidades, pero ninguna de las políticas pertinentes hace que la principal sea apta para acceder al recurso.

Evaluación de cierre ante fallas

Las políticas de Límite de Acceso de las Entidades fallan de forma cerrada. Esto significa que, si IAM encuentra un error al evaluar una política de límite de acceso de la principal, IAM impedirá que la principal acceda al recurso.

El motivo más común por el que IAM encuentra un error cuando evalúa las políticas de Límite de acceso de la principal es que los detalles de una principal aún se están propagando por el sistema. Es más probable que esto ocurra con los usuarios recién creados. Para resolver este problema, haz que el nuevo principal espere y vuelva a intentar acceder al recurso más tarde.

Aplica políticas de Límite de Acceso de las Entidades a conjuntos de entidades

Para aplicar una Política de Límite de Acceso de la Principal a un conjunto de principales, debes crear una vinculación de política que especifique tanto la Política de Límite de Acceso de la Principal que deseas aplicar como el conjunto de principales al que deseas aplicarla. Esta vinculación de política vincula la política al conjunto de principales.

Después de vincular una política a un conjunto de entidades, las entidades de ese conjunto solo podrán acceder a los recursos que se enumeran en las políticas de límite de acceso de las entidades a las que están sujetas.

Puedes vincular una política de Límite de Acceso de la Principal a cualquier cantidad de conjuntos de principales. Cada conjunto de entidades puede tener hasta 10 políticas de Límite de Acceso de la Entidad vinculadas.

Solo puedes crear vinculaciones para las políticas de Límite de Acceso a la Principal existentes. Si intentas crear una vinculación para una política de Límite de Acceso de la Principal borrada, se producirá un error. Si borraste recientemente una política de límite de acceso de la entidad principal, a veces puedes crear una vinculación correctamente, pero esta no tendrá ningún efecto. IAM limpia estas vinculaciones automáticamente.

Para obtener información sobre cómo administrar las Políticas de Límite de Acceso de las Entidades, consulta Crea y aplica Políticas de Límite de Acceso de las Entidades.

Conjuntos de entidades admitidos

En la siguiente tabla, se enumeran los tipos de conjuntos de principales a los que puedes vincular políticas de límite de acceso de las principales. Cada fila contiene la siguiente información:

  • Tipo de conjunto de entidades
  • Las principales en ese tipo de conjunto de principales
  • Es el formato de los IDs para ese tipo de conjunto de principales.
  • Es el recurso de Resource Manager (proyecto, carpeta u organización) que vincula las políticas para ese tipo de conjunto principal.
Conjunto principal Detalles Recurso principal de las vinculaciones de políticas
Grupo de identidad de trabajadores

Contiene todas las identidades del grupo de identidades para cargas de trabajo especificado.

Formato: //iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID

Organización que contiene el grupo de identidades de personal
Grupo de identidades para cargas de trabajo

Contiene todas las identidades en el grupo de identidades para cargas de trabajo especificado.

Formato: //iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_POOL_ID

Es el proyecto que contiene el grupo de identidades para cargas de trabajo.
Dominio de Google Workspace

Contiene todas las identidades del dominio de Google Workspace especificado.

Formato: //iam.googleapis.com/locations/global/workspace/CUSTOMER_ID

Puedes encontrar tu ID de cliente con los siguientes métodos:

La organización asociada al dominio de Google Workspace
Conjunto de principales del proyecto

Contiene todas las cuentas de servicio, los grupos de identidades para cargas de trabajo y las identidades de agente en el proyecto especificado.

Formato: //cloudresourcemanager.googleapis.com/projects/PROJECT_ID

El proyecto
Conjunto de principales de la carpeta

Contiene todas las cuentas de servicio, todos los grupos de identidades para cargas de trabajo y todas las identidades de agentes en cualquier proyecto de la carpeta especificada.

Formato: //cloudresourcemanager.googleapis.com/folders/FOLDER_ID

La carpeta
Conjunto principal de la organización

Contiene las siguientes identidades:

  • Todas las identidades en todos los dominios asociados con tu ID de cliente de Google Workspace
  • Todos los grupos de identidades del personal de tu organización
  • Todas las cuentas de servicio, los grupos de identidades para cargas de trabajo y las identidades de agentes en cualquier proyecto de la organización

Formato: //cloudresourcemanager.googleapis.com/organizations/ORGANIZATION_ID

La organización
Identidades de los agentes

Son todas las identidades de agente en el dominio de confianza del proyecto especificado. De forma predeterminada, el dominio de confianza de un proyecto contiene todas las identidades de agente del proyecto.

Formatos:

  • //agents.global.org-ORGANIZATION_ID.system.id.goog/attribute.container/projects/PROJECT_NUMBER
  • //agents.global.proj-PROJECT_NUMBER.system.id.goog/attribute.container/projects/PROJECT_NUMBER
El proyecto

Herencia de políticas y conjuntos de principales

Las políticas de Límite de Acceso de las Principales se adjuntan a conjuntos de principales, no a recursos. Como resultado, no se heredan a través de la jerarquía de recursos de la misma manera que las políticas de permiso y denegación.

Sin embargo, los conjuntos principales de las carpetas y las organizaciones siempre incluyen todos los principales en los conjuntos principales de sus elementos subordinados. Por ejemplo, si un principal se incluye en el conjunto de principales de un proyecto, también se incluye en los conjuntos de principales de las organizaciones o carpetas superiores.

Por ejemplo, considera una organización, example.com. Esta organización está asociada al dominio example.com y tiene los siguientes recursos:

Jerarquía de recursos para example.com

Jerarquía de recursos para example.com

  • Una organización, example.com
  • Un proyecto, project-1, que es secundario de la organización
  • Una carpeta, folder-a, que es secundaria de la organización
  • Dos proyectos, project-2 y project-3, que son elementos secundarios de folder-a

Los conjuntos principales de estos recursos contienen las siguientes identidades:

Conjunto principal Identidades de Google Workspace en el dominio example.com Grupos de federación de identidades de personal en example.com Cuentas de servicio, grupos de identidades para cargas de trabajo e identidades de agentes en project-1 Cuentas de servicio, grupos de identidades para cargas de trabajo e identidades de agentes en project-2 Cuentas de servicio, grupos de identidades para cargas de trabajo e identidades de agentes en project-3
Se estableció el principal para example.com
Se estableció el principal para folder-a
Se estableció el principal para project-1
Se estableció el principal para project-2
Se estableció el principal para project-3

Como resultado, las siguientes entidades principales se ven afectadas por las siguientes políticas de Límite de Acceso de las Entidades:

  • Una identidad de Google Workspace en el dominio example.com se encuentra en el conjunto de principales de example.com y se verá afectada por las políticas de Límite de Acceso de las Principales vinculadas a ese conjunto de principales.

  • Una cuenta de servicio en project-1 se encuentra en los conjuntos de principales de project-1 y example.com, y se verá afectada por las políticas de Límite de acceso a la principal vinculadas a cualquiera de esos conjuntos de principales.

  • Una identidad de agente en project-3 se encuentra en los conjuntos de principales de project-3, folder-a y example.com, y se verá afectada por las políticas de Límite de Acceso de las Principales vinculadas a cualquiera de esos conjuntos de principales.

Vinculaciones de políticas condicionales para las políticas de Límite de Acceso de las Entidades

Puedes usar expresiones de condición en las vinculaciones de políticas para las políticas de Límite de Acceso de las Entidades para definir mejor a qué entidades se aplica la política.

Las expresiones de condición para las vinculaciones de políticas constan de una o más declaraciones unidas por hasta 10 operadores lógicos (&&, || o !). Cada declaración expresa una regla de control basada en atributos que se aplica a la vinculación de políticas y, en última instancia, determina si se aplica la política.

Puedes usar los atributos principal.type y principal.subject en las condiciones de las vinculaciones de políticas. No se admiten otros atributos.

  • El atributo principal.type hace referencia al tipo de principal que realizó la solicitud, por ejemplo, una cuenta de servicio o la identidad de un agente. Puedes usar condiciones con este atributo para controlar a qué tipos de principales se aplica una política de límite de acceso de la principal.

    Por ejemplo, si agregas la siguiente expresión de condición a una vinculación para una política de límite de acceso de la principal, la política solo se aplicará a las cuentas de servicio:

    principal.type == 'iam.googleapis.com/ServiceAccount'
    
  • El atributo principal.subject hace referencia a la identidad del principal que realizó la solicitud, por ejemplo, cruz@example.com. Puedes usar condiciones con este atributo para controlar exactamente qué principales están sujetas a una política de Límite de Acceso de la Principal.

    Por ejemplo, si agregas la siguiente expresión de condición a una vinculación para una política de límite de acceso de las principales, la política no se aplicará al usuario special-admin@example.com:

    principal.subject != 'special-admin@example.com'
    

Para obtener más información sobre los valores que puedes usar para estas condiciones, consulta la referencia del atributo de condiciones.

Para ver un ejemplo de cómo usar estas condiciones en tus políticas de límite de acceso principal, consulta Cómo hacer que las cuentas de servicio sean aptas para acceder a los recursos en un solo proyecto.

Vinculaciones de políticas entre organizaciones

No puedes crear una vinculación de políticas entre organizaciones para una política de Límite de Acceso de la Principal. Una vinculación de políticas entre organizaciones es una vinculación de políticas que vincula una política de una organización a un conjunto de principales de otra organización.

IAM borra periódicamente las vinculaciones de políticas entre organizaciones existentes. Las vinculaciones de políticas entre organizaciones pueden ocurrir cuando mueves un proyecto de una organización a otra. Por ejemplo, considera la siguiente situación:

  • Tienes un proyecto, example-project, en la organización example.com.
  • Deseas que las principales en example-project sean aptas para acceder a los recursos en example.com. Para ello, crea una política de Límite de Acceso a la Principal en example.com que haga que las principales sean aptas para acceder a los recursos en example.com y vincula esa política al conjunto de principales para example-project.
  • Mueves example-project de example.com a cymbalgroup.com.

En esta situación, mover el proyecto crea una vinculación de política entre organizaciones. Esto se debe a que la Política de Límite de Acceso de las Principales en example.com está vinculada a un conjunto de principales en cymbalgroup.com. Si no borras la vinculación de forma manual, IAM la borrará automáticamente con el tiempo. Borrar esta vinculación ayuda a garantizar que los administradores de cymbalgroup.com tengan acceso a todas las políticas de Límite de Acceso de las Entidades vinculadas a sus entidades.

Estructura de una política de Límite de Acceso de las Entidades

Una política de Límite de Acceso a la Principal es una colección de metadatos y detalles de la política de Límite de Acceso a la Principal. Los metadatos proporcionan información como el nombre de la política y cuándo se creó. Los detalles de la política definen lo que hace la política, por ejemplo, los recursos a los que pueden acceder las principales afectadas.

Por ejemplo, la siguiente política de límite de acceso de la principal hace que las principales sujetas a la política sean aptas para acceder a los recursos de la organización con el ID 0123456789012.

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
  "uid": "puid_0123456789012345678",
  "etag": "W/\"Gh/PcTdJD/AWHUhPW45kdw==\"",
  "displayName": "Example policy",
  "annotations": {
    "example-key": "example-value"
  },
  "createTime": "2024-01-02T15:01:23Z",
  "updateTime": "2024-01-02T15:01:23Z",
  "details": {
    "rules": [
      {
        "description": "Example principal access boundary policy rule",
        "resources": [
          "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "4"
  }
}

En las siguientes secciones, se describen los campos en los metadatos y los detalles de una política de Límite de Acceso de las Entidades.

Metadatos

Las políticas de Límite de Acceso de las Entidades contienen los siguientes metadatos:

  • name: Es el nombre de la política de límite de acceso de la principal. Este nombre tiene el formato organizations/ORGANIZATION_ID/locations/global/principalAccessBoundaryPolicies/PAB_POLICY_ID, en el que ORGANIZATION_ID es el ID numérico de la organización en la que se creó la política de Límite de Acceso de la Principal y PAB_POLICY_ID es el ID alfanumérico de la política de Límite de Acceso de la Principal.
  • uid: Es un ID único asignado a la política de Límite de Acceso de la Principal.
  • etag: Es un identificador del estado actual de la política. Este valor cambia cuando actualizas la política. Para evitar actualizaciones en conflicto, el valor etag debe coincidir con el valor almacenado en IAM. Si los valores de etag no coinciden, la solicitud falla.
  • displayName: Es un nombre legible para la política de límite de acceso de la principal.
  • annotations: Opcional Es una lista de pares clave-valor definidos por el usuario. Puedes usar estas anotaciones para agregar metadatos adicionales a la política, por ejemplo, quién la creó o si se implementó con una canalización automatizada. Para obtener más información sobre las anotaciones, consulta Anotaciones.
  • createTime: Es la fecha y hora en que se creó la política de Límite de Acceso a la Principal.
  • updateTime: Es la fecha y hora en que se actualizó por última vez la política de Límite de Acceso a la Principal.

Detalles

Cada política de Límite de Acceso de las Entidades contiene un campo details. Este campo contiene las reglas del límite de acceso de la entidad y la versión de aplicación:

  • rules: Es una lista de reglas de Límite de Acceso de la Entidad Principal que definen los recursos a los que pueden acceder las entidades principales afectadas. Cada regla contiene los siguientes campos:

    • description: Es una descripción legible de la regla.
    • resources: Es una lista de recursos de Resource Manager (proyectos, carpetas y organizaciones) a los que deseas que los principales puedan acceder. Cualquier principal que esté sujeto a esta política es apto para acceder a estos recursos.

      Cada Política de Límite de Acceso de las Entidades puede hacer referencia a un máximo de 500 recursos en todas las reglas de la política.

    • effect: Es la relación que tienen las entidades principales con los recursos que se enumeran en el campo resources. El único efecto que puedes especificar en las reglas de Límite de Acceso de la Entidad es "ALLOW". Esta relación hace que las principales sean aptas para acceder a los recursos que se indican en la regla.

  • enforcementVersion: Es la versión de aplicación que usa IAM cuando aplica la política. La versión de la política de Límite de Acceso de la Entidad determina qué permisos puede bloquear la política de Límite de Acceso de la Entidad.

    Para obtener más información sobre cómo configurar y administrar las versiones de aplicación, consulta Administra versiones de aplicación en esta página.

Estructura de una vinculación de política

Una vinculación de políticas para una política de Límite de Acceso de las Entidades contiene el nombre de una política, el nombre del conjunto de entidades principales al que se vinculará la política y los metadatos que describen la vinculación de políticas. También puede contener condiciones que modifiquen los principales exactos a los que se aplica la política.

Por ejemplo, la siguiente vinculación de política vincula la política example-policy a todos los principales de la organización example.com, que tiene el ID 0123456789012. La vinculación de la política también contiene una condición que impide que la política se aplique a la principal super-admin@example.com.

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-policy-binding",
  "uid": "buid_01234567890123456789", 
  "etag": "W/\"cRMdDXbT82aLuZlvoL9Gqg==\"",
  "displayName": "Example policy binding",
  "annotations": {
    "example-key": "example-value"
  },
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-policy",
  "policyUid": "puid_0123456789012345678",
  "condition": {
    "title": "Exempt principal",
    "description": "Don't enforce the policy for super-admin@example.com",
    "expression": "principal.subject != 'super-admin@example.com'"
  },
  "createTime": "2024-01-02T17:00:16Z",
  "updateTime": "2024-01-02T17:00:16Z"
}

Cada vinculación de política contiene los siguientes campos:

  • name: Es el nombre de la vinculación de la política. Este nombre tiene el formato RESOURCE_TYPE/RESOURCE_ID/locations/global/policyBindings/BINDING_ID, en el que RESOURCE_TYPE/RESOURCE_ID es el tipo y el ID del recurso principal de la vinculación de política, y BINDING_ID es el ID alfanumérico de la vinculación de política.
  • uid: Es un ID único asignado a la vinculación de la política.
  • etag: Es un identificador del estado actual de la política. Este valor cambia cuando actualizas la política. Para evitar actualizaciones en conflicto, el valor etag debe coincidir con el valor almacenado en IAM. Si los valores de etag no coinciden, la solicitud falla.
  • displayName: Es un nombre legible para la vinculación de la política.
  • annotations: Opcional Es una lista de pares clave-valor definidos por el usuario. Puedes usar estas anotaciones para agregar metadatos adicionales a la vinculación de política, por ejemplo, quién creó la vinculación de política o si una canalización automatizada implementó la vinculación de política. Para obtener más información sobre las anotaciones, consulta Anotaciones.
  • target: Es el conjunto de principales al que se vinculará la política. El valor tiene el formato {"principalSet": PRINCIPAL_SET}, en el que PRINCIPAL_SET es el ID del conjunto de principales al que deseas vincular la política.

    Cada destino puede tener hasta 10 políticas vinculadas.

  • policyKind: Es el tipo de política al que hace referencia la vinculación de políticas. En el caso de las vinculaciones de políticas para las políticas de Límite de Acceso de las Entidades, este valor siempre es PRINCIPAL_ACCESS_BOUNDARY.

  • policy: Es la política de Límite de Acceso de la Principal que se vinculará al conjunto de principales objetivo.

  • policyUid: Es un ID único asignado a la política de límite de acceso de la principal a la que se hace referencia en el campo policy.

  • condition: Opcional Es una expresión lógica que afecta a qué principales IAM aplica la política. Si la condición se evalúa como verdadera o no se puede evaluar, Identity and Access Management aplica la política para la principal que realiza la solicitud. Si la condición se evalúa como falsa, Identity and Access Management no aplica la política para la principal. Para obtener más información, consulta Límite de acceso de la entidad y condiciones en esta página.

  • createTime: Es la fecha y hora en que se creó la vinculación de la política.

  • updateTime: Es la fecha y hora en que se actualizó la vinculación de la política por última vez.

¿Qué sigue?