Información sobre las políticas

Las políticas de IAM administran el control de acceso para los recursos de Google Cloud. Se adjunta una política de IAM a un recurso. La política administra el acceso al recurso en sí y a cualquier recurso secundario a través de la herencia de políticas.

En este tema, se proporcionan ejemplos de JSON de las políticas de IAM, aunque YAML también es compatible.

Estructura de políticas

Una política es un grupo de vinculaciones, configuración de auditoría y metadatos. Una vinculación especifica cómo se debe otorgar acceso a los recursos. Asocia (o vincula) a uno o más miembros con una sola función y cualquier condición específica del contexto que cambie cómo y cuándo se otorga la función. El campo AuditConfig especifica los datos de configuración sobre cómo deben auditarse los intentos de acceso. Los metadatos incluyen información adicional sobre la política, como ETag y versión para facilitar la administración de políticas. Cada parte se describe a continuación:

  • Una lista de vinculaciones. Cada vinculación incluye los siguientes campos:
    • Un miembro, también conocido como identidad o principal, puede ser una cuenta de usuario, una cuenta de servicio, un Grupo de Google o un dominio
    • Una función es un conjunto de permisos con nombre que otorga acceso para realizar acciones en los recursos de Google Cloud
    • Una condición es una expresión lógica 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, etcétera. Por lo general, las condiciones se usan para controlar si se otorga el acceso en función del contexto de una solicitud
  • Un campo AuditConfig, que se usa a fin de configurar el registro de auditoría para la política
  • Metadatos, incluidos los siguientes campos:
    • Un campo etag, que se usa para el control de simultaneidad, y garantiza que las políticas se actualicen de forma coherente
    • Un campo version, que especifica la versión de esquema para una política determinada. El uso del campo version se explica con más detalle en la sección versiones de políticas.

Una vinculación de función en una política de IAM es la combinación de la función y una lista de miembros. Si una vinculación de función también contiene una condición, se la denomina una vinculación de función condicional.

Usa ETags en una política

Cuando varios sistemas intentan escribir en la misma política de IAM al mismo tiempo, existe el riesgo de que esos sistemas se reemplacen entre sí. Este riesgo existe porque la actualización de una política de IAM implica varias operaciones:

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

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

Para evitar este problema, la administración de identidades y accesos (IAM) admite el control de simultaneidad mediante el uso de un campo etag en la política. El valor de este campo cambia cada vez que se actualiza una política.

Cuando necesites actualizar una política, asegúrate de incluir el campo etag cuando escribas la política actualizada. Si la política se modificó desde que la recuperaste, el valor etag no coincidirá y la actualización fallará. Para la API de REST, recibes el código de estado HTTP 409 Conflict y el cuerpo de la respuesta es 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 nuevo, modifícala según sea necesario y escribe la política actualizada. Debes realizar reintentos de forma automática, con retirada exponencial, en cualquier herramienta que uses para administrar las políticas de IAM.

Para obtener información sobre cómo actualizar políticas mediante el patrón de lectura, modificación y escritura, consulta Otorga, cambia y revoca el acceso.

Ejemplo: Política simple

Considera la siguiente política de ejemplo que vincula a un miembro con una función:

{
  "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. Esta función le otorga a jie@example.com acceso casi ilimitado.

Ejemplo: Política con vinculaciones múltiples

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

{
  "bindings": [
    {
      "members": [
        "user:jie@example.com"
      ],
      "role": "roles/resourcemanager.organizationAdmin"
    },
    {
      "members": [
        "user:divya@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 función, a Jie y a Divya (divya@example.com) se les otorga la capacidad de crear proyectos mediante la función de creador de proyectos (roles/resourcemanager.projectCreator). En conjunto, estas vinculaciones otorgan acceso detallado a Jie y a Divya. El acceso otorgado a Divya es el subconjunto del acceso otorgado a Jie.

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

Considera la siguiente política de IAM, que vincula a los miembros con una función predefinida y usa una expresión de condición para restringir la vinculación de función:

{
  "bindings": [
    {
      "members": [
        "group:prod-dev@example.com",
        "serviceAccount:prod-dev-example@appspot.gserviceaccount.com"
      ],
      "role": "roles/appengine.deployer",
      "condition": {
          "title": "Expires_July_1_2020",
          "description": "Expires on July 1, 2020",
          "expression":
            "request.time < timestamp('2020-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 contiene una expresión de condición. La vinculación de la política es una vinculación de función condicional. Otorga la función 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 2020.

Para obtener detalles sobre las funciones que admite cada versión de la política, 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 IAM, que contiene vinculaciones de funciones condicionales y no condicionales para la misma función:

{
  "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_2020",
        "description": "Expires on July 1, 2020",
        "expression":
          "request.time < timestamp('2020-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 tiene una condición que solo otorga la función hasta el 1 de julio de 2020.

En efecto, esta política siempre otorga la función 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, el miembro siempre tiene esa función. Agregar el miembro a una vinculació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 2020.

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

Considera la siguiente política de ejemplo. Esta política vincula una función a un usuario, donald@example.com, cuya cuenta se borró:

{
  "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 la política al usuario borrado no se aplican al usuario nuevo. Este comportamiento evita que los usuarios nuevos hereden funciones que se otorgaron a usuarios borrados. Si deseas otorgar funciones al usuario nuevo, agrega el usuario nuevo a las vinculaciones de la política, como se muestra en Políticas con miembros borrados 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 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 que incluye a ese miembro, el nombre del miembro borrado tiene el prefijo deleted: y el sufijo ?uid=numeric-id.

Limitaciones de políticas

Se aplican las siguientes limitaciones a las políticas de IAM:

  • Cada recurso de Google Cloud que admite una política de IAM a su nivel en la jerarquía de recursos puede tener un máximo de una política. Es el caso de las organizaciones, las carpetas, los proyectos o los recursos individuales (como discos de Compute Engine, imágenes y más).
  • Cada política de IAM puede contener hasta 1,500 members. Hasta 250 de estos miembros pueden ser Grupos de Google.

    IAM cuenta todas las apariciones de cada miembro en las vinculaciones de la política. No anula el duplicado de los miembros que aparecen en más de una vinculación. Por ejemplo, si el miembro user:alice@example.com aparece en 50 vinculaciones, puedes agregar 1,450 miembros más entre todas las vinculaciones de la política.

  • En general, cualquier cambio en la política entrará en vigor dentro de los 60 segundos posteriores a la llamada a setIamPolicy() o cuando se actualice una vinculación de función en Cloud Console. Sin embargo, en determinadas circunstancias, los cambios en la política pueden demorar hasta 7 minutos en propagarse por completo en el sistema.

  • En este momento, algunos servicios de Google Cloud no admiten vinculaciones de funciones condicionales para las políticas a nivel de recurso, incluso si Google Cloud, el nombre del recurso o el tipo de recurso se puede usar en una vinculación de función condicional. Por ejemplo, en algunos casos, una política con una vinculación de función condicional que restringe el acceso al recurso de un servicio se puede configurar en el proyecto, pero no en el recurso. Para obtener más información, consulta la Referencia del atributo de las Condiciones de IAM.

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 el nodo raíz en la jerarquía. 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 IAM. A la hora de establecer una política 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 y todos los recursos bajo ese nivel. Por ejemplo, una política 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 establecida a nivel del 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 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 superiores en la jerarquía de recursos para un recurso. Es la unión de los siguientes elementos:

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

Cada vinculación de función nueva (heredada de recursos superiores) que afecta la política 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 función en cualquier nivel de la política 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, ten en cuenta la siguiente política de ejemplo que se establece a nivel de la organización:

Política a nivel de la organización

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

La función de visualizador de objetos de almacenamiento (roles/storage.objectViewer) contiene permisos get y list para proyectos y objetos de Cloud Storage. Cuando se establece a nivel de la organización, esta vinculación de función se aplica a los niveles de la organización, incluidos todos los proyectos y todos los objetos de Cloud Storage correspondientes.

Para demostrar aún más la herencia de políticas, considera lo que sucede cuando una política se establece en myproject-123:

Política a nivel de proyecto

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

En el ejemplo anterior, la función de creador de objetos de Storage (roles/storage.objectCreator) otorga a Divya la capacidad de crear objetos de Cloud Storage en myproject-123. Ahora que hay dos vinculaciones de funciones que otorgan acceso a Divya a los objetos de Cloud Storage de destino en myproject-123, se aplican las siguientes políticas:

  • Una política a nivel de organización permite enumerar y obtener todos los objetos de Cloud Storage de esta organización.
  • Una política 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 Divya:

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 Divya 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 puede agregar nuevas funciones que sumen o cambien campos de forma significativa en el esquema de política. Para evitar que se rompan las integraciones existentes que dependen de la coherencia en la estructura de políticas, estos cambios se ingresan en las nuevas versiones de esquema de política.

Si te integras a la IAM por primera vez, te recomendamos usar la versión más reciente del esquema de política 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 IAM existente especifica un campo version como parte de los metadatos de la política. 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 de esquema de sintaxis de la política. Cada versión de política contiene un esquema de sintaxis específico que pueden usar las vinculaciones. La versión más reciente puede contener vinculaciones de función 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 el control de esquema de sintaxis de política.

Versiones válidas de políticas

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

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 uno o más miembros. 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 obtienes una política de IAM, te recomendamos que especifiques una versión de la política en la solicitud. Cuando en una solicitud se especifica una versión de la política, 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, IAM supone que el emisor quiere una política de versión 1.

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

  • Si la política no contiene ninguna condición, IAM siempre mostrará una política de versión 1, sin importar el número de versión en la solicitud.
  • Si la política contiene condiciones y el emisor solicitó una política de versión 3, IAM muestra una política 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 contiene condiciones y el emisor solicitó una política de versión 1 o no especificó una versión, IAM muestra una política 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.

Mediante este comportamiento, se evitan problemas con las bibliotecas cliente más antiguas que no reconocen las vinculaciones de funciones condicionales. Para obtener más detalles, consulta Compatibilidad de las bibliotecas cliente con las versiones de políticas, 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 IAM 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 IAM del proyecto. Si la política contiene al menos una vinculación de función condicional, su campo version se establece en 3:

{
  "bindings": [
    {
      "members": [
        "user:user@example.com"
      ],
      "role": "roles/iam.securityReviewer",
      "condition": {
          "title": "Expires_July_1_2020",
          "description": "Expires on July 1, 2020",
          "expression": "request.time < timestamp('2020-07-01T00:00:00.000Z')"
      }
    }
  ],
  "etag": "BwWKmjvelug=",
  "version": 3
}

Si la política no contiene vinculaciones de funciones 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 IAM 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, 1.

La política contiene una vinculación de función condicional. Debido a que la versión de la política es 1, la condición no aparece en la respuesta. Para indicar que la vinculación de función usa una condición, IAM agrega la string _withcond_ al nombre de la función, 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 configuras una política de IAM, te recomendamos que especifiques una versión de la política en la solicitud. Cuando en una solicitud se especifica una versión de la política, 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, IAM solo permitirá los campos que pueden aparecer en una política de versión 1. Como práctica recomendada, no cambies las vinculaciones de funciones condicionales en una política de versión 1. Debido a que la política no muestra la condición de cada vinculación, no sabrás en qué momento o en qué ubicación se otorga la vinculación. En su lugar, obtén la representación de la versión 3 de la política, que muestra la condición de cada vinculación, y usa esa representación para actualizar las vinculaciones.

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

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

{
  "bindings": [
    {
      "members": [
        "user:divya@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 divya@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 la función y envías una solicitud a la API de REST para configurar la política. Una vez más, debes especificar la versión 3 en la solicitud:

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

La respuesta contiene la política actualizada:

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

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

Compatibilidad de las biblioteca cliente con las versiones de políticas

Algunas bibliotecas cliente para Google Cloud solo admiten políticas de la versión 1. Si tu biblioteca cliente no admite versiones posteriores de políticas, no podrás usar funciones que solo están disponibles en las versiones posteriores. Por ejemplo, las Condiciones de IAM requieren compatibilidad con la versión 3 de las políticas.

Si usas características de IAM que no están disponibles en las políticas de versión 1, como las Condiciones de IAM, usa una biblioteca cliente que admita esa versión de la política y la configure de forma correcta en la solicitud.

Las siguientes bibliotecas cliente de las API de Google para la versión 3 de la política de asistencia de IAM:

Lenguaje Versiones que admiten la versión 3 de las políticas
C# Google.Apis >=v1.41.1
Go google-api-go-client >=v0.10.0
Java
Node.js googleapis >=v43.0.0
PHP google/apiclient >=v2.4.0
Python google-api-python-client >=v1.7.11
Ruby google-api-client >=v0.31.0

Puedes usar estas bibliotecas cliente a fin de administrar las políticas de IAM de la versión 3 en los recursos para los siguientes servicios:

  • IAM
  • Cloud KMS
  • Cloud Storage
  • Compute Engine
  • Resource Manager

Otras bibliotecas cliente, incluidas las bibliotecas cliente de Google Cloud, solo admiten políticas de la versión 1.

Compatibilidad de gcloud con las versiones de políticas

Si usas la herramienta de gcloud para administrar las políticas de IAM, asegúrate de usar la versión 263.0.0 o una posterior. Las versiones anteriores solo admiten las políticas de la versión 1.

Para verificar el número de versión de la herramienta de gcloud, ejecuta gcloud version. Para actualizar a la versión más reciente, ejecuta gcloud components update.

Políticas con miembros borrados

Si una vinculación en una política incluye un miembro borrado y agregas una vinculación para un miembro nuevo con el mismo nombre, la vinculación siempre se aplica al miembro nuevo.

Por ejemplo, considera esta política, que incluye una vinculación a un usuario borrado, donald@example.com, y una cuenta de servicio borrada, my-service-account@project-id.iam.gserviceaccount.com:

{
  "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 vincularlo con la función Creador de proyectos (roles/resourcemanager.projectCreator), que permite a los usuarios crear proyectos de Google Cloud. Para vincular al usuario nuevo, actualiza la política 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 IAM, también puedes quitar al usuario borrado de la vinculación a la función de propietario:

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

  • Permisos otorgados a nivel de la organización: Considera de forma cuidadosa qué miembros tienen permisos de acceso 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.

  • Permisos otorgados en los niveles de carpeta: Refleja la estructura de operaciones de tu organización mediante niveles de carpetas. Cada carpeta superior o secundaria 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 heredadas de las carpetas superiores y la organización. Esta práctica requiere menos mantenimiento de políticas cuando se crean y administran recursos de Google Cloud.

  • Permisos otorgados a nivel del proyecto: Otorga vinculaciones de función a nivel del proyecto solo cuando sea necesario para grupos específicos o permisos detallados individuales. Para facilitar la administración, en especial con muchos proyectos, te recomendamos que establezcas políticas a nivel de carpeta cuando sea posible.

Próximos pasos