Información general sobre la autenticación de APIs 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 proxies de API. Para usar esta función, incluye la política VerifyIAM en el flujo de solicitudes del proxy y configura el identificador de usuario (normalmente, la dirección de correo electrónico) del consumidor de la API para que tenga el Google Cloud rol o los permisos de gestión de identidades y accesos necesarios para invocar las APIs de Apigee. La solicitud de la API debe incluir un token de acceso Google Cloud válido para ese usuario.

Los administradores pueden conceder autorización a cualquier Google Cloud principal, no solo a usuarios concretos.

Usar el control de acceso basado en la gestión de identidades y accesos

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

Añadir gestión de accesos

Para configurar la gestión de accesos de un proxy de API, sigue estos pasos:

  1. Añade la política VerifyIAM al proxy o los proxies de la API de Apigee como parte del flujo de la solicitud.
  2. El administrador de Cloud del proyecto de Apigee:
    1. Concede el rol de gestión de identidades y accesos deploymentInvoker (o un rol personalizado con el permiso de gestión de identidades y accesos apigee.deployments.invoke) al Google Cloud principal del consumidor de la API a nivel de proyecto. De esta forma, el consumidor de la API podrá invocar todas las APIs alojadas en la organización de Apigee asociada.

      o

    2. Usa la acción SetIamPolicy para conceder el rol o el permiso al principal Google Cloud del consumidor de la API en una implementación concreta o de forma iterativa en varias implementaciones. Usa la operación de lista en el recurso de implementación para ver todas las implementaciones 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 para que genere un token de acceso, que enviará en la solicitud a la API de Apigee para comprobar los permisos. El token generado debe tener el permiso https://www.googleapis.com/auth/cloud-platform.

Operaciones de administrador

En esta sección se enumeran las acciones que realizan los administradores de APIs (productores de APIs) al gestionar los permisos basados en IAM.

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

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

Operación administrativa Acción Se necesita el permiso de gestión de identidades y accesos Recurso de gestión de identidades y accesos en el que se necesita el permiso*
GetDeployment Obtener información sobre un despliegue en un entorno de Apigee apigee.deployments.get Proyecto de Google Cloud o entorno de Apigee
ListDeployments Mostrar los despliegues de un entorno de Apigee apigee.deployments.list Proyecto o entorno de Apigee
SetIamPolicy Definir el acceso de invocación para los consumidores de la API en una implementación de API concreta apigee.deployments.setIamPolicy Proyecto de Google Cloud o entorno de Apigee
GetIamPolicy Obtiene el conjunto de ajustes de acceso de invocación de una implementación de API. apigee.deployments.getIamPolicy Proyecto de Google Cloud o entorno de Apigee
TestIamPermissions Comprueba si el usuario que llama a esta API tiene el permiso mencionado en la carga útil. No se necesita ningún permiso de gestión de identidades y accesos N/A
* El Google Cloud proyecto es el que se usa para aprovisionar Apigee. Los permisos a nivel de entorno de Apigee se definen en el entorno mediante setIAMPolicy.

Comprobación de acceso en tiempo de ejecución

Cuando el consumidor de la API intenta acceder a una API con control de acceso basado en gestión de identidades y accesos, se comprueba si tiene el token de acceso necesario y el rol o permiso adecuado a nivel de proyecto o de implementación. Si es así, podrán seguir accediendo al proxy. De lo contrario, se bloquearán.

Quitar acceso

Para quitar el acceso a nivel de proyecto: para quitar el acceso de un consumidor de APIs gestionado a nivel de proyecto, el administrador de Cloud del proyecto de Apigee revoca el rol de gestión de identidades y accesos deploymentInvoker (o el rol personalizado con el permiso de gestión de identidades y accesos apigee.deployments.invoke) de la Google Cloud entidad de seguridad Google Cloud del consumidor de APIs en el proyecto.

Si se ha concedido acceso a implementaciones concretas mediante setIamPolicy, elimina el rol o el permiso de las implementaciones mediante otra operación setIamPolicy.

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

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

  • Normalmente, la ejecución de la política con VerifyIAM tarda entre 10 y 50 milisegundos. Sin embargo, algunas llamadas pueden experimentar latencias más altas. Por ejemplo, en la región asia-east2, la latencia media puede aumentar hasta 50 ms y algunas llamadas pueden tardar unos 100 ms en completarse.

    Ten en cuenta que estas cifras de latencia no están garantizadas.

  • La inclusión de la política VerifyIAM en un proxy solo sirve para comprobar si se ha verificado o no. Los roles y permisos específicos del consumidor de la API no se tienen en cuenta en los procesos posteriores del flujo de solicitud o respuesta.
  • Como la comprobación de autorización solo se realiza en el momento de la ejecución de la política VerifyIAM, esta debe ser la primera política del flujo de solicitudes, después de las políticas de gestión del tráfico.
  • Si la validación de permisos se realiza correctamente o el productor de la API ha marcado la política VerifyIAM para continuar en caso de error, el flujo de la solicitud sigue ejecutando las demás políticas, si las hay, hasta llegar al servidor de destino. Si la comprobación de permisos falla y el productor de la API no ha marcado la política para que continúe en caso de error, el usuario recibe un error.
  • Si añades acceso de invocación (apigee.deployments.invoke) a nivel de entorno, no se concede acceso de invocación a todos los despliegues de APIs del entorno.
  • Las condiciones de gestión de identidades y accesos no se admiten en el recurso de implementación y no se pueden usar para controlar el acceso de invocación. Para obtener más información, consulte el artículo sobre cómo añadir condiciones de gestión de identidades y accesos de Apigee a las políticas.
  • El control de acceso basado en gestión de identidades y accesos admite un máximo de 1500 enlaces de roles en una sola política y otras limitaciones. Consulta las cuotas y los límites de IAM.
  • El control de acceso basado en IAM está sujeto a retrasos en la propagación de IAM.
  • Si intentas gestionar otras operaciones de apigee.deployments, como apigee.deployments.delete, mediante setIAMPolicy a nivel de implementación, no se producirá ningún error, pero tampoco será efectivo. Solo apigee.deployements.invoke es eficaz.
  • El acceso a una implementación se elimina cuando el proxy correspondiente se despliega del entorno o se elimina. El acceso debe volver a añadirse cuando se vuelva a desplegar.
  • La autenticación y la 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 de cómo conceder y revocar el acceso a las APIs basado en IAM. En todos estos ejemplos se da por hecho que VerifyIAM ya se ha añadido al proxy de API correspondiente.

En estos ejemplos, utiliza la consola de Cloud o gcloud (como se muestra) para gestionar roles o permisos en el principal del consumidor de la API Google Cloud .

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

Para añadir acceso, añade el rol deploymentInvoker:

APIGEE_ORG=GCP_PROJECT
USER=USER_EMAIL_HERE
gcloud projects add-iam-policy-binding "${APIGEE_ORG}" --member="${USER}" \
    --role='roles/apigee.deploymentInvoker'
  

Para revocar el acceso, quita el rol deploymentInvoker:

APIGEE_ORG=GCP_PROJECT
USER=USER_EMAIL_HERE
gcloud projects remove-iam-policy-binding "${APIGEE_ORG}" --member="${USER}" \
    --role='roles/apigee.deploymentInvoker'
 

Conceder y revocar el acceso de los usuarios a implementaciones específicas de un entorno

Para añadir el rol de invocador de un solo usuario a una implementación específica, sigue estos pasos:

APIGEE_ORG=GCP_PROJECT
ENV=APIGEE_ENVIRONMENT
API=APIPROXY_NAME
USER=USER_EMAIL_HERE
TOKEN=$(gcloud auth print-access-token)
curl "https://apigee.googleapis.com/v1/organizations/${APIGEE_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 tener un aspecto similar al siguiente:

{
    "version": 1,
    "etag": "BwYT8i40Vwo=",
    "bindings": [
      {
        "role": "roles/apigee.deploymentInvoker",
        "members": [
          "user:user-email@example.com"
        ]
      }
    ]
  }

Para añadir el rol de invocador a varios usuarios en una implementación específica, sigue estos pasos:

APIGEE_ORG=GCP_PROJECT
ENV=APIGEE_ENVIRONMENT
API=APIPROXY_NAME
USER1=EMAIL_FOR_USER1
USER2=EMAIL_FOR_USER2
USER3=EMAIL_FOR_USER3
TOKEN=$(gcloud auth print-access-token)
curl "https://apigee.googleapis.com/v1/organizations/${APIGEE_ORG}/environments/${ENV}/deployments/${API}:setIamPolicy" \
  --header "Authorization: Bearer $TOKEN" \
  --header 'Content-Type: application/json' \
  --data '{
  "policy": {
    "bindings": [
      {
        "members": [
        "user:'"$USER1"'",
        "user:'"$USER2"'",
        "user:'"$USER3"'"
        ],
        "role": "roles/apigee.deploymentInvoker"
      }
    ]
  }
}'
  

Para consultar el objeto de política que se ha definido anteriormente, haz lo siguiente:

curl "https://apigee.googleapis.com/v1/organizations/${APIGEE_ORG}/environments/${ENV}/deployments/${API}:getIamPolicy" \
  --header "Authorization: Bearer $TOKEN"
  

Deberías ver una respuesta de éxito como la que se muestra arriba.

El usuario puede verificar si tiene acceso a la implementación especificada (si el permiso apigee.deployments.invoke está definido para el usuario en una implementación especificada) sin invocar directamente la API implementada. Para ello, el usuario puede enviar esta solicitud con un token de acceso que genere:

APIGEE_ORG=GCP_PROJECT
ENV=APIGEE_ENVIRONMENT
API=APIPROXY_NAME
USER=USER_EMAIL_HERE
TOKEN=$(gcloud auth print-access-token)
curl "https://apigee.googleapis.com/v1/organizations/${APIGEE_ORG}/environments/${ENV}/deployments/${API}:testIamPermissions" \
    --header "Authorization: Bearer $TOKEN" \
    --header 'Content-Type: application/json' \
    --data '{"permissions":["apigee.deployments.invoke"]}'

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

Para revocar el acceso a una implementación específica de un usuario, quítale el rol deploymentInvoker. Para ello, primero obtén el objeto de política que está asociado actualmente a la implementación:

curl "https://apigee.googleapis.com/v1/organizations/${APIGEE_ORG}/environments/${ENV}/deployments/${API}:getIamPolicy" \
  --header "Authorization: Bearer $TOKEN"
  

La respuesta correcta debería tener un aspecto similar al siguiente.

{
  "version": 1,
  "etag": "BwYT8i40Vwo=",
  "bindings": [
      {
        "role": "roles/apigee.deploymentInvoker",
        "members": [
          "user:user1-email@example.com",
          "user:user2-email@example.com",
          "user:user3-email@example.com"
        ]
      }
    ]
  }

Para quitar la vinculación de un solo usuario, usa setIamPolicy y especifica en la carga útil los usuarios que deben seguir teniendo acceso, como harías al configurar el acceso inicial para esos usuarios. Siguiendo con el ejemplo anterior, si quieres quitar el acceso a USER1, pero mantener el acceso a USER2 y USER3, debes usar este comando:

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

Para quitar la vinculación de todos los usuarios de una implementación específica, especifica una carga útil vacía:

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

Para verificar que se ha eliminado la vinculación, comprueba que el usuario no tenga el permiso apigee.deployments.invoke en la implementación:

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

Debería devolver una respuesta adecuada; por ejemplo, una salida vacía si ningún usuario tiene permiso para invocar la API.