Políticas de límites de acceso de principales

Las políticas de límites de acceso de principales (PAB) te permiten definir los recursos a los que pueden acceder los 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 filtraciones de datos.

Para obtener información sobre los otros tipos de políticas de control de acceso que ofrece Gestión de Identidades y Accesos (IAM), consulta Tipos de políticas.

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

De forma predeterminada, las entidades principales pueden acceder a cualquier Trusted Cloud by S3NS recurso. Esto significa que, si una entidad tiene un permiso en el recurso y no se le ha denegado, puede usarlo para acceder al recurso.

Con las políticas de límites de acceso de principales, puedes definir los recursos a los que puede acceder un principal. Si una política de límites de acceso de principales hace que un principal no pueda acceder a un recurso, su acceso a ese recurso se limitará, independientemente de los roles que se le hayan concedido.

Cuando los principales intentan acceder a recursos para los que no tienen permiso, las políticas de límites de acceso de principales pueden bloquear algunos permisos de Gestión de Identidades y Accesos (IAM), pero no todos. Para obtener más información sobre los permisos que se bloquean, consulta Permisos que puede bloquear el límite de acceso de la cuenta principal.

Las políticas de límites de acceso de principales se componen de reglas de límites de acceso de principales. Cada regla de límite de acceso de principales define un conjunto de recursos a los que pueden acceder los principales afectados. Puedes crear hasta 1000 políticas de límite de acceso de principales en tu organización.

Después de crear una política de límite de acceso de principales, crea un enlace de política para aplicar la política a un conjunto de principales.

Un principal puede estar sujeto a una o varias políticas de límites de acceso de principales. Cada entidad principal solo puede acceder a los recursos que se indican en esas políticas. En el caso del resto de los recursos, el acceso de la entidad a ese recurso está limitado, aunque le asignes roles en ese recurso.

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

• El director Tal (tal@example.com) forma parte de la organización de Google Workspace example.com.
• A Tal se le asigna el rol Administrador de Storage (roles/storage.admin) en un segmento de Cloud Storage de otra organización, cymbalgroup.com. Este rol contiene el permiso storage.objects.get, que es necesario para ver los objetos del segmento.
• No hay ninguna política de denegación en cymbalgroup.com que impida que Tal use el permiso storage.objects.get.

Con solo las políticas de permitir y denegar, example.com no puede impedir que Tal vea los objetos de este segmento externo. Ningún principal de example.com tiene permiso para editar la política de permisos del segmento, por lo que no puede revocar el rol de Tal. Tampoco tienen permiso para crear políticas de denegación en cymbalgroup.com, por lo que no pueden usar una política de denegación para impedir que Tal acceda al contenedor.

Sin embargo, con las políticas de límite de acceso de principales, los administradores de example.com pueden asegurarse de que Tal no pueda ver objetos en el segmento cymbalgroup.com ni en ningún otro segmento fuera de example.com. Para ello, los administradores pueden crear una política de límite de acceso de principales que indique que los principales de example.com solo pueden acceder a los recursos de example.com. Después, pueden crear un enlace de política para adjuntar esta política a todas las entidades de la organización example.com. Con esta política, Tal no podrá ver los objetos del segmento cymbalgroup.com, aunque tenga asignado el rol Administrador de Storage en el segmento.

Evaluación de cierre por fallo

Las políticas de límites de acceso de principales fallan cerradas. Esto significa que, si IAM no puede evaluar una política de límite de acceso de un principal al evaluar el acceso de un principal, IAM impide que el principal acceda al recurso.

El motivo más habitual por el que IAM no puede evaluar las políticas de límites de acceso de principales es que los detalles de un 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, pide al nuevo principal que espere y que intente acceder al recurso de nuevo más tarde.

Permisos que bloquean las políticas de límites de acceso de principales

Cuando las entidades intentan acceder a un recurso al que no pueden acceder, las políticas de límite de acceso de la entidad les impiden usar algunos, pero no todos, los permisos de Gestión de Identidades y Accesos (IAM) para acceder al recurso.

Si una política de límites de acceso de principales bloquea un permiso, IAM aplica políticas de límites de acceso de principales para ese permiso. Es decir, impide que las entidades que no cumplan los requisitos para acceder a un recurso utilicen ese permiso para acceder al recurso.

Si una política de límites de acceso de principales no bloquea un permiso, las políticas de límites de acceso de principales no influyen en si los principales pueden usar el permiso.

Por ejemplo, imagina que a un principal, Lee (lee@example.com), se le asigna el rol de desarrollador de Dataflow (roles/dataflow.developer). Este rol incluye el permiso dataflow.jobs.snapshot, que permite a Lee crear snapshots de tareas de Dataflow. Lee también está sujeto a una política de límites de acceso de principales que le impide acceder a recursos fuera de example.com. Sin embargo, si las políticas de límite de acceso de principales no bloquean el permiso dataflow.jobs.snapshot, Lee podrá seguir haciendo capturas de los trabajos de Dataflow en organizaciones ajenas a example.com.

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

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

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

Periódicamente, Gestión de identidades y accesos añade nuevas versiones de la aplicación de límites de acceso de principales 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, debes actualizar tus políticas de límite de acceso de principales para usar la nueva versión. Si quieres que la versión de la medida de cumplimiento se actualice automáticamente cuando se publiquen nuevas versiones, puedes usar el valor latest al crear la política. Sin embargo, no recomendamos usar este valor, ya que podría provocar que las entidades de seguridad perdieran el acceso a los recursos de forma inesperada.

Para ver una lista completa de los permisos que bloquea cada versión de la medida de protección, consulta Permisos que bloquean las políticas de límite de acceso de la entidad principal.

Vincular políticas de límites de acceso de principales a conjuntos de principales

Para vincular una política de límites de acceso de principales a un conjunto de principales, crea un enlace de política que especifique tanto la política de límites de acceso de principales que quieras aplicar como el conjunto de principales al que quieras aplicarla. Después de vincular la política a un conjunto de entidades principales, las entidades principales de ese conjunto solo podrán acceder a los recursos incluidos en las reglas de la política de límites de acceso de principales.

Puedes vincular una política de límites de acceso de principales a tantos conjuntos de principales como quieras. Cada conjunto de principales puede tener asociadas hasta 10 políticas de límite de acceso principal.

Solo puedes crear enlaces para políticas de límites de acceso de principales que ya existan. Si intentas crear un enlace para una política de límites de acceso de principales eliminada, no podrás hacerlo. Si has eliminado recientemente una política de límite de acceso de principal, a veces puedes crear una vinculación correctamente, pero la vinculación no tendrá ningún efecto. IAM limpia estas vinculaciones automáticamente.

Para saber cómo gestionar las políticas de límites de acceso de principales, consulta Crear y aplicar políticas de límites de acceso de principales.

Conjuntos de principales admitidos

En la siguiente tabla se enumeran los tipos de conjuntos de principales a los que puede asociar políticas de límite de acceso de principales. Cada fila contiene lo siguiente:

• El tipo de conjunto de principales
• Los principales de ese tipo de conjunto de principales
• El formato de los IDs de ese tipo de conjunto de principales
• El recurso de Resource Manager (proyecto, carpeta u organización) que contiene los enlaces de políticas del tipo de conjunto de principales

Asignaciones de políticas condicionales para políticas de límites de acceso de principales

Puede usar expresiones de condición en las vinculaciones de políticas de las políticas de límites de acceso de la entidad principal para definir con mayor precisión a qué entidades principales se aplica la política.

Las expresiones de condición de las vinculaciones de políticas constan de una o varias instrucciones unidas por un máximo de 10 operadores lógicos (&&, || o !). Cada instrucció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.

Puede 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 de 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 de un grupo de identidades de carga de trabajo. Puede usar condiciones con este atributo para controlar a qué tipos de principales se aplica una política de límites de acceso de principales.

  Por ejemplo, si añades la siguiente expresión de condición a un enlace de una política de límites de acceso de 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 de seguridad en la solicitud, por ejemplo, cruz@example.com. Puedes usar condiciones con este atributo para controlar exactamente qué principales están sujetos a una política de límite de acceso principal.

  Por ejemplo, si añades la siguiente expresión de condición a un enlace de una política de límites de acceso de 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 puede usar en estas condiciones, consulte la referencia del atributo de estado.

Ejemplo: usar condiciones para reducir los recursos a los que puede acceder una principal

Una de las formas de usar las condiciones en las vinculaciones de políticas de límites de acceso de principales es reducir los recursos a los que puede acceder un principal.

Supongamos que tienes una cuenta de servicio, dev-project-service-account, con la dirección de correo dev-project-service-account@dev-project.s3ns-system.iam.gserviceaccount.com. Esta cuenta de servicio está sujeta a una política de límite de acceso principal que permite que los principales accedan 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 pueda 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 pueden acceder otras entidades principales del conjunto de entidades principales example.com.

Para hacer este cambio, sigue el procedimiento para reducir los recursos a los que pueden acceder los principales, pero añade una condición al enlace de la política en lugar de eliminarlo:

1. Confirmas que la única política de límites de acceso de principales a la que está sujeta dev-project-service-account es la que permite que los principales accedan a todos los recursos de example.com.

2. Crea una política de límite de acceso de principal que permita a los principales acceder a los recursos de dev-project y la adjunta al conjunto de principales de dev-project. Usa la siguiente condición en la vinculación de la política para asegurarte de 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.s3ns-system.iam.gserviceaccount.com'"
   }
   

3. Eximes a dev-project-service-account de la política de límites de acceso de principales que permite que los principales accedan a todos los recursos de example.com. Para ello, añade la siguiente condición a la vinculación de la política que asocia esa política de límites de acceso de 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.s3ns-system.iam.gserviceaccount.com' || principal.type != 'iam.googleapis.com/ServiceAccount'"
   }
   

   Para saber cómo actualizar las políticas de límites de acceso de principales, consulta Editar políticas de límites de acceso de principales.

Después de añadir esta condición a la vinculación de la política, dev-project-service-account ya no podrá acceder a todos los recursos de example.com, sino solo a los de dev-project.

Vinculaciones de políticas entre organizaciones

No puedes crear un enlace de política entre organizaciones para una política de límite de acceso de principales. Una vinculación de política entre organizaciones es una vinculación de política que vincula una política de una organización a un conjunto de principales de otra organización.

Gestión de identidades y accesos elimina periódicamente los enlaces de políticas entre organizaciones. Las vinculaciones de políticas entre organizaciones pueden producirse cuando mueves un proyecto de una organización a otra. Por ejemplo, supongamos que se da la siguiente situación:

• Tienes un proyecto, example-project, en la organización example.com.
• Quieres que las entidades de example-project puedan acceder a los recursos de example.com. Para ello, crea una política de límites de acceso de principales en example.com que permita a los principales acceder a los recursos de example.com y vincula esa política al conjunto de principales de example-project.
• Mueves example-project de example.com a cymbalgroup.com.

En esta situación, al mover el proyecto se crearía un enlace de política entre organizaciones. Esto se debe a que la política de límites de acceso de principales de example.com se asociaría a un conjunto de principales de cymbalgroup.com. Si no eliminas el enlace manualmente, IAM lo eliminará automáticamente con el tiempo. Eliminar esta vinculación ayuda a garantizar que los administradores de cymbalgroup.com tengan acceso a todas las políticas de límites de acceso de principales vinculadas a sus principales.

Interacciones con las políticas

IAM evalúa cada política de límites de acceso de principales en combinación con tus políticas de permitir y denegar, y con tus otras políticas de límites de acceso de principales. Todas estas políticas se usan para determinar si una entidad puede acceder a un recurso.

Interacción con otros tipos de políticas

Cuando un principal intenta acceder a un recurso, IAM evalúa todas las políticas de límites de acceso de principales, de permiso y de denegación relevantes para determinar si el principal tiene permiso para acceder al recurso. Si alguna de estas políticas indica que la entidad principal no debería poder acceder al recurso, la gestión de identidades y accesos impide el acceso.

Por lo tanto, si una política de límites de acceso de principales impide que un principal acceda a un recurso, IAM le impedirá acceder a ese recurso, independientemente de las políticas de permiso y de denegación asociadas al recurso.

Además, las políticas de límites de acceso de principales por sí solas no dan acceso a los recursos a las entidades principales. Aunque las políticas de límites de acceso de principales pueden hacer que un principal pueda acceder a un recurso, solo las políticas de permiso pueden concederle acceso al recurso.

Para obtener más información sobre la evaluación de políticas de gestión de identidades y accesos, consulta Evaluación de políticas.

Interacción entre políticas de límites de acceso de principales

Si alguna política de límites de acceso de principales permite que un principal acceda a un recurso, ese principal podrá acceder a ese recurso, independientemente de las demás políticas de límites de acceso de principales a las que esté sujeto. Por lo tanto, si un principal ya está sujeto a una política de límites de acceso de principales, no puedes añadirle más políticas de este tipo para reducir su acceso.

Por ejemplo, supongamos que un principal, Dana (dana@example.com), está sujeto a una única política de límites de acceso de principales, prod-projects-policy. Esta política permite que las entidades accedan a los recursos de prod-project. Dana está sujeta a esta política porque está vinculada al conjunto de principales de su organización.

Crea una política de límite de acceso de la entidad principal, dev-staging-projects-policy, que permite que las entidades principales accedan a los recursos de dev-project y staging-project, y, a continuación, la vincula al conjunto de entidades principales de la organización.

Como resultado de estas políticas de límites de acceso de principales, Dana puede acceder a los recursos de dev-project, staging-project y prod-project.

Si quiere reducir los recursos a los que puede acceder Dana, debe modificar o eliminar las políticas de límite de acceso de principales a las que está sujeta.

Por ejemplo, puedes editar dev-staging-projects-policy para que los principales no puedan acceder a los recursos de dev-project. En ese caso, Dana solo podría acceder a los recursos de staging-project y prod-project.

También puedes quitar prod-projects-policy eliminando la vinculación de la política que la vincula al conjunto de principales de la organización. En ese caso, 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 las demás entidades sujetas a las políticas y las vinculaciones de límites de acceso de la entidad modificadas. Si quieres reducir los recursos a los que puede acceder una sola entidad, usa enlaces de políticas condicionales.

Herencia de políticas

Las políticas de límites de acceso de principales se adjuntan a conjuntos de principales, no a recursos de Resource Manager. Por lo tanto, no se heredan a través de la jerarquía de recursos de la misma forma que las políticas de permitir y denegar.

Sin embargo, los conjuntos de principales de los recursos principales de Resource Manager (es decir, las carpetas y las organizaciones) siempre incluyen todos los principales de los conjuntos de principales de sus elementos descendientes. 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 carpetas o las organizaciones principales.

Por ejemplo, supongamos que tienes una organización llamada 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 principales de estos recursos contienen las siguientes identidades:

Por lo tanto, los siguientes principales se ven afectados por las siguientes políticas de límites de acceso de principales:

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

• Una cuenta de servicio de project-1 está 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 principales vinculadas a cualquiera de esos conjuntos de principales.

• Una cuenta de servicio de project-3 está 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 principales vinculadas a cualquiera de esos conjuntos de principales.

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

Algunos Trusted Cloud by S3NS servicios almacenan en caché recursos visibles públicamente. Por ejemplo, Cloud Storage almacena en caché los objetos que se pueden leer públicamente.

Si el límite de acceso de la entidad de seguridad puede impedir que las entidades de seguridad no aptas vean un recurso visible públicamente, depende de si el recurso está almacenado en caché:

• Si el recurso está en la caché, el límite de acceso de la entidad principal no puede impedir que las entidades principales vean el recurso.
• Si el recurso no está en la caché, el límite de acceso de la entidad principal impide que las entidades principales no aptas vean el recurso.

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

Estructura de una política de límites de acceso de principales

Una política de límites de acceso de principales es un conjunto de metadatos y detalles de la política de límites de acceso de principales. 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 entidades principales afectadas.

Por ejemplo, la siguiente política de límite de acceso de principales hace que los principales sujetos a la política puedan 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 de los metadatos y los detalles de una política de límite de acceso principal.

Metadatos

Las políticas de límites de acceso de principales contienen los siguientes metadatos:

• name: nombre de la política de límites de acceso de principales. Este nombre tiene el formato organizations/ORGANIZATION_ID/locations/global/principalAccessBoundaryPolicies/PAB_POLICY_ID, donde ORGANIZATION_ID es el ID numérico de la organización en la que se creó la política de límites de acceso de principales y PAB_POLICY_ID es el ID alfanumérico de la política de límites de acceso de principales.
• uid: ID único asignado a la política de límites de acceso de principales.
• etag: identificador del estado actual de la política. Este valor cambia cuando actualiza la política. Para evitar que se produzcan conflictos en las actualizaciones, el valor de etag debe coincidir con el valor almacenado en IAM. Si los valores de etag no coinciden, la solicitud fallará.
• displayName: nombre legible de la política de límites de acceso de principales.
• annotations: opcional. Lista de pares clave-valor definidos por el usuario. Puedes usar estas anotaciones para añadir metadatos adicionales a la política, como quién la ha creado o si se ha implementado mediante una canalización automatizada. Para obtener más información sobre las anotaciones, consulta Anotaciones.
• createTime: hora en la que se creó la política de límites de acceso de principales.
• updateTime: hora en la que se actualizó por última vez la política de límites de acceso de principales.

Detalles

Cada política de límites de acceso de principales contiene un campo details. Este campo contiene las reglas de límites de acceso de principales y la versión de la aplicación:

• rules: lista de reglas de límite de acceso de principales que definen los recursos a los que pueden acceder los principales afectados. Cada regla contiene los siguientes campos:

  • description: descripción legible por humanos de la regla.

  • resources: lista de recursos de Resource Manager (proyectos, carpetas y organizaciones) a los que quieres que puedan acceder las principales. Cualquier principal que esté sujeto a esta política puede acceder a estos recursos.

    Cada política de límite de acceso de principales puede hacer referencia a un máximo de 500 recursos en todas las reglas de la política.

  • effect: la relación que tienen las entidades con los recursos que se indican en el campo resources. El único efecto que puedes especificar en las reglas de límite de acceso de principales es "ALLOW". Esta relación permite que las entidades principales accedan a los recursos que se indican en la regla.

• enforcementVersion: la versión de la aplicación que usa Gestión de Identidades y Accesos (IAM) al aplicar la política. La versión de la política de límites de acceso de principales determina qué permisos puede bloquear la política de límites de acceso de principales.

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

Estructura de una vinculación de políticas

Un enlace de política de una política de límites de acceso de un principal contiene el nombre de una política, el nombre del conjunto de principales al que se va a vincular la política y los metadatos que describen el enlace de la política. También puede contener condiciones que modifiquen las entidades exactas a las que se aplica la política.

Por ejemplo, el siguiente enlace de política vincula la política example-policy a todos los principales de la organización example.com, que tiene el ID 0123456789012. El enlace de la política también contiene una condición que impide que la política se aplique a la entidad 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 enlace de política contiene los siguientes campos:

• name: nombre de la vinculación de la política. Este nombre tiene el formato RESOURCE_TYPE/RESOURCE_ID/locations/global/policyBindings/BINDING_ID, donde RESOURCE_TYPE/RESOURCE_ID es el tipo y el ID del recurso superior de la vinculación de la política, y BINDING_ID es el ID alfanumérico de la vinculación de la política.
• uid: ID único asignado a la vinculación de la política.
• etag: identificador del estado actual de la política. Este valor cambia cuando actualiza la política. Para evitar que se produzcan conflictos en las actualizaciones, el valor de etag debe coincidir con el valor almacenado en IAM. Si los valores de etag no coinciden, la solicitud fallará.
• displayName: nombre legible por personas de la vinculación de la política.
• annotations: opcional. Lista de pares clave-valor definidos por el usuario. Puedes usar estas anotaciones para añadir metadatos adicionales a la vinculación de la política. Por ejemplo, quién ha creado la vinculación de la política o si la ha implementado una canalización automatizada. Para obtener más información sobre las anotaciones, consulta Anotaciones.

• target: el principal al que se va a vincular la política. El valor tiene el formato {"principalSet": PRINCIPAL_SET}, donde PRINCIPAL_SET es el ID del conjunto de principales al que quieres vincular la política.

  Cada destino puede tener hasta 10 políticas vinculadas.

• policyKind: el tipo de política al que hace referencia el enlace de la política. En el caso de las vinculaciones de políticas de límites de acceso de principales, este valor siempre es PRINCIPAL_ACCESS_BOUNDARY.

• policy: la política de límites de acceso de principales que se va a vincular al conjunto de principales de destino.

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

• condition: opcional. Una expresión lógica que afecta a los principales para los que IAM aplica la política. Si la condición se evalúa como verdadera o no se puede evaluar, Gestión de Identidades y Accesos aplica la política al principal que hace la solicitud. Si la condición se evalúa como falsa, Gestión de Identidades y Accesos no aplica la política al principal. Para obtener más información, consulta la sección Límites y condiciones de acceso de la entidad principal de esta página.

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

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

Casos prácticos

A continuación, se muestran situaciones habituales en las que puede ser útil usar políticas de límites de acceso de principales, así como ejemplos de políticas de límites de acceso de principales y de enlaces de políticas que puede crear en cada situación. Para saber cómo crear políticas de límites de acceso de principales y cómo enlazarlas con conjuntos de principales, consulta Crear y aplicar políticas de límites de acceso de principales.

Hacer que las entidades puedan acceder a los recursos de tu organización

Puedes usar una política de límite de acceso de una entidad para que las entidades de tu organización puedan acceder a los recursos de tu organización. Si esta es la única política de límite de acceso de principales a la que están sujetos los principales de tu organización, también hará que los principales de tu organización no puedan acceder a recursos externos a ella.

Por ejemplo, supongamos que quieres que todos los principales de la organización example.com puedan acceder a los recursos de example.com y no puedan acceder a los recursos de otras organizaciones. Los principales que están en example.com incluyen todas las identidades del dominio example.com, todos los grupos de identidades de personal de example.com y todas las cuentas de servicio y grupos de identidades de carga de trabajo de cualquier proyecto de example.com.

No tienes ninguna política de límite de acceso de principales que se aplique a ninguno de los principales de tu organización. Por lo tanto, todas las entidades principales pueden acceder a todos los recursos.

Para que los principales puedan acceder a los recursos de example.com y no puedan acceder a los recursos que están fuera de example.com, crea una política de límite de acceso principal que permita a los principales acceder a los recursos de 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"
  }
}

A continuación, crea un enlace de política 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 permite que todos los principales de example.com puedan acceder a los recursos de example.com. Como esta es la única política de límites de acceso de principales a la que están sujetos estos principales, la política también hace que los principales de example.com no puedan 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 principal para acceder a recursos fuera de example.com, aunque tengan esos permisos en esos recursos.

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

Puedes crear una política de límite de acceso de principales para que las cuentas de servicio de un proyecto específico puedan acceder a los recursos de ese proyecto.

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

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

Tienes una política de límite de acceso de principales que permite que todos los principales de tu organización, incluidas las cuentas de servicio de example-dev, puedan acceder a los recursos de example.com. Para ver cómo es este tipo de política, consulta Hacer que las principales puedan acceder a los recursos de tu organización.

Para que las cuentas de servicio de example-dev no puedan acceder a recursos fuera de example-dev, primero debes crear una política de límite de acceso de principales que permita a los principales acceder a los recursos de 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"
  }
}

A continuación, crea un enlace de política para vincular esta política a todas las entidades de example-dev y añade una condición para que el enlace 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 hay una política de límite de acceso de principales que permite que todos los principales de example.com accedan a todos los recursos de example.com. Las políticas de límite de acceso de principales son aditivas, por lo que las cuentas de servicio de example-dev siguen pudiendo acceder a todos los recursos de example.com.

Para asegurarte de que las cuentas de servicio de example-dev solo puedan acceder a los recursos de example-dev, debes añadir una condición al enlace de política de la política de límite de acceso de la entidad de seguridad principal para evitar que se aplique a las cuentas de servicio, incluidas las cuentas de servicio predeterminadas, de 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.s3ns-system.iam.gserviceaccount.com') || !principal.subject == 'example-dev@appspot.s3ns-system.iam.gserviceaccount.com || !principal.subject == '901234567890-compute@developer.s3ns-system.iam.gserviceaccount.com'"
  }
}

Ahora, las cuentas de servicio de example-dev solo pueden acceder a los recursos de example-dev. No pueden usar permisos bloqueados por la política de límite de acceso principal para acceder a recursos fuera de example-dev, aunque tengan esos permisos en esos recursos.

Más adelante, si quieres aumentar los recursos a los que pueden acceder estas cuentas de servicio, puedes añadir más recursos a la política example-dev-only o crear otra política de límite de acceso principal y vincularla a las cuentas de servicio.

Siguientes pasos

• Consulte cómo crear y aplicar políticas de límite de acceso de principales.
• Consulta el permiso que bloquea cada versión de la aplicación de la política de límites de acceso de principales.