Comprende las políticas de permisos

Puedes otorgar acceso a los recursos de Google Cloud mediante las políticas de permisos, también conocidas como políticas de Identity and Access Management (IAM), que se adjuntan a los recursos. Solo puedes adjuntar una política de permisos a cada recurso. La política de permisos controla el acceso al recurso, así como a todos los subordinados de ese recurso que heredan la política.

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

Estructura de políticas

Una política de permisos es un conjunto de vinculaciones de roles y metadatos. Una vinculación de rol especifica qué acceso se debe otorgar a un recurso. Asocia, o vincula a una o más principales con un solo rol de IAM y cualquier condición específica del contexto que cambie cómo y cuándo se otorga el rol. Los metadatos incluyen información adicional sobre la política de permisos, como ETag y versión para facilitar la administración de políticas.

Cada vinculación de función puede incluir los siguientes campos:

  • Una o más principales, también conocidas como miembros o identidades. Existen varios tipos de principales, incluidas cuentas de usuario, cuentas de servicio, Grupos de Google y dominios. Para obtener una lista completa de los tipos de principales compatibles, consulta Identificadores de principal.
  • Una función, que es una colección de permisos con nombre que proporciona la capacidad de realizar acciones en los recursos de Google Cloud.

  • Una condición es una expresión lógica opcional que restringe aún más la vinculación de función según los atributos de la solicitud, como su origen, el recurso de destino. Por lo general, las condiciones se usan para controlar si se otorga el acceso en función del contexto de una solicitud.

    Si una vinculación de roles también contiene una condición, se la denomina una vinculación de roles condicional.

    Algunos servicios de Google Cloud no aceptan condiciones en las políticas de permisos. Para obtener una lista de los servicios y tipos de recursos que aceptan condiciones, consulta Tipos de recursos que aceptan vinculaciones de roles condicionales.

Los cambios en el acceso de una principal tienen coherencia eventual. Esto significa que los cambios de acceso tardan un tiempo en propagarse a través del sistema. Para saber cuánto tiempo tardan, en promedio, en propagarse los cambios de acceso, consulta Propagación de cambios de acceso.

Límites de todas las principales

Cada política de permisos puede contener hasta 1,500 principales. Para los fines 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 permisos exime a los registros de auditoría de acceso a los datos. No anula el duplicado de las principales que aparecen en más de una vinculación de roles. Por ejemplo, si una política de permisos solo contiene vinculaciones de roles para el user:my-user@example.com principal, y este principal aparece en 50 vinculaciones de roles, puedes agregar otras 1,450 principales a las vinculaciones de roles en la política de permisos.

Además, para los fines de este límite, cada aparición de un dominio o Grupo de Google se cuenta como un único principal, sin importar la cantidad de miembros individuales del dominio o grupo.

Si usas las Condiciones de IAM o si otorgas roles a muchas principales con identificadores más largos de lo normal, IAM podría permitir menos principales en la política de permisos.

Límites de grupos y dominios

Hasta 250 de las principales en una política de permisos pueden ser Grupos de Google, dominios de Cloud Identity o cuentas de Google Workspace.

Para los fines de este límite, los dominios de Cloud Identity, las cuentas de Google Workspace y los Grupos de Google se cuentan de la siguiente manera:

  • Para los Grupos de Google, cada grupo único se cuenta solo una vez, sin importar cuántas veces aparezca en la política de permisos. Esto es diferente de la forma en que se cuentan los grupos para el límite de la cantidad total de principales en una política de permisos. Para ese límite, cada aparición de un grupo se considera en el límite.
  • Para los dominios de Cloud Identity o las cuentas de Google Workspace, IAM cuenta todas las apariciones de cada dominio o cuenta en las vinculaciones de roles de la política de permisos. No anula el duplicado de los dominios o las cuentas que aparecen en más de una vinculación de roles.

Por ejemplo, si tu política de permisos contiene solo un grupo, group:my-group@example.com y el grupo aparece en la política de permisos 10 veces, puedes agregar 249 dominios, cuentas de Google Workspace o grupos únicos de Cloud Identity más antes de alcanzar el límite.

Como alternativa, si tu política de permisos contiene solo un dominio, domain:example.com, y el dominio aparece en la política de permisos 10 veces, puedes agregar otros 240 dominios de Cloud Identity, cuentas de Google Workspace o grupos únicos antes de alcanzar el límite.

Metadatos de políticas

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

  • Un campo etag, que se usa para el control de simultaneidad, y garantiza que las políticas de permisos se actualicen de forma coherente. Para obtener más información, consulta cómo usar ETags en una política en esta página.
  • Un campo version, que especifica la versión de esquema para una política de permisos determinada. Para obtener más información, consulta Versiones de políticas en esta página.

Para organizaciones, carpetas, proyectos y cuentas de facturación, la política de permisos también puede contener un campo auditConfig que especifica los tipos de actividad que generan registros de auditoría para cada servicio. Si quieres obtener información sobre cómo configurar esta parte de una política de permisos, consulta Configura registros de auditoría de acceso a los datos.

Usa ETags en una política

Cuando varios sistemas intentan escribir en la misma política de permisos al mismo tiempo, existe el riesgo de que esos sistemas reemplacen sus cambios entre sí. Este riesgo existe porque las políticas de permisos se actualizan a través del patrón de lectura, modificación y escritura, que implica varias operaciones:

  1. Leer la política de permisos existente
  2. Modificar la política de permisos
  3. Escribir toda la política de permisos

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

Para evitar este problema, Identity and Access Management (IAM) admite el control de simultaneidad mediante el uso de un campo etag en la política de permisos. Cada política de permisos contiene un campo etag, y el valor de este campo cambia cada vez que se actualiza una política de permisos. Si una política de permisos contiene un campo etag, pero no tiene vinculaciones de roles, la política de permisos no otorga roles de IAM.

El campo etag contiene un valor, como BwUjMhCsNvY=. Cuando actualices la política de permisos, asegúrate de incluir el campo etag en la política de permisos actualizada. Si se modificó la política de permisos desde que la recuperaste, el valor etag no coincidirá y la actualización fallará. Para la API de REST, recibirás 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 de nuevo, modifícala según sea necesario y escribe la política de permisos actualizada. Debes realizar reintentos de forma automática, con retirada exponencial, en cualquier herramienta que uses para administrar las políticas de permisos.

Ejemplo: Política simple

Considera la siguiente política de permisos que vincula a una principal con un rol:

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

En el ejemplo anterior, a jie@example.com se le otorga la función básica de propietario sin ninguna condición. Este rol le otorga a jie@example.com acceso casi ilimitado.

Ejemplo: Política con múltiples vinculaciones de función

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

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/resourcemanager.organizationAdmin"
    },
    {
      "members": [
        "user:raha@example.com",
        "user:jie@example.com"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

En el ejemplo anterior, a Jie (jie@example.com) se le otorga la función predefinida de administrador de la organización (roles/resourcemanager.organizationAdmin) en la primera vinculación de función. Esta función contiene permisos para organizaciones, carpetas y operaciones de proyectos limitadas. En la segunda vinculación de funciones, Jie y Raha (raha@example.com) tienen la capacidad de crear proyectos a través de la función de creador de proyectos (roles/resourcemanager.projectCreator). En conjunto, estas vinculaciones de funciones otorgan acceso detallado a Jie y Raha, y Jie posee más acceso que Raha.

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

Considera la siguiente política de permisos, que vincula a las principales con un rol predefinido y usa una expresión de condición para restringir la vinculación de rol:

{
  "bindings": [
    {
      "members": [
        "group:prod-dev@example.com",
        "serviceAccount:prod-dev-example@appspot.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 establece en 3, debido a que la política de permisos contiene una expresión de condición. La vinculación de rol de la política de permisos es condicional; otorga el rol al grupo de Google prod-dev@example.com y a la cuenta de servicio prod-dev-example@appspot.gserviceaccount.com, pero solo hasta el 1 de julio de 2022.

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

Ejemplo: Política con vinculaciones de funciones condicionales y no condicionales

Considera la siguiente política de permisos, que contiene vinculaciones de roles condicionales y no condicionales para el mismo rol:

{
  "bindings": [
    {
      "members": [
        "serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
       ],
       "role": "roles/appengine.deployer"
    },
    {
      "members": [
        "group:prod-dev@example.com",
        "serviceAccount:prod-dev-example@appspot.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.gserviceaccount.com se incluye en dos vinculaciones de funciones para la misma función. La primera vinculación no tiene una condición. La segunda vinculación de función tiene una condición que solo otorga la función hasta el 1 de julio de 2022.

En efecto, esta política de permisos siempre otorga el rol a la cuenta de servicio. En IAM, las vinculaciones de funciones condicionales no anulan las vinculaciones de funciones sin condiciones. Si un miembro está vinculado a una función y la vinculación de función no tiene una condición, la principal siempre tiene esa función. Agregar la principal a una vinculación de función condicional para la misma función no tiene efecto.

Por el contrario, el grupo de Google group:prod-dev@example.com se incluye solo en la vinculación de función condicional. Por lo tanto, tiene la función solo antes del 1 de julio de 2022.

Ejemplo: Política que vincula una función a un principal borrado

Considera la siguiente política de permisos. Esta política de permisos vincula un rol a un usuario, donald@example.com, cuya cuenta se borró: Como resultado, el identificador del usuario ahora tiene un prefijo deleted::

{
  "bindings": [
    {
      "members": [
        "deleted:user:donald@example.com?uid=123456789012345678901"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Si creas un usuario nuevo llamado donald@example.com, las vinculaciones de roles de la política de permisos para el usuario borrado no se aplican al usuario nuevo. Este comportamiento evita que los usuarios nuevos hereden roles que se otorgaron a usuarios borrados. Si deseas otorgar roles al usuario nuevo, agrega el usuario nuevo a las vinculaciones de roles de la política de permisos, como se muestra en Políticas con principales borradas en esta página.

Además, el nombre del usuario ahora incluye el prefijo deleted: y el sufijo ?uid=numeric-id, en el que numeric-id es el ID numérico único del usuario borrado. En este ejemplo, en lugar de user:donald@example.com, la política de permisos muestra el identificador deleted:user:donald@example.com?uid=123456789012345678901.

Las cuentas de servicio y los grupos tienen el mismo comportamiento que los usuarios. Si borras una cuenta de servicio o un grupo y, luego, visualizas una política de permisos que incluye a esa principal, el nombre de la principal borrada tiene el prefijo deleted: y el sufijo ?uid=numeric-id.

Políticas predeterminadas

Todos los recursos que aceptan políticas de permisos se crean con políticas de permisos predeterminadas. Las políticas de permisos predeterminadas de la mayoría de los recursos están vacías. Sin embargo, las políticas de permisos predeterminadas de algunos recursos contienen automáticamente ciertas vinculaciones de roles. Por ejemplo, cuando creas un proyecto nuevo, la política de permisos para el proyecto tiene automáticamente una vinculación de rol que te otorga el rol Owner (roles/owner) en el proyecto.

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

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

La herencia de políticas y la jerarquía de recursos

Los recursos de Google Cloud están organizados de forma jerárquica. El nodo de la organización es el nodo raíz en la jerarquía, después, de manera opcional, las carpetas y, luego, los proyectos. La mayoría de los demás recursos se crean y administran en un proyecto. Cada recurso tiene solo un elemento superior, excepto la organización. La organización, como el nodo raíz en la jerarquía, no tiene un superior. Consulta Jerarquía de recursos para obtener más información.

Es importante tener en cuenta la jerarquía de recursos cuando configuras la política de permisos. A la hora de establecer una política de permisos en un nivel superior en la jerarquía, por ejemplo, a nivel de organización, carpeta o proyecto, el permiso de acceso otorgado incluye el nivel de recursos al que está vinculada esta política de permisos y todos los recursos bajo ese nivel. Por ejemplo, una política de permisos establecida a nivel de la organización se aplica a la organización y a todos los recursos de la organización. Del mismo modo, una política de permisos establecida a nivel de proyecto se aplica al proyecto y a todos los recursos del proyecto.

Herencia de políticas es el término que describe cómo se aplican las políticas de permisos a los recursos por debajo de su nivel en la jerarquía de recursos. Política vigente es el término que describe cómo se heredan todas las políticas de permisos superiores en la jerarquía de recursos para un recurso. Es la unión de los siguientes elementos:

  • La política de permisos establecida en el recurso
  • Las políticas de permisos establecidas en todos los niveles de recursos principales del recurso en la jerarquía

Cada vinculación de rol nueva (heredada de recursos superiores) que afecta la política de permisos vigente del recurso se evalúa de forma independiente. Se concede una solicitud de acceso específica al recurso si alguna de las vinculaciones de función de nivel superior otorga acceso a la solicitud.

Si se ingresa una nueva vinculación de rol en cualquier nivel de la política de permisos heredada de un recurso, el alcance de la concesión de acceso aumenta.

Ejemplo: Herencia de políticas

Para comprender la herencia de políticas de permisos, considera una situación en la que otorgas a un usuario, Raha, dos roles de IAM diferentes en dos niveles diferentes en la jerarquía de recursos.

Para otorgar a Raha un rol a nivel de la organización, establece la siguiente política de permisos en tu organización:

{
  "bindings": [
    {
      "members": [
        "user:raha@example.com"
      ],
      "role": "roles/storage.objectViewer"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

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

Para otorgar a Raha un rol a nivel de proyecto, establece la siguiente política de permisos en el proyecto myproject-123:

{
  "bindings": [
    {
      "members": [
        "user:raha@example.com"
      ],
      "role": "roles/storage.objectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Esta política de permisos otorga a Raha el rol Storage Object Creator (roles/storage.objectCreator), que le permite crear objetos de Cloud Storage. Debido a que configuras la política de permisos en myproject-123, Raha puede crear objetos de Cloud Storage solo en myproject-123.

Ahora que hay dos vinculaciones de roles que otorgan a Raha acceso a los objetos de Cloud Storage de destino en myproject-123, se aplican las siguientes políticas de permisos:

  • Una política de permisos a nivel de organización permite enumerar y obtener todos los objetos de Cloud Storage de esta organización.
  • Una política de permisos a nivel de proyecto, para el proyecto myproject-123, otorga la capacidad de crear objetos dentro de ese proyecto.

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

Permisos otorgados mediante la función “storage.objectViewer” a nivel de organización Permisos otorgados mediante la función “storage.objectCreator” en “myproject-123” Permiso vigente otorgado para 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 políticas

Con el tiempo, IAM podría agregar nuevas funciones que sumen o cambien campos de forma significativa en el esquema de políticas de permisos. Para evitar que se rompan las integraciones existentes que dependen de la coherencia en la estructura de políticas de permisos, estos cambios se ingresan en las nuevas versiones del esquema de políticas de permisos.

Si te integras en IAM por primera vez, te recomendamos usar la versión más reciente del esquema de políticas de permisos disponible en ese momento. A continuación, analizaremos las diferentes versiones disponibles y cómo usar cada una. También describiremos cómo especificar la versión que deseas y te guiaremos en algunos casos de solución de problemas.

Cada política de permisos existente especifica un campo version como parte de los metadatos de la política de permisos. Considera la parte destacada a continuación:

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/owner"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

Este campo especifica la versión del esquema de sintaxis de la política de permisos. Cada versión de la política de permisos contiene un esquema de sintaxis específico que pueden usar las vinculaciones de roles. La versión más reciente puede contener vinculaciones de roles con el esquema de sintaxis más reciente que no es compatible con versiones anteriores. Este campo no está diseñado para usarse con otros fines que no sean controlar el esquema de sintaxis de la política de permisos.

Versiones válidas de políticas

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

Versión Descripción
1 Es la primera versión del esquema de sintaxis de IAM para las políticas. Admite la vinculación de una función con una o más principales. No admite las vinculaciones de funciones condicionales.
2 Está reservada para uso interno.
3 Presenta el campo condition en la vinculación de función, que restringe la vinculación de función mediante reglas basadas en los atributos y en el contexto. Para obtener más información, consulta la Descripción general de las Condiciones de IAM.

Especifica una versión de política cuando obtienes una política

Para la API de REST y las bibliotecas cliente, cuando obtengas una política de permisos, te recomendamos que especifiques una versión de la política de permisos en la solicitud. Cuando una solicitud especifica una versión de la política de permisos, IAM supone que el emisor conoce sus características y puede manejarlas de forma adecuada.

Si en la solicitud no se especifica una versión de la política de permisos, IAM supone que el emisor quiere una política de permisos de versión 1.

Cuando obtienes una política de permisos, IAM verifica la versión de la política de permisos en la solicitud o la versión predeterminada si la solicitud no especificó una. IAM también verifica la política de permisos en busca de campos que no son compatibles con una política de permisos de versión 1. Usa esta información para decidir qué tipo de respuesta debe enviar:

  • Si la política de permisos no contiene ninguna condición, IAM siempre mostrará una política de permisos de versión 1, sin importar el número de versión en la solicitud.
  • Si la política de permisos contiene condiciones y el emisor solicitó una política de permisos de versión 3, IAM muestra una política de permisos de versión 3 que incluye las condiciones. Para ver un ejemplo, consulta la Situación 1 que se describe en esta página.

  • Si la política de permisos contiene condiciones y el emisor solicitó una política de permisos de versión 1 o no especificó una versión, IAM muestra una política de permisos de versión 1.

    En el caso de las vinculaciones de funciones que incluyen una condición, IAM agrega la string _withcond_ al nombre de la función, seguida de un valor de hash; por ejemplo, roles/iam.serviceAccountAdmin_withcond_2b17cc25d2cd9e2c54d8. La condición en sí no está presente. Para ver un ejemplo, consulta la situación 2 que se describe en esta página.

Situación 1: Versión de la política que es totalmente compatible con las Condiciones de IAM

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

POST https://cloudresourcemanager.googleapis.com/v1/projects/project-id:getIamPolicy

El cuerpo de la solicitud contiene el siguiente texto:

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

La respuesta contiene la política de permisos del proyecto. Si la política de permisos contiene al menos una vinculación de rol condicional, su campo version se establece en 3:

{
  "bindings": [
    {
      "members": [
        "user:user@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 permisos no contiene vinculaciones de roles condicionales, su campo version se establece en 1, a pesar de que en la solicitud se haya especificado la versión 3:

{
  "bindings": [
    {
      "members": [
        "user:user@example.com"
      ],
      "role": "roles/iam.securityReviewer",
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 1
}

Situación 2: Versión de la política que tiene compatibilidad limitada con las Condiciones de IAM

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

POST https://cloudresourcemanager.googleapis.com/v1/projects/project-id:getIamPolicy

El cuerpo de la solicitud está vacío. No se especifica un número de versión. Como resultado, IAM usa la versión predeterminada de la política de permisos, 1.

La política de permisos contiene una vinculación de rol condicional. Debido a que 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 rol usa una condición, IAM agrega la string _withcond_ al nombre del rol, seguida de un valor de hash:

{
  "bindings": [
    {
      "members": [
        "user:user@example.com"
      ],
      "role": "roles/iam.securityReviewer_withcond_58e135cabb940ad9346c"
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 1
}

Especifica una versión de la política cuando configuras una política

Cuando configures una política de permisos, te recomendamos que especifiques una versión de la política de permisos en la solicitud. Cuando una solicitud especifica una versión de la política de permisos, IAM supone que el emisor conoce sus características y puede manejarlas de forma adecuada.

Si la solicitud no especifica una versión de la política de permisos, IAM solo aceptará los campos que pueden aparecer en una política de permisos de versión 1. Como práctica recomendada, no cambies las vinculaciones de roles condicionales en una política de permisos de versión 1. Debido a que la política de permisos no muestra la condición de cada vinculación de rol, no sabrás en qué momento o en qué ubicación se otorga la vinculación de rol. 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 vinculación de rol, y usa esa representación para actualizar las vinculaciones de roles.

Situación: Versiones de políticas en solicitudes y respuestas

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

{
  "bindings": [
    {
      "members": [
        "user: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@example.com debe tener la función de administrador de Storage (roles/storage.admin) durante toda la semana, no solo durante los días de semana. Quitas la condición de la vinculación de rol y envías una solicitud a la API de REST para configurar la política de permisos. Una vez más, debes especificar la versión 3 en la solicitud:

{
  "bindings": [
    {
      "members": [
        "user:raha@example.com"
      ],
      "role": "roles/storage.admin"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 3
}

La respuesta contiene la política de permisos actualizada:

{
  "bindings": [
    {
      "members": [
        "user:raha@example.com"
      ],
      "role": "roles/storage.admin"
    }
  ],
  "etag": "BwWd8I+ZUAQ=",
  "version": 1
}

La política de permisos en la respuesta usa la versión 1, aunque en la solicitud se haya especificado la versión 3, debido a que la política de permisos solo usa campos que sean compatibles con una política de permisos de versión 1.

Políticas con principales borradas

Si una vinculación de rol de una política de permisos incluye un principal borrada y agregas una vinculación de rol para una principal nueva con el mismo nombre, la vinculación de rol siempre se aplica a la principal nueva.

Por ejemplo, considera esta política de permisos, que incluye una vinculación de rol a un usuario borrado, donald@example.com, y una cuenta de servicio borrada, my-service-account@project-id.iam.gserviceaccount.com. Como resultado, el identificador de cada principal tiene un prefijo deleted::

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

Supongamos que creas un usuario nuevo que también se llama donald@example.com y deseas otorgar el rol de creador de proyectos (roles/resourcemanager.projectCreator), que permite a las principales crear proyectos de Google Cloud con el usuario nuevo. Para otorgar el rol al usuario nuevo, actualiza la política de permisos como se muestra en este ejemplo:

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

Para facilitar la auditoría de tus políticas de permisos de IAM, también puedes quitar al usuario borrado de la vinculación al rol Owner:

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

Prácticas recomendadas para políticas

Las siguientes prácticas recomendadas se aplican a organizaciones con muchos usuarios de Google Cloud:

  • Cuando administres varias cuentas de usuario con las mismas configuraciones de acceso, usa Grupos de Google. Coloca cada cuenta de usuario individual en el grupo y otorga las funciones previstas al grupo, en lugar de otorgarlas a las cuentas de usuario individuales.

  • Roles otorgados a nivel de la organización: Considera de forma cuidadosa qué principales tienen roles a nivel de la organización. Para la mayoría de las organizaciones, solo algunos equipos específicos (como los equipos de seguridad y de red) deben tener acceso en este nivel de la jerarquía de recursos.

  • Roles otorgados en los niveles de carpeta: Refleja la estructura de operaciones de tu organización mediante niveles de carpetas. Cada carpeta se puede configurar con diferentes conjuntos de concesiones de acceso que estén alineados con las necesidades empresariales y operativas. Por ejemplo, una carpeta superior puede reflejar un departamento, una de sus carpetas secundarias puede reflejar el acceso a recursos y las operaciones 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. Usar las carpetas de esta manera puede garantizar una separación de acceso adecuada, mientras se respetan las políticas de permisos heredadas de las carpetas superiores y la organización. Esta práctica requiere menos mantenimiento de las políticas de permisos cuando se crean y administran recursos de Google Cloud.

  • Roles otorgados a nivel del proyecto: Otorga vinculaciones de roles a nivel del proyecto cuando sea necesario para seguir el principio de privilegio mínimo. Por ejemplo, si una principal necesita acceso a 3 de los 10 proyectos en una carpeta, debes otorgar acceso a cada uno de los 3 proyectos de forma individual; por el contrario, si otorgaste una función en la carpeta, el principal obtendrá acceso que no necesita a otros 7 proyectos.

    Como alternativa, puedes usar las condiciones de IAM para otorgar funciones a nivel de organización o de carpeta, pero solo para un subconjunto de carpetas o proyectos.

  • Otorga acceso solo a las principales dentro de tu dominio: Para mejorar la seguridad de tu organización, no otorgues roles a principales fuera de tu dominio. Para aplicar esta práctica recomendada, puedes aplicar la restricción de la política de la organización iam.allowedPolicyMemberDomains.

¿Qué sigue?