Es posible que parte o toda la información de esta página no se aplique a Trusted Cloud by S3NS. Para obtener más información, consulta las diferencias con Google Cloud.

Esta página se ha traducido con Cloud Translation API.

Información sobre las políticas de permiso

Puedes conceder acceso a los Trusted Cloud by S3NS recursos mediante políticas de permiso, también conocidas como políticas de Gestión de Identidades y Accesos (IAM), que se adjuntan a los recursos. Solo puedes adjuntar una política de permiso a cada recurso. La política de permiso controla el acceso al recurso en sí, así como a cualquier recurso descendiente que herede la política de permiso.

En esta página se muestran las políticas de permiso en formato JSON. También puedes usar la CLI de Google Cloud para obtener políticas de permiso en formato YAML.

Estructura de las políticas

Una política de permiso es un conjunto de vinculaciones de roles y metadatos. Una asignación de roles especifica el acceso que se debe conceder a un recurso. Asocia o vincula uno o varios principales con un solo rol de gestión de identidades y accesos y cualquier condición específica del contexto que cambie cómo y cuándo se concede el rol. Los metadatos incluyen información adicional sobre la política de permiso, como un etag y una versión para facilitar la gestión de la política.

Cada enlace de rol puede incluir los siguientes campos:

Uno o varios principales, también conocidos como miembros o identidades. Hay varios tipos de principales, como usuarios individuales, grupos de usuarios y cuentas de servicio. Para ver una lista completa de los tipos de principales admitidos, consulta Tipos de principales.
Un rol, que es un conjunto de permisos con nombre que proporciona la capacidad de realizar acciones en los recursos de Trusted Cloud.
Una condición, que es una expresión lógica opcional que restringe aún más la vinculación de roles en función de los atributos de la solicitud, como su origen o el recurso de destino. Las condiciones se suelen usar para controlar si se concede acceso en función del contexto de una solicitud.

Si una vinculación de rol contiene una condición, se denomina vinculación de rol condicional.

Algunos Trusted Cloud servicios no aceptan condiciones en las políticas de permiso. Para ver una lista de los servicios y tipos de recursos que aceptan condiciones, consulta Tipos de recursos que aceptan enlaces de roles condicionales.

Los cambios en el acceso de una entidad de seguridad son eventualmente coherentes. Esto significa que los cambios en el acceso tardan en propagarse por el sistema. Para saber cuánto tiempo tardan de media en propagarse los cambios de acceso, consulta Propagación de cambios de acceso.

Límites en todas las entidades

Cada política de permiso puede contener hasta 1500 entidades principales. A efectos de este límite, IAM cuenta todas las apariciones de cada principal en las vinculaciones de roles de la política de permiso, así como los principales que la política de permiso exime del registro de auditoría de acceso a datos. No anula los principales duplicados que aparezcan en varias vinculaciones de roles. Por ejemplo, si una política de permiso solo contiene vinculaciones de roles para la entidad principal principal://iam.googleapis.com/locations/global/workforcePools/my-pool/subject/my-user@example.com y esta entidad principal aparece en 50 vinculaciones de roles, puedes añadir otras 1450 entidades principales a las vinculaciones de roles de la política de permiso.

Además, a efectos de este límite, cada aparición de un conjunto de principales se cuenta como un único principal, independientemente del número de miembros individuales que haya en el conjunto.

Si usas condiciones de gestión de identidades y accesos o asignas roles a muchos principales con identificadores inusualmente largos, es posible que la gestión de identidades y accesos permita menos principales en la política de permisos.

Metadatos de la política

Los metadatos de una política de permiso incluyen los siguientes campos:

Un campo etag, que se usa para controlar la simultaneidad y asegura que las políticas de permiso se actualicen de forma coherente. Para obtener más información, consulta la sección Usar etags en una política de esta página.
Un campo version, que especifica la versión del esquema de una política de permisos determinada. Para obtener más información, consulta la sección Versiones de las políticas de esta página.

En el caso de las organizaciones, las carpetas, los proyectos y las cuentas de facturación, la política de permiso también puede contener un campo auditConfig, que especifica los tipos de actividad que generan registros de auditoría para cada servicio. Para saber cómo configurar esta parte de una política de permiso, consulta el artículo sobre cómo configurar registros de auditoría de acceso a datos.

Usar etags en una política

Si varios sistemas intentan escribir en la misma política de permiso al mismo tiempo, existe el riesgo de que esos sistemas sobrescriban los cambios de los demás. Este riesgo se debe a que las políticas de permiso se actualizan mediante el patrón de lectura, modificación y escritura, que implica varias operaciones:

Leer la política de permiso
Modificar la política de permitir
Escribir toda la política de permiso

Si el sistema A lee una política de permiso y el sistema B escribe inmediatamente una versión actualizada de esa política, el sistema A no tendrá constancia de los cambios del sistema B. Cuando el sistema A escribe sus propios cambios en la política de permisos, los cambios del sistema B podrían perderse.

Para evitar este problema, Gestión de Identidades y Accesos (IAM) admite el control de simultaneidad mediante el uso de un campo etag en la política de permisos. Cada política de permiso contiene un campo etag, cuyo valor cambia cada vez que se actualiza una política de permiso. Si una política de permiso contiene un campo etag, pero no enlaces de roles, la política de permiso no concede ningún rol de gestión de identidades y accesos.

El campo etag contiene un valor como BwUjMhCsNvY=. Cuando actualice la política de permiso, asegúrese de incluir el campo etag en la política de permiso actualizada. Si la política de permiso se ha modificado desde que la recuperaste, el valor etag no coincidirá y la actualización fallará. En el caso de la API REST, recibirá el código de estado HTTP 409 Conflict y el cuerpo de la respuesta será similar al siguiente:

{
  "error": {
    "code": 409,
    "message": "There were concurrent policy changes. Please retry the whole read-modify-write with exponential backoff.",
    "status": "ABORTED"
  }
}

Si recibes este error, vuelve a intentar toda la serie de operaciones: lee la política de permisos, modifícala según sea necesario y escribe la política de permisos actualizada. Debes volver a intentar la operación automáticamente, con un retroceso exponencial, en cualquier herramienta que uses para gestionar las políticas de permiso.

Ejemplo: política sencilla

Supongamos que tenemos la siguiente política de permiso que vincula un principal a un rol:

{
  "bindings": [
    {
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/jie@example.com"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

En el ejemplo anterior, se le concede a Jie el rol básico de propietario sin ninguna condición. Este rol le da a Jie acceso casi ilimitado.

Ejemplo: Política con varias vinculaciones de roles

Considera la siguiente política de permisos que contiene más de una vinculación de rol. Cada enlace de rol otorga un rol diferente:

{
  "bindings": [
    {
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/jie@example.com"
      ],
      "role": "roles/resourcemanager.organizationAdmin"
    },
    {
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/raha@example.com",
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/jie@example.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

En el ejemplo anterior, se le ha concedido a Jie el rol predefinido Administrador de la organización (roles/resourcemanager.organizationAdmin) en la primera asignación de roles. Este rol contiene permisos para organizaciones, carpetas y operaciones de proyectos limitadas. En la segunda asignación de roles, tanto Jie como Raha tienen la capacidad de crear proyectos mediante el rol Creador de proyectos (roles/resourcemanager.projectCreator). En conjunto, estas asignaciones de roles conceden acceso detallado a Jie y a Raha, y Jie tiene más acceso que Raha.

Ejemplo: Política con vinculación de roles condicional

Considere la siguiente política de permiso, que vincula principales a un rol predefinido y usa una expresión de condición para restringir la vinculación del rol:

{
  "bindings": [
    {
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/prod-dev",
        "serviceAccount:prod-dev-example@appspot.s3ns-system.iam.gserviceaccount.com"
      ],
      "role": "roles/appengine.deployer",
      "condition": {
          "title": "Expires_July_1_2022",
          "description": "Expires on July 1, 2022",
          "expression":
            "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

En este ejemplo, el campo version se define como 3, porque la política de permiso contiene una expresión de condición. La vinculación de roles en la política de permiso es condicional: concede el rol al grupo prod-dev y a la cuenta de servicio prod-dev-example@appspot.s3ns-system.iam.gserviceaccount.com, pero solo hasta el 1 de julio del 2022.

Para obtener información sobre las funciones que admite cada versión de la política de permisos, consulta Versiones de la política en esta página.

Ejemplo: política con vinculaciones de roles condicionales e incondicionales

Considera la siguiente política de permiso, que contiene vinculaciones de roles condicionales e incondicionales para el mismo rol:

{
  "bindings": [
    {
      "members": [
        "serviceAccount:prod-dev-example@appspot.s3ns-system.iam.gserviceaccount.com"
       ],
       "role": "roles/appengine.deployer"
    },
    {
      "members": [
        "principalSet://iam.googleapis.com/locations/global/workforcePools/example-pool/group/prod-dev",
        "serviceAccount:prod-dev-example@appspot.s3ns-system.iam.gserviceaccount.com"
      ],
      "role": "roles/appengine.deployer",
      "condition": {
        "title": "Expires_July_1_2022",
        "description": "Expires on July 1, 2022",
        "expression":
          "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

En este ejemplo, la cuenta de servicio serviceAccount:prod-dev-example@appspot.s3ns-system.iam.gserviceaccount.com se incluye en dos enlaces de rol para el mismo rol. La primera vinculación de roles no tiene ninguna condición. La segunda vinculación de rol tiene una condición que solo concede el rol hasta el 1 de julio del 2022.

En la práctica, esta política de permiso siempre concede el rol a la cuenta de servicio. En gestión de identidades y accesos, las vinculaciones de roles condicionales no anulan las vinculaciones de roles sin condiciones. Si una cuenta principal está vinculada a un rol y la vinculación de roles no tiene una condición, la cuenta principal siempre tendrá ese rol. Añadir la cuenta principal a una vinculación de roles condicional para el mismo rol no tiene ningún efecto.

Por el contrario, el grupo prod-dev solo se incluye en el enlace de rol condicional. Por lo tanto, solo tiene el rol antes del 1 de julio del 2022.

Ejemplo: Política que vincula un rol a una cuenta principal eliminada

Veamos la siguiente política de permiso. Esta política de permiso vincula un rol a una cuenta de servicio, serviceAccount:my-service-account@my-project.s3ns-system.iam.gserviceaccount.com, que se ha eliminado. Por lo tanto, el identificador de la cuenta de servicio ahora tiene el prefijo deleted::

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@my-project.s3ns-system.iam.gserviceaccount.com?uid=123456789012345678901"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Si creas una cuenta de servicio con el mismo nombre, las vinculaciones de roles de la política de permisos de la cuenta de servicio eliminada no se aplicarán a la nueva cuenta de servicio. Este comportamiento se aplica a todos los tipos de entidades principales eliminadas.

De esta forma, se evita que los nuevos principales hereden roles que se hayan concedido a principales eliminados. Si quieres asignar roles a la nueva entidad principal, añádela a las vinculaciones de roles de la política de permiso, tal como se muestra en la sección Políticas con entidades principales eliminadas de esta página.

Todas las entidades principales eliminadas tienen el prefijo deleted:. Algunos tipos de principales eliminados, como las cuentas de servicio, también tienen el sufijo ?uid=numeric-id, donde numeric-id es el ID numérico único del principal eliminado. En este ejemplo, en lugar de serviceAccount:serviceAccount:my-service-account@my-project.s3ns-system.iam.gserviceaccount.com, la política de permiso muestra el identificador deleted:serviceAccount:my-service-account@my-project.s3ns-system.iam.gserviceaccount.com?uid=123456789012345678901.

Políticas predeterminadas

Todos los recursos que aceptan políticas de permiso se crean con políticas de permiso predeterminadas. Las políticas de permiso predeterminadas de la mayoría de los recursos están vacías. Sin embargo, las políticas de permiso predeterminadas de algunos recursos contienen automáticamente determinados enlaces de rol. Por ejemplo, cuando creas un proyecto, la política de permiso del proyecto incluye automáticamente un enlace de rol que te concede el rol Propietario (roles/owner) en el proyecto.

El sistema crea estas vinculaciones de roles, por lo que el usuario no necesita los permisos getIamPolicy o setIamPolicy en el recurso para que se creen las vinculaciones de roles.

Para saber si un recurso se ha creado con una política de permiso, consulta la documentación del recurso.

Herencia de políticas y jerarquía de recursos

Trusted Cloud Los recursos se organizan jerárquicamente. El nodo de organización es el nodo raíz de la jerarquía, seguido de las carpetas (opcional) y, por último, los proyectos. La mayoría de los demás recursos se crean y gestionan en un proyecto. Cada recurso tiene un único elemento superior, excepto la organización. La organización, como nodo raíz de la jerarquía, no tiene ningún elemento superior. Consulta más información en el tema Jerarquía de recursos.

Es importante tener en cuenta la jerarquía de recursos al definir una política de permiso. Cuando se define una política de permiso a un nivel superior de la jerarquía (por ejemplo, a nivel de organización, carpeta o proyecto), el ámbito de acceso concedido incluye el nivel de recurso al que se adjunta esta política de permiso y todos los recursos de ese nivel. Por ejemplo, una política de permiso definida a nivel de organización se aplica a la organización y a todos los recursos que dependen de ella. Del mismo modo, una política de permiso configurada a nivel de proyecto se aplica al proyecto y a todos los recursos del proyecto.

La herencia de políticas es el término que describe cómo se aplican las políticas de permiso a los recursos que están por debajo de su nivel en la jerarquía de recursos. El término política efectiva describe cómo se heredan todas las políticas de permiso de los elementos superiores de la jerarquía de recursos en un recurso. Es la unión de lo siguiente:

La política de permiso definida en el recurso
Las políticas de permiso definidas en todos los niveles de recursos antecesores del recurso en la jerarquía

Cada nuevo enlace de rol (heredado de recursos superiores) que afecte a la política de permiso efectiva del recurso se evalúa de forma independiente. Se concede una solicitud de acceso específica al recurso si alguna de las vinculaciones de roles de nivel superior concede acceso a la solicitud.

Si se introduce un nuevo enlace de rol en cualquier nivel de la política de permiso heredada de un recurso, el ámbito de la concesión de acceso aumenta.

Ejemplo: Herencia de políticas

Para entender la herencia de políticas de permiso, vamos a plantear una situación en la que se asignan dos roles de gestión de identidades y accesos a un usuario, Raha, en dos niveles diferentes de la jerarquía de recursos.

Para conceder un rol a Raha a nivel de organización, debes definir la siguiente política de permiso en tu organización:

{
  "bindings": [
    {
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/raha@example.com"
      ],
      "role": "roles/storage.objectViewer"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Esta política de permiso otorga a Raha el rol Lector de objetos de Storage (roles/storage.objectViewer), que contiene los permisos get y list para proyectos y objetos de Cloud Storage. Como has definido la política de permiso en tu organización, Raha puede usar estos permisos en todos los proyectos y objetos de Cloud Storage de tu organización.

Para concederle a Raha un rol a nivel de proyecto, debes definir la siguiente política de permiso en el proyecto myproject-123:

{
  "bindings": [
    {
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/raha@example.com"
      ],
      "role": "roles/storage.objectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Esta política de permiso concede a Raha el rol Creador de objetos de Storage (roles/storage.objectCreator), que le permite crear objetos de Cloud Storage. Como has definido la política de permiso en myproject-123, Raha solo puede crear objetos de Cloud Storage en myproject-123.

Ahora que hay dos enlaces de rol que conceden acceso a Raha a los objetos de Cloud Storage de destino en myproject-123, se aplican las siguientes políticas de permiso:

Una política de permiso a nivel de organización concede la capacidad de enumerar y obtener todos los objetos de Cloud Storage de esa organización.
Una política de permiso a nivel de proyecto, para el proyecto myproject-123, otorga la capacidad de crear objetos en ese proyecto.

En la siguiente tabla se resume la política efectiva de Raha:

Permisos del rol Lector de objetos de Storage en la organización	Permisos del rol Creador de objetos de Storage en `myproject-123`	Permisos efectivos de Raha en `myproject-123`
resourcemanager.projects.get resourcemanager.projects.list storage.objects.get storage.objects.list	resourcemanager.projects.get resourcemanager.projects.list storage.objects.create	resourcemanager.projects.get resourcemanager.projects.list storage.objects.get storage.objects.list storage.objects.create

Versiones de la política

Con el tiempo, es posible que Gestión de Identidades y Accesos añada nuevas funciones que modifiquen o añadan campos significativos al esquema de la política de permisos. Para evitar que se interrumpan las integraciones que tengas configuradas y que dependan de la coherencia de la estructura de la política de permisos, estos cambios se introducen en las nuevas versiones del esquema de la política de permisos.

Si es la primera vez que integras IAM, te recomendamos que utilices la versión del esquema de la política de permiso más reciente disponible en ese momento. En la siguiente sección se describen las diferentes versiones disponibles y cómo usar cada una de ellas. También se describe cómo especificar una versión de la política y se analizan algunos casos prácticos de solución de problemas.

Todas las políticas de permiso especifican un campo version como parte de los metadatos de la política de permiso. Fíjate en la parte destacada del siguiente ejemplo:

{
  "bindings": [
    {
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/jie@example.com"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

En este campo se especifica la versión del esquema de sintaxis de la política de permiso. Cada versión de la política de permiso contiene un esquema de sintaxis específico que pueden usar las vinculaciones de roles. La versión más reciente puede contener enlaces de rol con el esquema de sintaxis más reciente, que no es compatible con versiones anteriores. Este campo no se debe usar para ningún otro fin que no sea controlar el esquema de sintaxis de la política de permiso.

Versiones válidas de la política

Las políticas de permiso pueden usar las siguientes versiones:

Versión	Descripción
`1`	La primera versión del esquema de sintaxis de gestión de identidades y accesos para las políticas. Permite vincular un rol a uno o varios principales. No admite vinculaciones de roles condicionales.
`2`	Reservado para uso interno.
`3`	Presenta el campo `condition` en la asignación de roles, que restringe la asignación de roles mediante reglas basadas en el contexto y en atributos. Para obtener más información, consulta la descripción general de las condiciones de gestión de identidades y accesos.

Especificar una versión de la política al obtenerla

En el caso de la API REST y las bibliotecas de cliente, cuando obtengas una política de permiso, te recomendamos que especifiques una versión de la política de permiso en la solicitud. Cuando una solicitud especifica una versión de la política de permiso, IAM da por hecho que el llamante conoce las funciones de esa versión de la política de permiso y puede gestionarlas correctamente.

Si la solicitud no especifica una versión de la política de permiso, Gestión de Identidades y Accesos asume que el llamante quiere una versión 1 de la política de permiso.

Cuando recibes una política de permiso, IAM comprueba la versión de la política de permiso en la solicitud o la versión predeterminada si la solicitud no especifica ninguna. Gestión de identidades y accesos también comprueba la política de permiso de los campos que no se admiten en una política de permiso de la versión 1. Usa esta información para decidir qué tipo de respuesta enviar:

Si la política de permiso no contiene ninguna condición, IAM siempre devuelve una política de permiso de la versión 1, independientemente del número de versión de la solicitud.
Si la política de permiso contiene condiciones y el llamante ha solicitado una versión 3 de la política de permiso, IAM devuelve una versión 3 de la política de permiso que incluye las condiciones. Para ver un ejemplo, consulta el caso 1 de esta página.
Si la política de permiso contiene condiciones y el llamante ha solicitado una política de permiso de la versión 1 o no ha especificado ninguna versión, IAM devuelve una política de permiso de la versión 1.

En el caso de las vinculaciones de roles que incluyen una condición, IAM añade la cadena _withcond_ al nombre del rol, seguida de un valor hash. Por ejemplo, roles/iam.serviceAccountAdmin_withcond_2b17cc25d2cd9e2c54d8. La condición no está presente. Para ver un ejemplo, consulta el caso práctico 2 de esta página.

Situación 1: Versión de la política que admite completamente las condiciones de gestión de identidades y accesos

Supongamos que llamas al siguiente método de la API REST para obtener la política de permiso de un proyecto:

POST https://cloudresourcemanager.s3nsapis.fr/v1/projects/project-id:getIamPolicy

El cuerpo de la solicitud contiene el siguiente texto:

{
  "options": {
    "requestedPolicyVersion": 3
  }
}

La respuesta contiene la política de permiso del proyecto. Si la política de permiso contiene al menos un enlace de rol condicional, su campo version se define como 3:

{
  "bindings": [
    {
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/tal@example.com"
      ],
      "role": "roles/iam.securityReviewer",
      "condition": {
          "title": "Expires_July_1_2022",
          "description": "Expires on July 1, 2022",
          "expression": "request.time < timestamp('2022-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

Si la política de permiso no contiene enlaces de roles condicionales, su campo version se define como 1, aunque la solicitud haya especificado la versión 3:

{
  "bindings": [
    {
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/tal@example.com"
      ],
      "role": "roles/iam.securityReviewer",
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 1
}

Situación 2: Versión de la política con compatibilidad limitada con las condiciones de gestión de identidades y accesos

Supongamos que llamas al siguiente método de la API REST para obtener la política de permiso de un proyecto:

POST https://cloudresourcemanager.s3nsapis.fr/v1/projects/project-id:getIamPolicy

El cuerpo de la solicitud está vacío y no especifica un número de versión. Por lo tanto, IAM usa la versión predeterminada de la política de permiso, 1.

La política de permiso contiene una vinculación de rol condicional. Como la versión de la política de permisos es 1, la condición no aparece en la respuesta. Para indicar que la vinculación de roles usa una condición, la aplicación IAM añade la cadena _withcond_ al nombre del rol, seguida de un valor de hash:

{
  "bindings": [
    {
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/tal@example.com"
      ],
      "role": "roles/iam.securityReviewer_withcond_58e135cabb940ad9346c"
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 1
}

Especificar una versión de la política al definirla

Cuando definas una política de permiso, te recomendamos que especifiques una versión de la política de permiso en la solicitud. Cuando una solicitud especifica una versión de la política de permiso, IAM da por hecho que el llamante conoce las funciones de esa versión y puede gestionarlas correctamente.

Si la solicitud no especifica una versión de la política de permiso, IAM solo acepta los campos que pueden aparecer en una versión de la política de permiso 1. Como práctica recomendada, no cambies las vinculaciones de roles condicionales en una versión 1 allow policy, ya que esta política no muestra la condición de cada vinculación de roles, por lo que no sabes cuándo ni dónde se concede realmente la vinculación de roles. En su lugar, obtén la representación de la versión 3 de la política de permisos, que muestra la condición de cada enlace de rol, y usa esa representación para actualizar los enlaces de rol.

Situación: versiones de la política en solicitudes y respuestas

Supongamos que usas la API REST para obtener una política de permiso y especificas la versión 3 en la solicitud. La respuesta contiene la siguiente política de permiso, que usa la versión 3:

{
  "bindings": [
    {
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/raha@example.com"
      ],
      "role": "roles/storage.admin",
      "condition": {
          "title": "Weekday_access",
          "description": "Monday thru Friday access only in America/Chicago",
          "expression": "request.time.getDayOfWeek('America/Chicago') >= 1 && request.time.getDayOfWeek('America/Chicago') <= 5"
      }
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 3
}

Decides que Raha debe tener el rol Administrador de almacenamiento (roles/storage.admin) durante toda la semana, no solo los días laborables. Elimina la condición de la vinculación de roles y envía una solicitud a la API REST para definir la política de permiso. De nuevo, especifica la versión 3 en la solicitud:

{
  "bindings": [
    {
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/raha@example.com"
      ],
      "role": "roles/storage.admin"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 3
}

La respuesta contiene la política de permitir actualizada:

{
  "bindings": [
    {
      "members": [
        "principal://iam.googleapis.com/locations/global/workforcePools/example-pool/subject/raha@example.com"
      ],
      "role": "roles/storage.admin"
    }
  ],
  "etag": "BwWd8I+ZUAQ=",
  "version": 1
}

La política de permiso de la respuesta usa la versión 1, aunque la solicitud especificaba la versión 3, porque la política de permiso solo usa campos compatibles con una política de permiso de la versión 1.

Políticas con entidades principales eliminadas

Si una vinculación de roles de una política de permiso incluye una cuenta principal eliminada y añades una vinculación de roles para una cuenta principal nueva con el mismo nombre, la vinculación de roles siempre se aplicará a la cuenta principal nueva.

Por ejemplo, considera esta política de permiso que incluye una vinculación de rol para una cuenta de servicio eliminada, my-service-account@project-id.s3ns-system.iam.gserviceaccount.com. Por lo tanto, el identificador de cada cuenta de servicio tiene el prefijo deleted::

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@project-id.s3ns-system.iam.gserviceaccount.com?uid=123456789012345678901"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Supongamos que creas una cuenta de servicio con el nombre my-service-account@project-id.s3ns-system.iam.gserviceaccount.com y quieres asignarle el rol Creador de proyectos (roles/resourcemanager.projectCreator). Para asignarle el rol a la nueva cuenta de servicio, actualiza la política de permisos como se muestra en este ejemplo:

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@project-id.s3ns-system.iam.gserviceaccount.com?uid=123456789012345678901"
      ],
      "role": "roles/owner"
    },
    {
      "members": [
        "serviceAccount:my-service-account@project-id.s3ns-system.iam.gserviceaccount.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Para que te resulte más fácil auditar tus políticas de permiso de gestión de identidades y accesos, también puedes quitar al usuario eliminado del enlace de rol al rol de propietario:

{
  "bindings": [
    {
      "members": [
        "deleted:serviceAccount:my-service-account@project-id.s3ns-system.iam.gserviceaccount.com?uid=123456789012345678901"
      ],
      "role": "roles/owner"
    },
    {
      "members": [
        "user:donald@example.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Prácticas recomendadas de las políticas

Las siguientes prácticas recomendadas se aplican a las organizaciones con muchos Trusted Cloud usuarios:

Si gestionas varios principales con las mismas configuraciones de acceso, usa grupos. Incluye cada principal individual en el grupo y concede los roles correspondientes al grupo en lugar de a los principales de las cuentas de usuario individuales.
Roles concedidos a nivel de organización: piensa detenidamente a qué principales se les conceden roles a nivel de organización. En la mayoría de las organizaciones, solo unos pocos equipos específicos, como los de seguridad y redes, deberían tener acceso a este nivel de la jerarquía de recursos.
Roles concedidos a nivel de carpeta: puedes reflejar la estructura operativa de tu organización mediante niveles de carpetas, donde cada carpeta se puede configurar con diferentes conjuntos de concesiones de acceso que se ajusten a las necesidades empresariales y operativas. Por ejemplo, una carpeta principal puede reflejar un departamento, una de sus carpetas secundarias puede reflejar el acceso y el funcionamiento de los recursos por parte de un grupo, y otra carpeta secundaria puede reflejar un equipo pequeño. Ambas carpetas pueden contener proyectos para las necesidades operativas de su equipo. Si usas las carpetas de esta forma, puedes asegurarte de que el acceso esté correctamente separado, al tiempo que respetas las políticas de permiso heredadas de las carpetas principales y de la organización. Esta práctica requiere menos mantenimiento de las políticas de permiso al crear y gestionar recursos de Trusted Cloud .
Roles concedidos a nivel de proyecto: concede enlaces de roles a nivel de proyecto cuando sea necesario para seguir el principio de privilegio mínimo. Por ejemplo, si una entidad necesita acceder a 3 de los 10 proyectos de una carpeta, debes concederle acceso a cada uno de los 3 proyectos por separado. Por el contrario, si le asignaras un rol en la carpeta, la entidad obtendría acceso a otros 7 proyectos que no necesita.

También puede usar condiciones de gestión de identidades y accesos para asignar roles a nivel de organización o carpeta, pero solo a un subconjunto de carpetas o proyectos.
Solo concede acceso a las entidades de tu dominio: para mejorar la seguridad de tu organización, no concedas roles a entidades que no pertenezcan a tu dominio. Para aplicar esta práctica recomendada, aplica la restricción de la política de organización iam.allowedPolicyMemberDomains.

Nota: Si tu organización se creó el 3 de mayo del 2024 o después de esa fecha, la restricción predefinida iam.allowedPolicyMemberDomains se aplica de forma predeterminada y tu dominio se muestra como el único valor permitido.

Siguientes pasos

Consulta cómo solucionar problemas de políticas de permiso que contengan la cadena withcond en nombres de roles.
Consulta cómo gestionar las vinculaciones de roles en una política de permiso.
Consulta una descripción general de las condiciones de gestión de identidades y accesos, que usan la versión 3 de las políticas de permiso.