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

Vista previa

Esta función está sujeta a las "Condiciones de las Ofertas de Fase Previa a la DG" de la sección Condiciones Generales del Servicio de las Condiciones Específicas del Servicio. Las funciones de fase previa a la DG están disponibles “tal cual” y podrían tener asistencia limitada. Para obtener más información, consulta las descripciones de la etapa de lanzamiento.

Las Políticas de Límite de Acceso de las Principales (PAB) te permiten restringir los recursos a los que pueden acceder las principales.

Por ejemplo, puedes usar políticas de límite de acceso de las principales para evitar que las 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, los principales son aptos para acceder a cualquier recurso de Google Cloud. Esto significa que, si una principal tiene un permiso en el recurso y no se le niega, puede usar ese permiso para acceder al recurso.

Con las políticas de límite de acceso de las principales, puedes restringir los recursos a los que puede acceder una principal. 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 qué permisos están bloqueados, consulta Permisos que puede bloquear el límite de acceso de las principales.

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, creas una vinculación de políticas para aplicarla 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 puede acceder a los recursos que se indican en esas políticas. Para todos los demás recursos, el acceso del principal a ese recurso es limitado, incluso si le otorgas roles a ese principal.

Debido a que las políticas de límite de acceso de las principales están asociadas con las principales y no con los recursos, puedes usarlas para evitar que las principales accedan a recursos que no te pertenecen. Por ejemplo, considera la siguiente situación:

• El director Tal ([e-mail]) forma parte de la organización de Google Workspace altostrat.com.
• A Tal se le otorga el rol de Administrador de almacenamiento (roles/storage.admin) en un bucket de Cloud Storage en una organización diferente, cymbalgroup.com. Este rol contiene el permiso storage.objects.get, que se requiere para ver los 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 las políticas de permiso y denegación, altostrat.com no puede impedir que Tal vea los objetos en este bucket externo. Ningún principal de altostrat.com tiene permiso para editar la política de permisos del bucket, por lo que no pueden 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 evitar que Tal acceda al bucket.

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

Evaluación de fail-open

Durante la versión preliminar de la política de límite de acceso de las principales, estas políticas fallan de forma abierta. Esto significa que, si IAM no puede evaluar una política de límite de acceso de las principales, la ignora y continúa evaluando las políticas de permiso y denegación relevantes.

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 las principales bloquea un permiso, IAM aplica las políticas de límite de acceso de las principales para ese permiso. En otras palabras, impide que los principales que no son aptos para acceder a un recurso usen ese permiso para acceder al recurso.

Si una política de límite de acceso de las principales no bloquea un permiso, las políticas de límite de acceso de las principales no tienen efecto en si las principales pueden usar el permiso.

Por ejemplo, imagina que a un principal, Lee ([e-mail]), se le otorga el rol de desarrollador de Dataflow (roles/dataflow.developer). Este rol incluye el permiso dataflow.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 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 del 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 las principales 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 las principales puede bloquear. Especificas la versión de aplicación cuando creas o actualizas una política de límite de acceso de las principales. Si no especificas una versión de aplicación forzosa, IAM usará la versión más reciente y seguirá usándola hasta que la actualices.

De forma periódica, IAM agrega nuevas versiones de aplicación de límites de acceso de las 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 forzosa, debes actualizar tus políticas de límite de acceso de las principales para usar la nueva versión. Si deseas que la versión de aplicación forzosa se actualice automáticamente a medida que se lanzan 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 los 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 las principales

Para vincular una Política de Límite de Acceso de las Principales a un conjunto de principales, crea una vinculación de políticas que especifique la Política de Límite de Acceso de las Principales que deseas aplicar y el conjunto de principales para el que deseas aplicarla. Después de vincular la política a un conjunto de principales, los principales de ese conjunto solo pueden acceder a los recursos que se incluyen 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.

Para obtener información sobre cómo administrar las Políticas de Límite de Acceso de las Principales, consulta Cómo crear y aplicar políticas de límite de acceso de las principales.

Conjuntos principales admitidos

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

• El tipo de conjunto principal
• Las cuentas principales de ese tipo de conjunto principal
• El formato de los IDs para ese tipo de conjunto de principales
• Es el recurso de Resource Manager (proyecto, carpeta u organización) que es superior a las vinculaciones de políticas para ese tipo de conjunto de principales.

Conjunto principal	Detalles	Recurso superior de las vinculaciones de políticas
Grupo de identidad de trabajadores	Contiene todas las identidades del grupo de identidad de personal especificado. Formato: //iam.googleapis.com/locations/global/workforcePools/WORKFORCE_POOL_ID	La organización que contiene el grupo de identidades de personal
Grupo de identidades para cargas de trabajo	Contiene todas las identidades del grupo de identidades para cargas de trabajo especificado. Formato: //iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/WORKLOAD_POOL_ID	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/WORKSPACE_ID Puedes encontrar el ID de tu lugar de trabajo con los siguientes métodos: Usa el comando gcloud organizations describe. El ID de tu lugar de trabajo se encuentra en el campo directoryCustomerId de la respuesta. Usa el método organizations.get en la API de Cloud Resource Manager. El ID de tu lugar de trabajo se encuentra en el campo directoryCustomerId de la respuesta. Consulta el ID de tu espacio de trabajo en la Consola del administrador. Este método requiere el rol de administrador avanzado de Google Workspace.	La organización asociada con el dominio de Google Workspace
Conjunto principal del proyecto	Contiene todas las cuentas de servicio y los grupos de identidades para cargas de trabajo en el proyecto especificado. Formato: //cloudresourcemanager.googleapis.com/projects/PROJECT_ID	El proyecto
Conjunto principal de la carpeta	Contiene todas las cuentas de servicio y todos los grupos de identidades para cargas de trabajo de cualquier proyecto en 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 de todos los dominios asociados con tu ID de cliente de Google Workspace Todos los grupos de identidad del personal de tu organización Todas las cuentas de servicio y los grupos de identidades para cargas de trabajo de cualquier proyecto de la organización Formato: //cloudresourcemanager.googleapis.com/organizations/ORGANIZATION_ID	La organización

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 consisten en una o más declaraciones que se unen con 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 encuentra 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 del principal en la solicitud, por ejemplo, [e-mail]. Puedes usar condiciones con este atributo para controlar exactamente qué principales están sujetos a 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 no se aplicará para el usuario [e-mail]:

  principal.subject != '[e-mail]'
  

Para obtener más información sobre los valores que puedes usar para estas condiciones, consulta la referencia de atributos de 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 reducir los recursos a los que puede acceder un solo principal.

Imagina que tienes una cuenta de servicio, dev-project-service-account, con la dirección de correo electrónico [e-mail]. Esta cuenta de servicio está sujeta a una política de límite de acceso de las principales que hace que los principales sean aptos 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, solo quieres que sea apto para acceder a los recursos 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 los principales pueden acceder, 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 las principales a la que está sujeto dev-project-service-account es la política que hace que las principales sean aptas para acceder a todos los recursos de example.com.

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

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

3. Exoneras a dev-project-service-account de la política de límite de acceso de las principales que hace que las principales sean aptas para acceder a todos los recursos de example.com. Para hacer esto, agrega la siguiente condición a la vinculación de políticas que adjunta la 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 != '[e-mail]' || 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 Cómo editar las Políticas de Límite de Acceso de las Principales.

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

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 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 lo impide.

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 a las principales acceso a los recursos. Si bien las políticas de límite de acceso de las principales pueden hacer que una principal sea apto para acceder a un recurso, solo las políticas de permisos pueden otorgarle al principal acceso al recurso.

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, 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 ([e-mail]), está sujeta a una sola política de límite de acceso de las principales, 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 principal de su organización.

Creas una nueva política de límite de acceso de las principales, dev-staging-projects-policy, que permite que las principales sean aptas para acceder a los recursos en dev-project y staging-project y, luego, la vinculas al conjunto principal 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 de 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 Dana está sujeta.

Por ejemplo, puedes editar dev-staging-projects-policy para que no haga que los principales sean aptos para acceder a los recursos en dev-project. Luego, Dana solo podría acceder a los recursos de 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. De esta manera, Dana solo podría acceder a los recursos de dev-project y staging-project.

Importante: Si quitas una Política de Límite de Acceso de las Principales para reducir el acceso de una principal, asegúrate de que esta siempre esté sujeta a al menos una Política de Límite de Acceso de las Principales. Si una principal no está sujeta a ninguna política de límite de acceso de las principales, es apta para acceder a todos los recursos de Google Cloud. Para obtener información sobre cómo reducir de forma segura el acceso de una principal, consulta Reduce los recursos a los que pueden acceder las principales.

Sin embargo, estos cambios no solo afectan a Dana, sino que también afectan a los otros principales que están sujetos a las políticas y vinculaciones de límite de acceso de las principales modificadas. Si deseas reducir los recursos a los que puede acceder un solo 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 lo hacen las políticas de permiso y 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 principal de un proyecto, también se incluye en los conjuntos principales de cualquier organización o carpeta superior.

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

• Una organización, example.com
• Un proyecto, project-1, que es un elemento secundario de la organización
• Una carpeta, folder-a, que es un elemento secundario 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:

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 y grupos de identidades para cargas de trabajo en project-1	Cuentas de servicio y grupos de identidades para cargas de trabajo en project-2	Cuentas de servicio y grupos de identidades para cargas de trabajo en project-3
Conjunto principal para example.com
Conjunto principal para folder-a
Conjunto principal para project-1
Conjunto principal para project-2
Conjunto principal para project-3

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

• 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 servicios de Google Cloud almacenan en caché recursos visibles públicamente. Por ejemplo, Cloud Storage almacena en caché los objetos que son de lectura pública.

El hecho de que el límite de acceso de las principales pueda 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é, el límite de acceso a 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 las principales 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 las principales es un conjunto de metadatos y detalles de la política de límite de acceso de las 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 principales afectadas.

Por ejemplo, la siguiente política de límite de acceso de las principales hace que las principales que están 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 las principales. 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 las principales y PAB_POLICY_ID es el ID alfanumérico de la política de límite de acceso de las principales.
• uid: Es un ID único asignado a la política de límite de acceso de las principales.
• etag: Es un identificador para el 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 etag no coinciden, la solicitud falla.
• displayName: Es un nombre legible por humanos para la política de límite de acceso de las principales.
• annotations: Opcional 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 una canalización automatizada la implementó. Para obtener más información sobre las anotaciones, consulta Anotaciones.
• createTime: Es el momento en que se creó la política de límite de acceso de las principales.
• updateTime: Es la última vez que se actualizó 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 de límite de acceso de las principales y la versión de aplicación forzosa:

• 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 por humanos 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 los principales tienen con los recursos que se enumeran en el campo resources. El único efecto que puedes especificar en las reglas de límite de acceso principal es "ALLOW". Esta relación hace que las principales sean aptas para acceder a los recursos que se enumeran 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 las principales determina qué permisos puede bloquear.

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

Estructura de una vinculación de políticas

Una vinculación de políticas para una política de límite de acceso de las principales contiene el nombre de una política, el nombre del conjunto de principales al que se vincula la política y los 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íticas 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 políticas también contiene una condición que evita que la política se aplique para el principal [e-mail].

{
  "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 [e-mail]",
    "expression": "principal.subject != '[e-mail]'"
  },
  "createTime": "2024-01-02T17:00:16Z",
  "updateTime": "2024-01-02T17:00:16Z"
}

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

• name: Es el nombre de la vinculación de políticas. 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 superior de la vinculación de políticas, y BINDING_ID es el ID alfanumérico de la vinculación de políticas.
• uid: Es un ID único asignado a la vinculación de políticas.
• etag: Es un identificador para el 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 etag no coinciden, la solicitud falla.
• displayName: Es un nombre legible por humanos para la vinculación de políticas.
• annotations: Opcional Una lista de pares clave-valor definidos por el usuario. Puedes usar estas anotaciones para agregar metadatos adicionales a la vinculación de políticas, por ejemplo, quién creó la vinculación de políticas o si una canalización automatizada la implementó. Para obtener más información sobre las anotaciones, consulta Anotaciones.

• target: Es el principal configurado para 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 objetivo puede tener hasta 10 políticas vinculadas a él.

• policyKind: Es el tipo de política a la que hace referencia la vinculación de políticas. Para las vinculaciones de 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 de destino.

• 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 para qué principales la 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 el principal que realiza la solicitud. Si la condición se evalúa como falsa, Identity and Access Management no aplica la política para el principal. Para obtener más información, consulta Límites y condiciones de acceso principales en esta página.

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

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

Casos de uso

Las siguientes son 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 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 principales, consulta Crea y aplica Políticas de Límite de Acceso de las Principales.

Cómo restringir las principales a los recursos de tu organización

Puedes usar las políticas de límite de acceso de las principales para asegurarte de que las principales de tu organización solo sean aptas para acceder a los recursos dentro de tu organización.

Por ejemplo, imagina que quieres asegurarte de que todas las principales de la organización example.com solo sean aptas para acceder a los recursos dentro de example.com. Los principales que se encuentran en example.com incluyen todas las identidades del dominio example.com, todos los grupos de identidades de la fuerza laboral en example.com y todas las cuentas de servicio y los grupos de identidades para cargas de trabajo de cualquier proyecto en 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 no sean aptas para acceder a recursos fuera de example.com, debes crear una política de límite de acceso de las principales que las haga 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:

{
  "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"
}

Ahora, todas las principales de example.com solo son apenas aptas para acceder a los recursos de example.com. No se les permite usar los permisos que bloquea la política de límite de acceso de las principales para acceder a recursos fuera de example.com, incluso si tienen esos permisos en esos recursos.

Restringe las cuentas de servicio a los recursos de un solo proyecto

Puedes usar políticas de límite de acceso de las principales para garantizar que las cuentas de servicio de un proyecto específico solo sean aptas para acceder a los recursos de ese proyecto.

Por ejemplo, imagina que tienes un proyecto, example-dev. Debes 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 las principales 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 restringir los principales a los recursos de tu organización.

Para que las cuentas de servicio de 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 las haga aptas para 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"
  }
}

Luego, creas una vinculación de políticas para vincular esta política a todos los principales en example-dev y agregas una condición para que la vinculación de políticas 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 restringe la elegibilidad de las cuentas de servicio. Esto se debe a que existe una política de límite de acceso de las principales existente que hace que todos los principales de example.com sean aptos 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 son aptas para acceder a todos los recursos de 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 evite que se aplique a las cuentas de servicio 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')"
  }
}

Ahora, las cuentas de servicio en example-dev solo son aptas para acceder a los recursos en example-dev. No se les permite usar permisos que bloquea la política de límite de acceso de las principales para acceder a recursos fuera de example-dev, incluso si tienen esos permisos en esos recursos.

¿Qué sigue?

• Obtén 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 las principales.