Información sobre las políticas

Las políticas de Cloud IAM administran el control de acceso para los recursos de Google Cloud. Una política de Cloud IAM se vincula a un recurso y restringe el acceso al recurso en sí mismo y a los recursos secundarios a través de la herencia de políticas.

En este tema, se proporcionan ejemplos de JSON de las políticas de Cloud 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. Las condiciones suelen usarse para expresar restricciones en función del contexto en el que se realiza la solicitud de acceso.
  • 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 Cloud 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 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 Cloud IAM al mismo tiempo, existe el riesgo de que esos sistemas se reemplacen entre sí. Este riesgo surge porque modificar una política de Cloud IAM implica tres operaciones: recuperar la política actual, modificar su contenido según se desee y, luego, establecer la nueva política en su totalidad. Si dos sistemas están haciendo esto a la vez, es posible que uno de ellos establezca una política actualizada sin advertir que la política se modificó entre el momento en que se recuperó y el actual.

Para evitar este tipo de situaciones, Cloud IAM admite el control de simultaneidad mediante el uso de un campo etag en la política. Siempre que recuperes una política, asegúrate de usar el campo etag de la política recuperada cuando envíes la política modificada. Si la política se modificó desde que la recuperaste, el campo etag no coincidirá y la actualización fallará.

Cuando esto ocurra, vuelve a intentar toda la operación: recupera la política de nuevo, aplica las modificaciones y envía la política actualizada. Te recomendamos que realices esta lógica de reintento de forma automática en cualquier código o secuencia de comandos que uses para administrar las políticas de Cloud IAM.

Ejemplo: Política simple

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

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

En el ejemplo anterior, a jim@example.com se le otorga la función básica de propietario sin ninguna condición. La vinculación a una función básica suele ser demasiado permisiva. En este caso, la función de propietario contiene más de 1,000 permisos. Recomendamos que otorgues una función predefinida o una función personalizada en lugar de una función básica. Estos tipos de funciones están diseñadas con un alcance y un número de permisos limitados.

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:jim@example.com"
          ],
          "role": "roles/resourcemanager.organizationAdmin"
        },
        {
          "members": [
            "user:alice@example.com",
            "user:jim@example.com"
          ],
          "role": "roles/resourcemanager.projectCreator"
        }
      ],
      "etag": "BwUjMhCsNvY=",
      "version": 1
    }
    

En el ejemplo anterior, a Jim (jim@example.com) se le otorga la función predefinida de administrador de 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, Jim y Alice (alice@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 otorgan acceso detallado a Jim y Alice; el acceso otorgado a Alice es el subconjunto del acceso otorgado a Jim.

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

Considera la siguiente política de Cloud 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 policy está establecido en 3, porque la política contiene una expresión de condición. La vinculación en 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 más información acerca de las funciones que admite cada versión de la política, consulte Versiones de la política en esta página.

Limitaciones de políticas

Las siguientes limitaciones se aplican a las políticas de Cloud IAM:

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

    Cloud IAM cuenta todos los miembros de cada vinculación. 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, entonces podría agregar otros 1.450 miembros en 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.

  • Actualmente, algunos servicios de Google Cloud no admiten políticas condicionales a nivel de recursos. Por ejemplo, se puede establecer una política condicional que restrinja el acceso al recurso de un servicio en el proyecto, pero no se admite una política condicional en el recurso. Para obtener más información, consulta la referencia del atributo de condiciones de Cloud 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 se configura una política de Cloud IAM. A la hora de establecer una política en un nivel superior en la jerarquía, a nivel de organización, carpeta o proyecto, el alcance 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:alice@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 del proyecto

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

En el ejemplo anterior, la función de Creador de objetos de almacenamiento (roles/storage.objectCreator) otorga a Alice la capacidad de crear objetos de Cloud Storage, en myproject-123. Ahora hay dos vinculaciones de función que le otorgan a Alice acceso a los objetos de Cloud Storage de destino en myproject-123.

  • Una política a nivel de la organización permite enumerar y obtener todos los objetos de Cloud Storage de esta organización.
  • Una política en myproject-123 otorga la capacidad de crear objetos, en myproject-123, en el que se vincula la política.

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

Permisos otorgados mediante la función “storage.objectViewer” a nivel de la organización Permisos otorgados mediante la función “storage.objectCreator” en “myproject-123” Alcance de concesión efectivo para Alice 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, Cloud IAM puede agregar nuevas funciones que sumen o cambien campos de forma significativa en el esquema de políticas. 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 Cloud IAM por primera vez, te recomendamos que uses la versión más reciente de 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 Cloud 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:jim@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 de políticas válidas

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

Versión Descripción
1 La primera versión del esquema de sintaxis de Cloud IAM para políticas. Admite la vinculación de una función con uno o más miembros. No es compatible con las vinculaciones de función condicional.
2 Reservada para uso interno.
3 Presenta el campo condition en la vinculación de funciones, que restringe la vinculación de funciones mediante reglas basadas en atributos y basadas en contexto. Para obtener más información, consulta la descripción general de las condiciones de Cloud 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 Cloud IAM, te recomendamos que especifiques una versión de política en la solicitud. Cuando una solicitud especifica una versión de política, Cloud IAM supone que el emisor conoce las características de esa versión de política y puede manejarlas correctamente.

Si la solicitud no especifica una versión de política, Cloud IAM supone que el emisor desea una política de versión 1.

Cuando obtienes una política, Cloud IAM comprueba la versión de la política en la solicitud o la versión predeterminada si la solicitud no especifica una versión. Cloud IAM también verifica la política para detectar campos que no se admiten en una política de versión 1. Utiliza esta información para decidir qué tipo de respuesta enviar:

  • Si la política no contiene ninguna condición, entonces Cloud IAM siempre muestra una política de versión 1, independientemente del número de versión de la solicitud.
  • Si la política contiene condiciones y el emisor solicitó una política de versión 3, entonces Cloud IAM muestra una política de versión 3 que incluye las condiciones. Para ver un ejemplo, consulta la situación 1 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, entonces Cloud IAM muestra una política de versión 1.

    Para las vinculaciones de función que incluyen una condición, Cloud IAM agrega la string _withcond_ al nombre de la función, seguido de un valor 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 en esta página.

Este comportamiento evita los problemas con las bibliotecas cliente antiguas que no tienen conocimiento de las vinculaciones de función condicional. Para obtener más información, consulte Compatibilidad con bibliotecas cliente para las versiones de políticas en esta página.

Situación 1: Versión de la política que admite completamente las condiciones de Cloud IAM

Supongamos que llamas al siguiente método de la API de REST para obtener la política de Cloud IAM para 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 Cloud 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 función condicional, su campo version se establece en 1, aunque la solicitud especifica la versión 3:

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

Situación 2: Versión de política con compatibilidad limitada con las condiciones de Cloud IAM

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

POST https://cloudresourcemanager.googleapis.com/v1/projects/[PROJECT-ID]:getIamPolicy
    

El cuerpo de la solicitud está vacío. no especifica un número de versión. Como resultado, Cloud IAM usa la versión de política predeterminada, 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 funciones usa una condición, Cloud IAM agrega la string _withcond_ al nombre de la función, seguida de un valor hash:

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

Cómo especificar una versión de política al configurar una política

Cuando estableces una política de Cloud IAM, te recomendamos que especifiques una versión de política en la solicitud. Cuando una solicitud especifica una versión de política, Cloud IAM supone que el emisor conoce las características de esa versión de política y puede manejarlas correctamente.

Si la solicitud no especifica una versión de política, Cloud IAM solo permite los campos que pueden aparecer en una política de versión 1. Como práctica recomendada, no cambie las vinculaciones de función condicional en una política de versión 1. Debido a que la política no muestra la condición para cada vinculación, no sabe cuándo ni dónde se otorga realmente 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 Cloud IAM y especificas la versión 3 en la solicitud. La respuesta contiene la siguiente política, que usa la versión 3:

{
      "bindings": [
        {
          "members": [
            "user:alice@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
    }

Usted decide que alice@example.com debe tener la función de administrador de almacenamiento (roles/storage.admin) durante toda la semana, no solo los días de semana. Quitas la condición de la vinculación de función y envías una solicitud de la API de REST para establecer la política. Una vez más, especificas la versión 3 en la solicitud:

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

La respuesta contiene la política actualizada:

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

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

Asistencia de la biblioteca cliente para las versiones de políticas

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

Si usas funciones de Cloud IAM que no están disponibles en las políticas de la versión 1, como las condiciones de Cloud IAM, usa una biblioteca cliente que admita esa versión de política y la establezca correctamente en la solicitud.

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

Idioma Versiones que admiten la política de versión 3
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 para administrar las políticas de versión 3 de Cloud IAM de los recursos para los siguientes servicios:

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

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

Compatibilidad con gcloud para las versiones de políticas

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

Para comprobar el número de versión de la herramienta gcloud, ejecute gcloud version. Para actualizar a la última versión, ejecute gcloud components update.

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 en el nivel de la carpeta cuando sea posible.

Qué sigue