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

Las políticas de límite de acceso de las principales (PAB) te permiten definir los recursos a los que pueden acceder las principales.

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

Para obtener información sobre los otros tipos de políticas de control de acceso que ofrece Identity and Access Management (IAM), consulta Tipos de políticas.

Cómo funcionan las políticas de límite de acceso de las principales

De forma predeterminada, las principales son aptas para acceder a cualquier recurso Google Cloud . Esto significa que, si una principal tiene un permiso en el recurso y no se le deniega ese permiso, puede usarlo para acceder al recurso.

Con las políticas de límite de acceso de las principales, puedes definir los recursos a los que una principal puede acceder. Si una política de límite de acceso de las principales hace que una principal no sea apta para acceder a un recurso, su acceso a ese recurso se limita, independientemente de los roles que se le hayan otorgado.

Cuando las principales intentan acceder a recursos a los que no son aptas para acceder, las políticas de límite de acceso de las principales pueden bloquear algunos, pero no todos, los permisos de Identity and Access Management (IAM). Para obtener más información sobre los permisos que se bloquean, consulta Permisos que puede bloquear el límite de acceso de la principal.

Las políticas de límite de acceso de las principales se componen de reglas de límite de acceso de las principales. Cada regla de límite de acceso principal define un conjunto de recursos a los que pueden acceder las principales afectadas. Puedes crear hasta 1,000 políticas de límite de acceso de las principales en tu organización.

Después de crear una política de límite de acceso de las principales, crea una vinculación de políticas para aplicar la política a un conjunto de principales.

Un principal puede estar sujeto a una o más políticas de límite de acceso de las principales. Cada principal solo es apta para acceder a los recursos que se indican en esas políticas. Para todos los demás recursos, el acceso de la principal a ese recurso es limitado, incluso si le otorgas roles a la principal en ese recurso.

Dado que las políticas de límite de acceso de las principales se asocian con las principales y no con los recursos, puedes usarlas para impedir que las principales accedan a los recursos que no te pertenecen. Por ejemplo, considera la siguiente situación:

• El principal Tal (tal@example.com) forma parte de la organización de Google Workspace example.com.
• A Tal se le otorga el rol de administrador de almacenamiento (roles/storage.admin) en un bucket de Cloud Storage en otra organización, cymbalgroup.com. Este rol contiene el permiso storage.objects.get, que se requiere para ver objetos en el bucket.
• No hay políticas de denegación en cymbalgroup.com que impidan que Tal use el permiso storage.objects.get.

Con solo políticas de permiso y denegación, example.com no puede impedir que Tal vea objetos en este bucket externo. Ninguna principal example.com tiene permiso para editar la política de permisos del bucket, por lo que no puede revocar el rol de Tal. Tampoco tiene permiso para crear políticas de denegación en cymbalgroup.com, por lo que no puede usar una política de denegación para impedir que Tal acceda al bucket.

Sin embargo, con las políticas de límite de acceso de la principal, los administradores de example.com pueden asegurarse de que Tal no pueda ver objetos en el bucket de cymbalgroup.com ni en ningún bucket fuera de example.com. Para ello, los administradores pueden crear una política de límite de acceso de la principal que indique que las principales de example.com solo son aptas para acceder a los recursos de example.com. Luego, pueden crear una vinculación de políticas para adjuntar esta política a todos los principales de la organización example.com. Con esa política, Tal no podrá ver objetos en el bucket cymbalgroup.com, aunque se le haya otorgado el rol de administrador de almacenamiento en el bucket.

Evaluación de cierre ante fallas

Las políticas de límite de acceso de las principales fallan de forma cerrada. Esto significa que, si IAM no puede evaluar una política de límite de acceso de la principal cuando evalúa el acceso de una principal, IAM impedirá que la principal acceda al recurso.

El motivo más común por el que IAM no puede evaluar las políticas de límite de acceso de las principales 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 la nueva principal espere y vuelva a intentar acceder al recurso más tarde.

Permisos que bloquean las Políticas de Límite de Acceso de las Principales

Cuando las principales intentan acceder a un recurso al que no son aptas, las políticas de límite de acceso de las principales les impiden usar algunos, pero no todos, los permisos de Identity and Access Management (IAM) para acceder al recurso.

Si una política de límite de acceso de la principal bloquea un permiso, IAM aplica las políticas de límite de acceso de la principal para ese permiso. En otras palabras, impide que los principales que no son aptos para acceder a un recurso usen ese permiso para acceder a él.

Si una política de límite de acceso de las principales no bloquea un permiso, entonces las políticas de límite de acceso de las principales no tienen ningún efecto sobre si las principales pueden usar el 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.jobs.snapshot, que 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 las principales que lo hace no apto para acceder a recursos fuera de example.com. Sin embargo, si las políticas de límite de acceso de las principales no bloquean el permiso dataflow.jobs.snapshot, Lee aún puede tomar instantáneas de trabajos de Dataflow en organizaciones fuera de example.com.

Los permisos que bloquea una política de límite de acceso de las principales dependen de la versión de aplicación de la política de límite de acceso de las principales.

Versiones de aplicación de límites de acceso de las principales

Cada política de límite de acceso de la principal especifica una versión de aplicación, que identifica una lista predefinida de permisos de IAM que la política de límite de acceso de la principal puede bloquear. Especificas la versión de aplicación cuando creas o actualizas una política de límite de acceso de la principal. Si no especificas una versión de aplicación, IAM usará la versión de aplicación más reciente y seguirá usándola hasta que la actualices.

Periódicamente, IAM agrega nuevas versiones de aplicación de límites de acceso de principales que pueden bloquear permisos adicionales. Cada versión nueva 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 nueva versión. Si deseas que la versión de aplicación de la 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.

Para obtener una lista completa de los permisos que bloquea cada versión de aplicación, consulta Permisos que bloquean las Políticas de Límite de Acceso de las Principales.

Vincula políticas de límite de acceso de las principales a conjuntos de principales

Para vincular una Política de Límite de Acceso de las Principales a un conjunto de principales, debes crear una vinculación de políticas que especifique tanto la Política de Límite de Acceso de las Principales que deseas aplicar como el conjunto de principales para el que deseas aplicarla. Después de vincular la política a un conjunto de principales, las principales de ese conjunto solo podrán acceder a los recursos incluidos en las reglas de la Política de Límite de Acceso de las Principales.

Puedes vincular una política de límite de acceso de las principales a cualquier cantidad de conjuntos de las principales. Cada conjunto de principales puede tener hasta 10 políticas de límite de acceso de las principales vinculadas.

Solo puedes crear vinculaciones para las políticas de límite de acceso de las principales existentes. Si intentas crear una vinculación para una Política de Límite de Acceso de las Principales borrada, se producirá un error. Si borraste recientemente una política de límite de acceso de las principales, 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 Principales, consulta Crea y aplica Políticas de Límite de Acceso de las Principales.

Conjuntos de principales 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 principales. Cada fila contiene la siguiente información:

• Tipo de conjunto principal
• 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.

Vinculaciones de políticas condicionales para las políticas de límite de acceso de las principales

Puedes usar expresiones de condición en las vinculaciones de políticas para las políticas de límite de acceso de las principales para definir mejor a qué principales 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 en las condiciones para las vinculaciones de políticas.

• El atributo principal.type indica qué tipo de principal se incluye en la solicitud, por ejemplo, cuentas de servicio o identidades en un grupo de identidades para cargas de trabajo. Puedes usar condiciones con este atributo para controlar a qué tipos de principales se aplica una política de límite de acceso de las principales.

  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 solo se aplicará a las cuentas de servicio:

  principal.type == 'iam.googleapis.com/ServiceAccount'
  

• El atributo principal.subject indica la identidad de la entidad principal en 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 principales.

  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 Condiciones.

Ejemplo: Usa condiciones para reducir los recursos a los que puede acceder un principal

Una de las formas en que puedes usar condiciones en las vinculaciones de políticas de límite de acceso de las principales es para reducir los recursos a los que puede acceder una sola principal.

Supongamos que tienes una cuenta de servicio, dev-project-service-account, con la dirección de correo electrónico dev-project-service-account@dev-project.iam.gserviceaccount.com. Esta cuenta de servicio está sujeta a una política de límite de acceso de la principal que hace que las principales sean aptas para acceder a todos los recursos de la organización example.com. Esta política se adjunta al conjunto de principales de la organización example.com.

Decides que no quieres que dev-project-service-account sea apto para acceder a todos los recursos de example.com, sino solo a los de dev-project. Sin embargo, no quieres cambiar los recursos a los que otros principales del conjunto de principales example.com son aptos para acceder.

Para realizar este cambio, sigue el procedimiento para reducir los recursos a los que pueden acceder las principales, pero agrega una condición a la vinculación de políticas en lugar de borrarla:

1. Confirmas que la única política de límite de acceso de la principal a la que está sujeta dev-project-service-account es la política que hace que las principales sean aptas para acceder a todos los recursos en example.com.

2. Crea una nueva política de límite de acceso de las principales que haga que las principales sean aptas para acceder a los recursos en dev-project y adjúntala al conjunto de principales de dev-project. Usas la siguiente condición en la vinculación de la política para garantizar que la política solo se aplique a dev-project-service-account:

   "condition": {
     "title": "Only dev-project-service-account",
     "expression": "principal.type == 'iam.googleapis.com/ServiceAccount' && principal.subject == 'dev-project-service-account@dev-project.iam.gserviceaccount.com'"
   }
   

3. Eximes a dev-project-service-account de la política de límite de acceso de la principal que hace que las principales sean aptas para acceder a todos los recursos en example.com. Para ello, agrega la siguiente condición a la vinculación de política que adjunta esa Política de Límite de Acceso de las Principales al conjunto de principales de la organización:

   "condition": {
     "title": "Exempt dev-project-service-account",
     "expression": "principal.subject != 'dev-project-service-account@dev-project.iam.gserviceaccount.com' || principal.type != 'iam.googleapis.com/ServiceAccount'"
   }
   

   Para obtener información sobre cómo actualizar las Políticas de Límite de Acceso de las Principales existentes, consulta Edita las Políticas de Límite de Acceso de las Principales.

Después de agregar esta condición a la vinculación de política, dev-project-service-account ya no es apto para acceder a todos los recursos en example.com, sino que solo es apto para acceder a los recursos en dev-project.

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 las principales. 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 de las Principales 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 crearía una vinculación de política entre organizaciones. Esto se debe a que la política de límite de acceso de la principal en example.com estaría 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 principales vinculadas a sus principales.

Interacciones de políticas

IAM evalúa cada política de límite de acceso de las principales en combinación con tus políticas de permiso y de denegación, y con tus otras políticas de límite de acceso de las principales. Todas estas políticas se usan para determinar si un principal puede acceder a un recurso.

Interacción con otros tipos de políticas

Cuando una principal intenta acceder a un recurso, IAM evalúa todos los límites de acceso de las principales relevantes para ver si la principal puede acceder al recurso. Si alguna de estas políticas indica que la principal no debería poder acceder al recurso, IAM impedirá el acceso.

Como resultado, si una política de límite de acceso de las principales impediría que una principal acceda a un recurso, IAM le impedirá acceder a ese recurso, independientemente de las políticas de permiso y denegación adjuntas al recurso.

Además, las políticas de límite de acceso de las principales por sí solas no les otorgan acceso a los recursos. Si bien las políticas de límite de acceso de las principales pueden hacer que una principal sea apta para acceder a un recurso, solo las políticas de permisos pueden otorgarle acceso a la principal.

Para obtener más información sobre la evaluación de políticas de IAM, consulta Evaluación de políticas.

Interacción entre las políticas de límite de acceso de las principales

Si alguna política de límite de acceso de las principales hace que una principal sea apta para acceder a un recurso, entonces la principal es apta para acceder a ese recurso, independientemente de las otras políticas de límite de acceso de las principales a las que esté sujeta. Como resultado, si una principal ya está sujeta a una política de límite de acceso de las principales, no puedes agregar políticas de límite de acceso de las principales para reducir el acceso de una principal.

Por ejemplo, imagina que una principal, Dana (dana@example.com), está sujeta a una sola política de límite de acceso de la principal, prod-projects-policy. Esta política hace que las principales sean aptas para acceder a los recursos en prod-project. Dana está sujeta a esta política porque está vinculada al conjunto de principales de su organización.

Creas una nueva política de límite de acceso de las principales, dev-staging-projects-policy, que hace que las principales sean aptas para acceder a los recursos en dev-project y staging-project, y, luego, la vinculas al conjunto de principales de la organización.

Como resultado de estas políticas de límite de acceso de las principales, Dana es apta para acceder a los recursos en dev-project, staging-project y prod-project.

Si quieres reducir los recursos a los que Dana puede acceder, debes modificar o quitar las Políticas de Límite de Acceso de las Principales a las que está sujeta.

Por ejemplo, puedes editar dev-staging-projects-policy para que no haga que las entidades principales sean aptas para acceder a los recursos en dev-project. Luego, Dana solo podría acceder a los recursos en staging-project y prod-project.

Como alternativa, puedes quitar prod-projects-policy borrando la vinculación de la política que la vincula al conjunto de principales de la organización. Luego, Dana solo podría acceder a los recursos de dev-project y staging-project.

Sin embargo, estos cambios no solo afectan a Dana, sino también a los demás principales sujetos a las políticas y vinculaciones modificadas del límite de acceso de principales. Si deseas reducir los recursos a los que puede acceder una sola principal, usa vinculaciones de políticas condicionales.

Herencia de políticas

Las políticas de límite de acceso de las principales se adjuntan a conjuntos de principales, no a los recursos de Resource Manager. Como resultado, no se heredan a través de la jerarquía de recursos de la misma manera que las políticas de permisos y de denegación.

Sin embargo, los conjuntos principales de los recursos superiores de Resource Manager, es decir, 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 principales.

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

• 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 de principales de estos recursos contienen las siguientes identidades:

Como resultado, las siguientes principales se ven afectadas por las siguientes políticas de límite de acceso de la principal:

• 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 de las principales vinculadas a cualquiera de esos conjuntos de principales.

• Una cuenta de servicio 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.

Políticas de límite de acceso de las principales y recursos almacenados en caché

Algunos Google Cloud 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 el 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á en caché, el límite de acceso de la principal no puede impedir que las principales vean el recurso.
• Si el recurso no está almacenado en caché, el límite de acceso de la principal impide que las principales no aptas vean el recurso.

En todos los casos, las políticas de límite de acceso de las principales impiden que las principales no aptas modifiquen o borren recursos visibles públicamente.

Estructura de una política de límite de acceso de las principales

Una política de límite de acceso de la principal es una colección de metadatos y detalles de la política de límite de acceso de 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": "1"
  }
}

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 principales.

Metadatos

Las políticas de límite de acceso de las principales 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 las principales.
• 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 las principales.
• 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 de la principal.
• updateTime: Es la fecha y hora en que se actualizó por última vez la política de límite de acceso de las principales.

Detalles

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

• rules: Es una lista de reglas de límite de acceso principal que definen los recursos a los que pueden acceder las 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 Principales 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 principal 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 principal determina qué permisos puede bloquear la política de límite de acceso de la principal.

  Si deseas obtener más información sobre las versiones de la política de límite de acceso de la principal, consulta Versiones de aplicación de límites de acceso de las principales en esta página.

Estructura de una vinculación de política

Una vinculación de política para una política de límite de acceso de la principal contiene el nombre de una política, el nombre del conjunto de principales al que se vinculará la política y metadatos que describen la vinculación de la política. 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 se aplique la política para 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ítica. En el caso de las vinculaciones de políticas para las políticas de límite de acceso de las principales, este valor siempre es PRINCIPAL_ACCESS_BOUNDARY.

• policy: Es la política de límite de acceso de las principales que se vinculará al conjunto de principales objetivo.

• policyUid: Es un ID único asignado a la política de límite de acceso de las principales 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ímites y condiciones de acceso de la principal 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.

Casos de uso

A continuación, se indican situaciones comunes en las que tal vez quieras usar políticas de límite de acceso de las principales y ejemplos de las políticas de límite de acceso de las principales y las vinculaciones de políticas que podrías crear en cada situación. Para obtener información sobre cómo crear Políticas de Límite de Acceso de las Principales y vincularlas a conjuntos de principales, consulta Crea y aplica Políticas de Límite de Acceso de las Principales.

Cómo hacer que las principales sean aptas para acceder a los recursos de tu organización

Puedes usar una política de límite de acceso de las principales para que las principales de tu organización sean aptas para acceder a los recursos dentro de ella. Si esta es la única política de límite de acceso de las principales a la que están sujetas las principales de tu organización, la política de límite de acceso de las principales también hará que las principales de tu organización no sean aptas para acceder a recursos fuera de tu organización.

Por ejemplo, imagina que deseas que todas las principales de la organización example.com sean aptas para acceder a los recursos dentro de example.com y no sean aptas para acceder a los recursos de otras organizaciones. Los principales que se encuentran en example.com incluyen todas las identidades del dominio example.com, todos los grupos de identidades para cargas de trabajo en example.com y todas las cuentas de servicio y los grupos de identidades para cargas de trabajo en cualquier proyecto de example.com.

No tienes ninguna política de límite de acceso de las principales que se aplique a ninguna de las principales de tu organización. Como resultado, todas las principales son aptas para acceder a todos los recursos.

Para que las principales sean aptas para acceder a los recursos en example.com y no aptas para acceder a los recursos fuera de example.com, crea una política de límite de acceso de las principales que haga que las principales sean aptas para acceder a los recursos en example.com:

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
  "displayName": "Boundary for principals in example.org",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example.org",
        "resources": [
            "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

Luego, crea una vinculación de políticas para vincular esta política al conjunto de principales de la organización:

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
  "displayName": "Bind policy to all principals in example.com",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only"
}

Cuando se vincula al conjunto de principales de la organización, esta política hace que todos los principales de example.com sean aptos para acceder a los recursos de example.com. Dado que esta es la única política de límite de acceso de las principales a la que están sujetas estas principales, la política también hace que las principales de example.com no sean aptas para acceder a recursos fuera de tu organización. Esto significa que no pueden usar permisos que están bloqueados por la política de límite de acceso de la principal para acceder a recursos fuera de example.com, incluso si tienen esos permisos en esos recursos.

Habilita las cuentas de servicio para que sean aptas para los recursos en un solo proyecto

Puedes crear una política de límite de acceso de la principal para que las cuentas de servicio de un proyecto específico sean aptas para acceder a los recursos dentro de ese proyecto.

Si esta es la única política de límite de acceso de las principales a la que están sujetas las cuentas de servicio, estas solo podrán acceder a los recursos dentro de ese proyecto.

Por ejemplo, imagina que tienes un proyecto, example-dev, con el número de proyecto 901234567890. Quieres asegurarte de que las cuentas de servicio en example-dev solo sean aptas para acceder a los recursos en example-dev.

Tienes una política de límite de acceso de la principal que hace que todas las principales de tu organización, incluidas las cuentas de servicio en example-dev, sean aptas para acceder a los recursos en example.com. Para ver cómo se ve este tipo de política, consulta Cómo hacer que los principales sean aptos para acceder a los recursos de tu organización.

Para que las cuentas de servicio en example-dev no sean aptas para acceder a recursos fuera de example-dev, primero debes crear una política de límite de acceso de las principales que haga que las principales sean aptas para acceder a recursos en example-dev.

{
  "name": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "displayName": "Boundary for principals in example-dev",
  "details": {
    "rules": [
      {
        "description": "Principals are only eligible to access resources in example-dev",
        "resources": [
          "//cloudresourcemanager.googleapis.com/projects/example-dev"
        ],
        "effect": "ALLOW"
      }
    ],
    "enforcementVersion": "1"
  }
}

Luego, crea una vinculación de política para vincular esta política a todas las principales en example-dev y agrega una condición para que la vinculación de política solo se aplique a las cuentas de servicio:

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-dev-only-binding",
  "displayName": "Bind policy to all service accounts in example-dev",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/projects/example-dev"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-dev-only",
  "condition": {
    "title": "Only service accounts",
    "description": "Only enforce the policy if the principal in the request is a service account",
    "expression": "principal.type == 'iam.googleapis.com/ServiceAccount'"
  }
}

Sin embargo, esta política por sí sola no cambia los recursos a los que pueden acceder las cuentas de servicio. Esto se debe a que existe una política de límite de acceso de la principal que hace que todas las principales de example.com sean aptas para acceder a todos los recursos de example.com. Las políticas de límite de acceso de las principales son aditivas, por lo que las cuentas de servicio en example-dev aún pueden acceder a todos los recursos en example.com.

Para garantizar que las cuentas de servicio en example-dev sean solo aptas para acceder a los recursos en example-dev, debes agregar una condición a la vinculación de políticas para la política de límite de acceso de las principales existente que impida que se aplique a las cuentas de servicio, incluidas las cuentas de servicio predeterminadas, en example-dev:

{
  "name": "organizations/0123456789012/locations/global/policyBindings/example-org-only-binding",
  "displayName": "Bind policy to all principals in example.com",
  "target": {
    "principalSet": "//cloudresourcemanager.googleapis.com/organizations/0123456789012"
  },
  "policyKind": "PRINCIPAL_ACCESS_BOUNDARY",
  "policy": "organizations/0123456789012/locations/global/principalAccessBoundaryPolicies/example-org-only",
  "condition": {
    "title": "Exempt example-dev service accounts",
    "description": "Don't enforce the policy for service accounts in the example-dev project",
    "expression": "principal.type != 'iam.googleapis.com/ServiceAccount' || !principal.subject.endsWith('@example-dev.iam.gserviceaccount.com') || !principal.subject == 'example-dev@appspot.gserviceaccount.com || !principal.subject == '901234567890-compute@developer.gserviceaccount.com'"
  }
}

Ahora, las cuentas de servicio en example-dev solo son aptas para acceder a los recursos en example-dev. Se les impide usar permisos que están bloqueados por la política de límite de acceso de la principal para acceder a recursos fuera de example-dev, incluso si tienen esos permisos en esos recursos.

Más adelante, si deseas aumentar los recursos a los que pueden acceder estas cuentas de servicio, puedes agregar recursos adicionales a la política de example-dev-only o crear una política adicional de límite de acceso de la principal y vincularla a las cuentas de servicio.

¿Qué sigue?

• Obtén más información para crear y aplicar Políticas de Límite de Acceso de las Principales.
• Revisa el permiso que bloquea cada versión de aplicación de la política de límite de acceso de la principal.