Información sobre las políticas

El control de acceso para los recursos de Google Cloud se administra mediante políticas de IAM, que están adjuntas a los recursos. Solo puedes adjuntar una política de IAM a cada recurso. La política de IAM controla el acceso al recurso, así como a todos los descendientes de ese recurso que heredan la política.

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 de IAM es un conjunto de vinculaciones de funciones y metadatos. Una vinculación de función especifica qué acceso se debe otorgar a un recurso. Asocia (o vincula) a uno o más miembros con una sola función de IAM y cualquier condición específica del contexto que cambie cómo y cuándo se otorga la función. Los metadatos incluyen información adicional sobre la política, como un ETag y la versión para facilitar la administración de políticas.

Cada vinculación de función puede incluir 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

    Cada política de IAM puede contener hasta 1,500 miembros. 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.

  • 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, etcétera. 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 función también contiene una condición, se la denomina una vinculación de función condicional.

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

Los metadatos de una política de IAM incluyen 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 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 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 IAM 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 IAM, consulta Configura registros de auditoría de acceso a los datos.

En general, cuando actualizas una política de IAM, los cambios entrarán en vigor en 60 segundos. Sin embargo, en algunos casos, el cambio puede tomar hasta 7 minutos en propagarse por completo en Google Cloud.

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 lees una política, la política incluye un campo etag con el valor etag actual, como BwUjMhCsNvY=. Cuando escribas la política actualizada, asegúrate de incluir este mismo valor en el campo etag de la política. Si se modificó la política 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 nuevo, modifícala según sea necesario y escribe la política actualizada. Debes realizar reintentos de forma automática, con la 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 múltiples vinculaciones de función

Considera la siguiente política de ejemplo que contiene más de una vinculación de funció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, Jie y Divya (divya@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 función otorgan acceso detallado a Jie y Divya, y a Jie posee más acceso que Divya.

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_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 contiene una expresión de condición. La vinculación de función de la política es 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 2022.

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_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 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 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 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 función de la política para el 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 función de la política, como se muestra en Políticas con miembros borrados de 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.

Políticas predeterminadas

Todos los recursos que aceptan políticas de IAM se crean con políticas de IAM predeterminadas. La mayoría de las políticas predeterminadas de los recursos están vacías. Sin embargo, las políticas predeterminadas de algunos recursos contienen automáticamente ciertas vinculaciones de función. Por ejemplo, cuando creas un proyecto nuevo, la política de IAM para el proyecto tiene automáticamente una vinculación de función que te otorga la función de propietario (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 IAM, 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 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 podría 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 de función. 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_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 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 de funció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 de función, y usa esa representación para actualizar las vinculaciones de función.

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 IAM admiten la versión 3 de la política:

Idioma 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

Puedes administrar las políticas de IAM de la versión 3 con la herramienta de gcloud. Para actualizar a la versión más reciente, ejecuta gcloud components update.

Políticas con miembros borrados

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

Por ejemplo, considera esta política, que incluye una vinculación de funció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 las políticas de IAM, también puedes quitar al usuario borrado de la vinculación de funció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