Soluciona problemas con “withcond” en políticas y vinculaciones de funciones

Cuando veas una política de permisos, es posible que veas nombres de roles que incluyen la string withcond, seguida de un valor de hash. Por ejemplo, es posible que veas el nombre de un rol como roles/iam.serviceAccountAdmin_withcond_2b17cc25d2cd9e2c54d8.

En esta página, se explica cuándo y por qué podrías ver la string withcond en una política de permisos. También se recomiendan acciones que debes realizar si ves esta string.

Versiones de políticas y vinculaciones de funciones condicionales

Una política de permisos se puede representar de varias formas diferentes. Cada forma se conoce como una versión de la política de permisos.

En una política de permisos que usa la versión 1, puede que algunas vinculaciones de roles contengan la string withcond en un nombre de rol, seguida de un valor de hash:

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

Mediante este formato, se indica que la vinculación de la función es condicional. En otras palabras, la función se otorga solo si se cumplen condiciones específicas.

Las políticas de permisos de la versión 1 no muestran estas condiciones. Si ves la string withcond y un valor de hash, la vinculación de la función incluye una condición que no puedes ver.

Solución: Especifica la versión 3 de la política

Para asegurarte de que puedes ver y actualizar toda la política de permisos, incluidas sus condiciones, siempre debes especificar la versión 3 cuando obtengas o establezcas una política de permisos. Para especificar la versión 3, debes completar las tareas de las siguientes secciones.

Actualiza la herramienta de gcloud

Si usas Google Cloud CLI, ejecuta gcloud version para verificar su número de versión. En el resultado, se incluye una string similar a Google Cloud CLI 279.0.0.

Si el número de la versión es inferior a 263.0.0, ejecuta gcloud components update para actualizar la CLI de gcloud. En la versión 263.0.0 y en las posteriores, la CLI de gcloud especifica de forma automática una versión de la política de permisos que admite condiciones.

Actualiza las bibliotecas cliente

Si tu aplicación usa una biblioteca cliente, sigue estos pasos:

  1. Busca el nombre y el número de la versión de la biblioteca cliente y, luego, revisa la lista de bibliotecas cliente que admiten versiones de políticas de permisos.

    • Si ya usas una versión reciente de la biblioteca cliente que admite versiones de políticas, no necesitas actualizar tu biblioteca cliente. Avanza al siguiente paso.

    • Si usas una versión anterior de la biblioteca cliente y una versión posterior admite versiones de políticas de permisos, actualízala a la versión más reciente.

    • Si usas una biblioteca cliente que no admite versiones de políticas de permisos, puedes agregar otra biblioteca cliente que sí las admita en tu aplicación. Usa esa biblioteca cliente para trabajar con políticas de permisos. Como alternativa, puedes usar la API de REST de IAM directamente.

  2. Actualiza cualquier código de tu aplicación que obtenga y establezca políticas de permisos:

Actualiza las llamadas a la API de REST

Si tu aplicación usa directamente la API de REST de IAM, actualiza cualquier código que obtenga y establezca políticas de permisos:

Actualiza herramientas de administración para las políticas

Si guardas copias locales de tus políticas de permisos, por ejemplo, si las almacenas en un sistema de control de versión y las tratas como código, asegúrate de que todas las herramientas que uses cumplan con estos criterios:

  • Todas las solicitudes para obtener o configurar una política de permisos especifican la versión 3
  • Todas las solicitudes para establecer una política de permisos incluyen el campo etag en la solicitud

Si una herramienta no cumple con estos criterios, verifica si existe una versión actualizada de la herramienta.

Además, asegúrate de que las herramientas de administración conserven las asignaciones de funciones condicionales, en lugar de agregar una asignación duplicada de funciones que no incluya una condición. Por ejemplo, considera la siguiente situación:

  1. Otorgas la función de creador de cuentas de servicio (roles/iam.serviceAccountCreator) al usuario vikram@example.com en la carpeta my-folder. La política de permisos para la carpeta es similar a este ejemplo:

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

  2. Usas una herramienta para recuperar la política de permisos y almacenarla en un sistema de control de versión.

  3. Agregas una condición para que vikram@example.com pueda crear cuentas de servicio solo durante la semana laboral normal, en función de la fecha y la hora de Berlín, Alemania. La política de permisos actualizada es similar al siguiente ejemplo:

    {
  "bindings": [
    {
      "members": [
        "user:vikram@example.com"
      ],
      "role": "roles/iam.serviceAccountCreator",
      "condition": {
        "title": "work_week_only",
        "expression": "request.time.getDayOfWeek('Europe/Berlin') >= 1 && request.time.getDayOfWeek('Europe/Berlin') <= 5"
      }
    }
  ],
  "etag": "BwWcR/B3tNk=",
  "version": 3
}

  4. Usas una herramienta para recuperar la política de permisos actualizada. La herramienta no especifica una versión de la política de permisos cuando la solicita, por lo que recibes una política de permisos de versión 1 con un nombre de rol modificado:

    {
  "bindings": [
    {
      "members": [
        "user:vikram@example.com"
      ],
      "role": "roles/iam.serviceAccountCreator_withcond_a75dc089e6fa084bd379"
    }
  ],
  "etag": "BwWcR/B3tNk=",
  "version": 1
}

En este punto, puede que la herramienta de administración decida que desapareció la vinculación de vikram@example.com al rol roles/iam.serviceAccountCreator y que se debería restablecer la vinculación de rol original a la política de permisos:

Evita las vinculaciones adicionales de las funciones sin condiciones.

{
  "bindings": [
    {
      "members": [
        "user:vikram@example.com"
      ],
      "role": "roles/iam.serviceAccountCreator_withcond_a75dc089e6fa084bd379"
    },
    {
      "members": [
        "user:vikram@example.com"
      ],
      "role": "roles/iam.serviceAccountCreator"
    }
  ],
  "etag": "BwWd3HjhKxE=",
  "version": 1
}

Este cambio no es correcto. Le otorga la función roles/iam.serviceAccountCreator a vikram@example.com sin importar el día de la semana. Como resultado, la condición de la primera vinculación de la función no tiene efecto.

Si tus herramientas de administración intentan realizar este tipo de cambio, no debes aprobarlo. En su lugar, debes actualizar tus herramientas de administración para especificar la versión 3 en las solicitudes.

¿Qué sigue?