Solucionar problemas relacionados con "withcond" en políticas y vinculaciones de roles

Cuando veas una política de permiso, es posible que veas nombres de roles que incluyan la cadena withcond, seguida de un valor hash. Por ejemplo, puede que veas un nombre de rol como roles/iam.serviceAccountAdmin_withcond_2b17cc25d2cd9e2c54d8.

En esta página se explica cuándo y por qué puede ver la cadena withcond en una política de permitidos. También recomienda las acciones que debes llevar a cabo si ves esta cadena.

Versiones de políticas y vinculaciones de roles condicionales

Una política de permiso se puede representar de varias formas. Cada formulario se conoce como versión de la política de permisos.

En una política de permiso que usa la versión 1, algunas vinculaciones de roles pueden contener la cadena withcond en un nombre de rol, seguida de un valor hash:

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

Este formato indica que la vinculación de roles es condicional. Es decir, el rol solo se concede si se cumplen determinadas condiciones.

Las políticas de la versión 1 no muestran estas condiciones. Si ve la cadena withcond y un valor hash, significa que la vinculación de roles incluye una condición que no puede ver.

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

Para asegurarse de que puede ver y actualizar toda la política de permisos, incluidas sus condiciones, siempre debe especificar la versión 3 cuando obtenga o defina una política de permisos. Para especificar la versión 3, completa las tareas que se indican en las siguientes secciones.

Actualizar la herramienta gcloud

Si usas la CLI de Google Cloud, ejecuta gcloud version para comprobar su número de versión. El resultado incluye una cadena similar a Google Cloud CLI 279.0.0.

Si el número de versión es inferior a 263.0.0, ejecuta gcloud components update para actualizar la interfaz de línea de comandos de gcloud. En la versión 263.0.0 y posteriores, la CLI de gcloud especifica automáticamente una versión de la política de permiso que admite condiciones.

Actualizar bibliotecas de cliente

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

  1. Busca el nombre y el número de versión de la biblioteca de cliente y, a continuación, consulta la lista de bibliotecas de cliente que admiten versiones de la política de permiso.

    • Si ya usas una versión reciente de la biblioteca de cliente y esta admite versiones de la política de permisos, no es necesario que la actualices. Ve al siguiente paso.

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

    • Si usas una biblioteca de cliente que no admite versiones de la política de permiso, puedes añadir otra biblioteca de cliente que sí las admita a tu aplicación. Usa esa biblioteca de cliente para trabajar con políticas de permiso. También puedes usar directamente la API REST de IAM.

  2. Actualiza el código de tu aplicación que obtiene y define las políticas de permiso:

Actualizar las llamadas a la API REST

Si tu aplicación usa la API REST de gestión de identidades y accesos directamente, actualiza el código que obtiene y define las políticas de permiso:

Herramientas de gestión de actualizaciones para políticas

Si conservas copias locales de tus políticas de permiso (por ejemplo, si las almacenas en un sistema de control de versiones y las tratas como código), asegúrate de que todas las herramientas que utilices cumplan estos criterios:

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

Si una herramienta no cumple estos criterios, busca una versión actualizada de la herramienta.

Además, asegúrate de que tus herramientas de gestión conserven las concesiones de roles condicionales en lugar de añadir una concesión de rol duplicada que no incluya una condición. Por ejemplo, supongamos que se da la siguiente situación:

  1. Asigna el rol Crear cuentas de servicio (roles/iam.serviceAccountCreator) al usuario Mahan en la carpeta my-folder. La política de permiso de la carpeta tiene un aspecto similar al de este ejemplo:

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

  2. Usas una herramienta para recuperar la política de permiso y almacenarla en un sistema de control de versiones.

  3. Añades una condición para que Mahan solo pueda crear cuentas de servicio durante la semana laboral normal, según la fecha y la hora de Berlín (Alemania). La política de permisos actualizada tiene un aspecto similar al de este ejemplo:

    {
  "bindings": [
    {
      "members": [
        "user:mahan@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. Usa una herramienta para recuperar la política de permiso actualizada. La herramienta no especifica una versión de la política de permiso cuando solicita la política de permiso, por lo que recibes una versión 1 de la política de permiso con un nombre de rol modificado:

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

En este punto, la herramienta de gestión puede decidir que el enlace de Mahan al rol roles/iam.serviceAccountCreator ha desaparecido y que debe restaurar el enlace de rol original a la política de permiso:

Evita: vinculación de roles adicional sin condición

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

Este cambio no es correcto. Se le asigna el rol roles/iam.serviceAccountCreator a Mahan independientemente del día de la semana. Por lo tanto, la condición de la primera vinculación de rol no tiene ningún efecto.

Si tus herramientas de gestión intentan hacer este tipo de cambio, no lo apruebes. En su lugar, debe actualizar sus herramientas de gestión para especificar la versión 3 en las solicitudes.

Siguientes pasos