Descripción general de la autenticación de API basada en IAM

Esta página se aplica a Apigee, pero no a Apigee Hybrid.

Apigee admite la autenticación y la autorización basadas en IAM para los proxies de API. Con esta solución, el acceso para invocar una API se basa en varios factores, como si el flujo de solicitud incluye la política VerifyIAM y si el consumidor de la API tiene el rol o los permisos de Google Cloud IAM necesarios para invocar las APIs de Apigee. La autorización se puede otorgar a cualquier principal de Google Cloud y no se limita a usuarios individuales.

Usa el control de acceso basado en IAM

En esta sección, se describe el proceso de extremo a extremo para configurar la autenticación y la autorización basadas en IAM, cómo se evalúan las solicitudes una vez que se configura el acceso y cómo revocar el acceso de los consumidores de la API que ya tenían acceso.

Agrega la administración de acceso

Para configurar la administración de acceso de un proxy de API, haz lo siguiente:

  1. Agrega la política VerifyIAM a los proxies de API de Apigee como parte del flujo de solicitudes.
  2. El administrador de Cloud del proyecto de Apigee debe hacer lo siguiente:
    1. Otorga el rol de IAM deploymentInvoker (o un rol personalizado con el permiso de IAM apigee.deployments.invoke) al principal de Google Cloud del consumidor de la API a nivel del proyecto. Esto le otorga al consumidor de la API acceso para invocar todas las APIs alojadas en la organización de Apigee asociada.

      o

    2. Usa la acción SetIamPolicy para otorgar el rol o el permiso al principio de Google Cloud del consumidor de la API en una implementación en particular o de forma iterativa en varias implementaciones. Usa la operación de lista en el recurso de implementación para ver todas las implementaciones dentro de un entorno, incluidos los proxies de API y los flujos compartidos. El nombre de la implementación es el nombre del proxy de API o del flujo compartido.
  3. Dirige al consumidor de la API a generar un token de acceso, que pasará dentro de la solicitud a la API de Apigee para la verificación de permisos. El token generado debe tener el permiso de autenticación https://www.googleapis.com/auth/cloud-platform.

Operaciones del administrador

En esta sección, se enumeran las acciones que realizan los administradores de la API (productores de la API) cuando administran permisos basados en IAM.

La documentación de las operaciones basadas en la API que se usan cuando se administra el acceso basado en IAM se encuentra en la documentación de referencia de las APIs organizations.environments y organizations.environments.deployments, y las operaciones SetIamPolicy, GetIamPolicy, TestIamPermissions y GetDeployment.

En esta tabla, se asignan las operaciones a los permisos necesarios:

Operación del administrador Acción Se requiere permiso de IAM Recurso de IAM en el que se necesita el permiso*
GetDeployment Recupera información de una implementación en un entorno de Apigee apigee.deployments.get Proyecto de Google Cloud o entorno de Apigee
ListDeployments Enumera las implementaciones de un entorno de Apigee apigee.deployments.list Proyecto o entorno de Apigee
SetIamPolicy Configura el acceso de invocación para los consumidores de la API en una implementación de API en particular apigee.deployments.setIamPolicy Proyecto de Google Cloud o entorno de Apigee
GetIamPolicy Recupera el conjunto de parámetros de configuración de acceso de invocación para una implementación de API apigee.deployments.getIamPolicy Proyecto de Google Cloud o entorno de Apigee
TestIamPermissions Verifica si el usuario que llama a esta API tiene el permiso mencionado en la carga útil. No se necesita permiso de IAM N/A
* El proyecto de Google Cloud es el que se usa para aprovisionar Apigee. Los permisos a nivel del entorno de Apigee se establecen en el entorno con setIAMPolicy.

Verificación de acceso al entorno de ejecución

Cuando el consumidor de la API intenta acceder a una API con un control de acceso basado en IAM, se realiza una verificación para ver si tiene el token de acceso necesario y el rol o permiso adecuados a nivel del proyecto o de la implementación. Si es así, se le permite continuar con el acceso al proxy. De lo contrario, se bloquean.

Quitar acceso

Para quitar el acceso a nivel del proyecto: Para quitar el acceso de un consumidor de API que se administra a nivel del proyecto, el administrador de Cloud del proyecto de Apigee revoca el rol de IAM deploymentInvoker (o el rol personalizado con el permiso de IAM apigee.deployments.invoke) del principal de Google Cloud del consumidor de API para el proyecto de Google Cloud.

Si se otorgó acceso a implementaciones individuales con setIamPolicy, quita el rol o el permiso de las implementaciones con otra operación setIamPolicy.

Características y limitaciones del control de acceso basado en IAM

Ten en cuenta estas características y limitaciones cuando uses la autenticación y autorización basadas en IAM:

  • Por lo general, la ejecución de políticas con VerifyIAM tarda aproximadamente 10 milisegundos. Sin embargo, algunas llamadas pueden experimentar latencias de finalización de aproximadamente 50 ms. Por ejemplo, en la región de asia-east2 específicamente, la latencia promedio puede aumentar a 50 ms, y algunas llamadas pueden tardar alrededor de 100 ms en completarse.

    Ten en cuenta que estas cifras de latencia no están garantizadas.
  • La inclusión de la política de VerifyIAM para un proxy es solo una verificación de verificación o no verificación. Los roles y permisos específicos del consumidor de la API no se consideran en procesos posteriores del flujo de solicitud o respuesta.
  • Dado que una verificación de autorización solo se realiza en el momento de la ejecución de la política de VerifyIAM, esta debe ser la primera política en el flujo de solicitud, después de solo las políticas de administración de tráfico.
  • Si la validación de permisos se realiza correctamente o el productor de la API marcó la política VerifyIAM para que continúe en caso de error, el flujo de solicitudes seguirá ejecutando las otras políticas, si las hay, y, en última instancia, llegará al servidor de destino. Si la verificación de permisos falla y el productor de la API no marcó la política para que continúe en caso de error, el usuario recibirá un error.
  • Agregar acceso de invocación (apigee.deployments.invoke) a nivel del entorno no transmite el acceso de invocación a todas las implementaciones de API dentro del entorno.
  • Las condiciones de IAM no son compatibles con el recurso de implementación y no se pueden usar para controlar el acceso de invocación. Consulta Agrega condiciones de IAM de Apigee a las políticas para obtener más información.
  • El control de acceso basado en IAM admite un máximo de 1,500 vinculaciones de roles dentro de una sola política y otras limitaciones. Consulta Cuotas y límites de IAM.
  • El control de acceso basado en IAM está sujeto a demoras de propagación de IAM.
  • Si intentas administrar otras operaciones de apigee.deployments, como apigee.deployments.delete a través de setIAMPolicy a nivel de la implementación, no será eficaz, pero tampoco se mostrará un error. Solo apigee.deployements.invoke es efectivo.
  • El acceso en una implementación se borra cuando se desimplementa o se borra el proxy correspondiente. El acceso se debe volver a agregar en la nueva implementación.
  • La autenticación y autorización basadas en IAM no están disponibles en el entorno híbrido en este momento.

Ejemplos

En esta sección, se proporcionan ejemplos para otorgar y revocar el acceso a las APIs basado en IAM. En estos ejemplos, se da por sentado que VerifyIAM ya se agregó al proxy de API adecuado.

En estos ejemplos, usa la consola de Cloud o gcloud (que se muestra) para administrar roles o permisos en el principal de Google Cloud del consumidor de la API. El $Project de los ejemplos es el proyecto de Google Cloud.

Otorga y revoca el acceso de los usuarios para invocar todas las APIs de una organización de Apigee

Para agregar acceso, agrega el rol deploymentInvoker:

gcloud projects add-iam-policy-binding {$Project} --member={$user} --role='roles/apigee.deploymentInvoker'

Para revocar el acceso, quita el rol deploymentInvoker:

gcloud projects remove-iam-policy-binding {$Project} --member={$user} --role='roles/apigee.deploymentInvoker'

Otorga y revoca el acceso de los usuarios a implementaciones específicas dentro de un entorno

Para agregar el rol de invocador de un usuario a una implementación específica, haz lo siguiente:

curl 'https://apigee.googleapis.com/v1/organizations/{org}/environments/{env}/deployments/{api}:setIamPolicy' \
    --header 'Authorization: Bearer $TOKEN ' \
    --header 'Content-Type: application/json' \
    --data '{"policy":{"bindings":[{"members":["user:$user"],"role":"roles/apigee.deploymentInvoker"}]}}'
   

Una respuesta correcta debería verse de la siguiente manera:

  {
    "version": 1,
    "etag": "BwYT8i40Vwo=",
    "bindings": [
      {
        "role": "roles/apigee.deploymentInvoker",
        "members": [
          "user:$user"
        ]
      }
    ]
  }

Para confirmar que el objeto de política que agregaste se conserva correctamente (opcional), haz lo siguiente:

curl 'https://apigee.googleapis.com/v1/organizations/{org}/environments/{env}/deployments/{api}:getIamPolicy' \
  --header 'Authorization: Bearer $TOKEN'

Deberías ver una respuesta correcta como la que se muestra arriba.

Para que el usuario verifique si puede acceder a la implementación especificada (si el permiso apigee.deployments.invoke está configurado para el usuario especificado en una implementación especificada), indícale que envíe esta solicitud con el token de acceso que generó anteriormente:

curl 'https://apigee.googleapis.com/v1/organizations/{org}/environments/{env}/deployments/{api}:testIamPermissions' \
  --header 'Authorization: Bearer $TOKEN' \
  --header 'Content-Type: application/json' \
  --header 'Accept: application/json' \
  --data '{"permissions":["apigee.deployments.invoke"]}'

La respuesta debe incluir el permiso apigee.deployments.invoke para el usuario.

Para revocar el acceso a una implementación específica, quita el rol deploymentInvoker. Primero, obtén el objeto de política que está asociado actualmente con la implementación:

curl 'https://apigee.googleapis.com/v1/organizations/{org}/environments/{env}/deployments/{api}:getIamPolicy' \
  --header 'Authorization: Bearer $TOKEN'

La respuesta correcta debería ser similar a la siguiente. Ten en cuenta que es posible que también veas otras vinculaciones.

{
  "version": 1,
  "etag": "BwYT8i40Vwo=",
  "bindings": [
      {
        "role": "roles/apigee.deploymentInvoker",
        "members": [
          "user:$user"
        ]
      }
    ]
  }

Para quitar la vinculación, sigue estos pasos:

curl 'https://apigee.googleapis.com/v1/organizations/{org}/environments/{env}/deployments/{api}:setIamPolicy' \
  --header 'Authorization: Bearer $TOKEN' \
  --header 'Content-Type: application/json' \
  --data '{}'

Ten en cuenta que proporcionar una carga útil vacía quita el acceso a todos los usuarios, pero es apropiado en este ejemplo porque solo tenemos un usuario con acceso. Cuando quites el acceso de un usuario en una circunstancia en la que el acceso debe continuar para otros usuarios, especifica los usuarios que deben seguir teniendo acceso en la carga útil, como lo harías cuando configuras el acceso inicial para esos usuarios.

Para verificar que se quitó la vinculación, asegúrate de que el permiso apigee.deployments.invoke no exista para el usuario en la implementación:

curl 'https://apigee.googleapis.com/v1/organizations/{org}/environments/{env}/deployments/{api}:testIamPermissions' \
  --header 'Authorization: Bearer $USER_TOKEN' \
  --header 'Content-Type: application/json' \
  --header 'Accept: application/json' \
  --data '{"permissions":["apigee.deployments.invoke"]}'

Esto debería mostrar un resultado vacío si ningún usuario tiene el permiso.