Create the API proxy
/ 20
Add policies to verify tokens
/ 10
Add policies to generate tokens
/ 10
Deploy the API proxy
/ 10
Add the API product and create an app
/ 20
Add the SpikeArrest policy
/ 10
Add error handling
/ 20
Apigee es una plataforma para desarrollar y administrar las APIs. Apigee puede ayudarte a proteger el acceso a tus APIs y a limitar la frecuencia de acceso a ellas. Apigee también proporciona funciones que se usan para proteger el acceso interno a los datos de la API.
En este lab, crearás una API que requiere tokens de OAuth para el acceso. Aplicarás la política de SpikeArrest para limitar la tasa de llamadas a la API por aplicación y usarás variables privadas y enmascaramiento de datos para ocultar datos sensibles de los usuarios que depuran el tráfico de la API.
En este lab, aprenderás a realizar las siguientes tareas:
Lee estas instrucciones. Los labs cuentan con un temporizador que no se puede pausar. El temporizador, que comienza a funcionar cuando haces clic en Comenzar lab, indica por cuánto tiempo tendrás a tu disposición los recursos de Google Cloud.
Este lab práctico te permitirá realizar las actividades correspondientes en un entorno de nube real, no en uno de simulación o demostración. Para ello, se te proporcionan credenciales temporales nuevas que utilizarás para acceder a Google Cloud durante todo el lab.
Para completar este lab, necesitarás lo siguiente:
Haz clic en el botón Comenzar lab. Si debes pagar por el lab, se abrirá un diálogo para que selecciones la forma de pago. A la izquierda, se encuentra el panel Detalles del lab, que tiene estos elementos:
Haz clic en Abrir la consola de Google Cloud (o haz clic con el botón derecho y selecciona Abrir el vínculo en una ventana de incógnito si ejecutas el navegador Chrome).
El lab inicia recursos y abre otra pestaña en la que se muestra la página de acceso.
Sugerencia: Ordena las pestañas en ventanas separadas, una junto a la otra.
De ser necesario, copia el nombre de usuario a continuación y pégalo en el diálogo Acceder.
También puedes encontrar el nombre de usuario en el panel Detalles del lab.
Haz clic en Siguiente.
Copia la contraseña que aparece a continuación y pégala en el diálogo Te damos la bienvenida.
También puedes encontrar la contraseña en el panel Detalles del lab.
Haz clic en Siguiente.
Haz clic para avanzar por las páginas siguientes:
Después de un momento, se abrirá la consola de Google Cloud en esta pestaña.
Cloud Shell es una máquina virtual que cuenta con herramientas para desarrolladores. Ofrece un directorio principal persistente de 5 GB y se ejecuta en Google Cloud. Cloud Shell proporciona acceso de línea de comandos a tus recursos de Google Cloud.
Haz clic en Activar Cloud Shell 
Haz clic para avanzar por las siguientes ventanas:
Cuando te conectes, habrás completado la autenticación, y el proyecto estará configurado con tu Project_ID,
gcloud es la herramienta de línea de comandos de Google Cloud. Viene preinstalada en Cloud Shell y es compatible con la función de autocompletado con tabulador.
Resultado:
Resultado:
gcloud, en Google Cloud, consulta la guía con la descripción general de gcloud CLI.
Para abrir la consola de Apigee, haz lo siguiente:
Apigee y, luego, haz clic en Administración de APIs de Apigee en los resultados de la búsqueda.Se abrirá la consola de Apigee y, en la página de destino, se mostrarán vínculos rápidos a ubicaciones de uso frecuente.
), junto a Apigee, haz clic en Favorito (
).Apigee ahora se agregó como favorito al menú de navegación.
En esta tarea, crearás un proxy de API de Apigee que actuará como una fachada para un servicio de backend. El proxy de API usará una cuenta de servicio para permitirle presentar tokens de identidad de OpenID Connect al servicio de Cloud Run.
Ya se creó un servicio de backend llamado simplebank-rest y se implementó en Cloud Run. También se creó una cuenta de servicio para ti.
En Cloud Shell, para recuperar la URL del servicio de backend, usa el siguiente comando:
Guarda esta URL, ya que se usará cuando crees el proxy de API.
Navega a la IU de Apigee en la consola de Cloud.
En el menú de navegación de la izquierda, selecciona Desarrollo de proxies > Proxies de API.
Para crear un proxy nuevo con el asistente de proxy, haz clic en +Crear.
Crearás un proxy inverso para tu servicio de backend. Este proxy de API usará una especificación de OpenAPI para crear el esqueleto de la API.
En el cuadro Plantilla de proxy, en Plantilla de especificación de OpenAPI, selecciona Proxy inverso (más común).
Para obtener el archivo de OpenAPI, abre la URL en un navegador y se descargará el archivo YAML de especificación de OpenAPI en tu computadora:
Haz clic en Explorar, selecciona el archivo OpenAPI de la computadora y haz clic en Siguiente.
Especifica lo siguiente para los detalles del proxy:
| Propiedad | Valor |
|---|---|
| Nombre del proxy | bank-v1 |
| Ruta de acceso base | /bank/v1 |
| Descripción | API de solo lectura de SimpleBank |
| (API existente) de destino | URL del backend |
El destino debe ser la URL del backend que recuperaste anteriormente en la tarea. El destino debería ser similar a lo siguiente:
Haz clic en Siguiente.
Deja el resto de los parámetros con la configuración predeterminada y haz clic en Crear.
Haz clic en la pestaña Desarrollar.
El servicio de backend se implementa para requerir acceso autenticado, por lo que no puedes llamar al servicio sin un token de identidad de OpenID Connect válido.
HTTPTargetConnection especifica el destino de backend para el servicio.
En el menú Navegador del proxy, en la sección Extremos de destino, haz clic en PreFlow.
Busca el siguiente código (tu URL será diferente):
Debajo de la URL, agrega una sección Autenticación que se vea de la siguiente manera:
Reemplaza AUDIENCE por el valor de URL que ya se encuentra en la sección HTTPTargetConnection. Ahora, tu código debería ser similar al siguiente, excepto que tendrá tu URL específica en los elementos URL y Audience:
Haz clic en Guardar.
Haz clic en Revisar mi progreso para verificar el objetivo.
En esta tarea, agregarás una política de OAuthV2 al proxy de API. Una política de OAuthV2 que usa la operación VerifyJWTAccessToken aplica de manera forzosa la verificación de los tokens de acceso en el entorno de ejecución, lo que permite que solo las aplicaciones con un token de acceso de OAuth válido accedan a la API.
La política de OAuthV2 puede crear y verificar tanto tokens opacos como tokens web JSON (JWT). Este proxy de API usará JWT para los tokens de acceso.
Se usará un conjunto de propiedades para almacenar el secreto de firma que se utiliza en la creación y verificación del JWT.
El JWT se firmará con un código de autenticación de mensajes basado en hash (HMAC). Este tipo de firma criptográfica requiere un secreto.
En el menú Navegador del proxy, junto a Recursos, haz clic en +.
En el menú desplegable Tipo de recurso, selecciona Property Set.
Especifica oauth.properties para el Nombre del recurso y, luego, haz clic en Agregar.
En el panel de código oauth.properties, agrega la siguiente propiedad:
Se puede acceder a este valor en el código con la variable de flujo propertyset.oauth.secret.
El secreto de firma se debe proporcionar a la política de OAuth en una variable privada, pero la variable propertyset.oauth.secret no es privada. Esta política AssignMessage creará una variable privada a partir de la variable del conjunto de propiedades.
En el menú Navegador del proxy, en la sección Extremos de proxy, en predeterminado, haz clic en PreFlow.
El PreFlow de solicitud en el extremo de proxy predeterminado es el primer flujo que se ejecuta cuando una solicitud ingresa al proxy de API.
La política OAuthV2 requiere el secreto y se ejecutará muy temprano en el proxy de API.
En el panel Flujo, haz clic en el botón + junto a PreFlow en el flujo de solicitud.
Selecciona Crear una política nueva y, en el menú desplegable Seleccionar política, elige Asignar mensaje en la sección Mediación. Luego, establece AM-GetSecret como Nombre visible y Nombre.
Haz clic en Agregar. Haz clic en AM-GetSecret en Políticas en el menú Navegador.
La configuración de la política AssignMessage se muestra en el panel Código.
Cambia la configuración de la política a lo siguiente:
El parámetro de configuración AssignVariable copia la variable propertyset.oauth.secret en la variable private.secretkey.
El parámetro de configuración IgnoreUnresolvedVariables hace que la política AssignMessage genere una falla si no se puede resolver propertyset.oauth.secret.
En el menú Navegador del proxy, en la sección Extremos de proxy, en predeterminado, haz clic en PreFlow.
La política de OAuthV2 debe ejecutarse después de la política AssignMessage.
En el panel Flujo, haz clic en el botón + junto a PreFlow en el flujo de solicitud.
Selecciona Crear una política nueva y, en el menú desplegable Seleccionar política, selecciona OAuth v2.0 en la sección Seguridad. Luego, establece OA-VerifyToken como Nombre visible y Nombre.
Haz clic en Agregar y, luego, en OA-VerifyToken en Políticas en el menú Navegador.
La configuración de la política de OAuthV2 se muestra en el panel Código.
Cambia la configuración de la política de OAuthV2 a lo siguiente:
La configuración especifica que el token de acceso JWT usará el algoritmo HS256 (HMAC-SHA256) con la variable privada creada en la política AssignMessage como clave secreta.
Haz clic en Guardar.
Haz clic en Revisar mi progreso para verificar el objetivo.
También se agregará un extremo de proxy independiente al proxy de API para permitir la creación de los tokens JWT.
En un entorno de producción, se suele crear un proxy independiente para generar tokens. En este lab, crearás el flujo de generación de tokens en un extremo de proxy independiente dentro del mismo proxy de API.
En el menú Navegador del proxy, en la fila Extremos de proxy, haz clic en el botón +.
Esto creará un extremo de proxy nuevo que se usará cuando se cree un JWT nuevo.
En Nombre, especifica token y, luego, haz clic en Agregar.
El nuevo extremo del proxy llamado token se mostrará en el panel Código.
Cambia toda la configuración del flujo de token para que pase de:
a:
Haz clic en Guardar.
Con esta configuración actualizada, se generan 2 cambios específicos:
/token. Esta es la ruta de acceso base que se usará cuando se cree un token.En el flujo del proxy, en la sección Extremos de proxy: token, justo al lado de /token, haz clic en +.
Para el nuevo flujo condicional, especifica los siguientes valores:
| Propiedad | Valor |
|---|---|
| Nombre del flujo | generateToken |
| Tipo de condición | selecciona Personalizada |
En Condición, especifica este valor:
Solo se permitirán las solicitudes de tokens de credenciales de cliente válidas.
Haz clic en Agregar.
La política de OAuthV2 que generará tokens también necesitará acceso a la variable private.secretkey.
En el menú Navegador del proxy, en la sección Extremos de proxy, en token, haz clic en generateToken.
En el panel Flujo, haz clic en el botón + a la derecha, junto a generateToken en el flujo de solicitud.
En Seleccionar política, elige la opción Seleccionar política existente y, luego, haz clic en AM-GetSecret.
Haz clic en Agregar.
La misma política AssignMessage se adjunta al PreFlow del extremo del proxy de token.
En el menú Navegador del proxy, en la sección Extremos de proxy, en token, haz clic en generateToken.
En el panel Flujo, haz clic en el botón + a la derecha, junto a generateToken en el flujo de solicitud.
En Seleccionar política, selecciona Crear una política nueva y OAuth v2.0 en la sección Seguridad. Luego, establece OA-GenerateToken como Nombre visible y Nombre.
Haz clic en Agregar y, luego, en OA-GenerateToken en Políticas.
La configuración de la política de OAuthV2 se muestra en el panel Código.
Cambia la configuración de la política de OAuthV2 a lo siguiente:
Esta configuración permitirá la creación de un token de OAuth de JWT que vence dentro de 30 minutos.
En el flujo del proxy, en la sección Extremos de proxy: token, justo al lado de /token, haz clic en +.
Para el nuevo flujo condicional, especifica los siguientes valores:
| Propiedad | Valor |
|---|---|
| Nombre del flujo | invalidRequest |
| Tipo de condición | selecciona Personalizada |
| Condición | DELETETHIS |
La condición se borrará una vez que se agregue el flujo, ya que cualquier solicitud de generateToken no válida debe pasar por este flujo.
Haz clic en Agregar.
En el flujo invalidRequest, quita la siguiente línea:
En el menú Navegador del proxy, en la sección Extremos de proxy, en token, haz clic en invalidRequest.
En el panel Flujo, haz clic en el botón + junto a invalidRequest para el flujo de solicitud.
Selecciona Crear una política nueva y, luego, Generar una falla en la sección Mediación. Luego, establece RF-InvalidTokenRequest como Nombre visible y Nombre.
Haz clic en Agregar y, luego, en RF-InvalidTokenRequest en Políticas.
La configuración de la política RaiseFault se muestra en el panel Código.
Cambia la configuración de la política RaiseFault a la siguiente:
Si la solicitud no es válida, se creará una respuesta Error 400: Solicitud incorrecta.
Haz clic en Guardar.
Haz clic en Revisar mi progreso para verificar el objetivo.
En esta tarea, implementarás el proxy de API y confirmarás que para el acceso se requiere un token de OAuth.
En Cloud Shell, pega y ejecuta el siguiente conjunto de comandos:
Esta serie de comandos usa la API de Apigee para determinar cuándo se creó la instancia del entorno de ejecución y se conectó el entorno de evaluación.
Espera hasta que la instancia esté lista.
Cuando se muestra el texto ***ORG IS READY TO USE***, la instancia está lista. Es posible que la organización de Apigee (org) se haya creado antes de que comenzaras el lab, por lo que tal vez no tengas que esperar a que se cree la instancia.
Si estás esperando que la organización esté lista, puedes obtener información sobre OAuth, la política de SpikeArrest, el enmascaramiento y el ocultamiento de datos, y los tokens opacos y los JWT.
Navega a Apigee en la consola de Cloud.
En el menú de navegación de la izquierda, selecciona Desarrollo de proxy > Proxies de API y, luego, haz clic en bank-v1.
Haz clic en la pestaña Desarrollar.
Haz clic en Implementar y, en Entorno, selecciona evaluación.
En un cuadro de diálogo se te pedirá que confirmes la implementación.
En Cuenta de servicio, especifica la dirección de correo electrónico de la cuenta de servicio:
Haz clic en Implementar y, luego, en Confirmar.
Haz clic en la pestaña Descripción general y espera a que el estado de implementación de evaluación muestre que se implementó el proxy.
Haz clic en Revisar mi progreso para verificar el objetivo.
Se puede llamar al entorno de evaluación en la organización de Apigee con el nombre de host eval.example.com. La entrada de DNS para este nombre de host se creó dentro de tu proyecto y se resuelve en la dirección IP de la instancia de entorno de ejecución de Apigee. Esta entrada de DNS se creó en una zona privada, lo que significa que solo puede verse en la red interna.
Cloud Shell no reside en la red interna, por lo que los comandos de Cloud Shell no pueden resolver esta entrada de DNS. Una máquina virtual (VM) dentro de tu organización puede acceder al DNS de la zona privada. Se creó automáticamente una máquina virtual llamada apigeex-test-vm. Puedes usar esta máquina para llamar al proxy de API.
En Cloud Shell, abre una conexión SSH a tu VM de prueba:
Si se te solicita autorización, haz clic en Autorizar.
Para cada pregunta que se haga en Cloud Shell, haz clic en Intro o Retorno para especificar la entrada predeterminada.
La identidad con la que accediste es la propietaria del proyecto, por lo que se permite la conexión SSH a esta máquina.
Tu sesión de Cloud Shell ahora se ejecuta dentro de la VM.
Llama al proxy de API bank-v1 implementado en el entorno de evaluación:
La opción -k le indica a curl que omita la verificación del certificado TLS. En este lab, el entorno de ejecución de Apigee usa un certificado autofirmado en lugar de un certificado creado por una autoridad certificadora (AC) de confianza.
-k para omitir la verificación de certificados en casos de uso de producción.
Esta API intenta recuperar una lista de clientes. Ahora deberías ver una respuesta 401 (solicitud no autorizada) similar a esta:
Esta respuesta indica que el proxy de API bloqueó el acceso al servicio de backend porque no se proporcionó el token de acceso.
Ingresa el comando exit para salir de la sesión de SSH y regresar a Cloud Shell.
En esta tarea, agregarás un producto de API que proporcionará acceso a tu API. También crearás un desarrollador y, luego, una aplicación que estará asociada con tu producto de API.
Navega a Apigee en la consola de Cloud.
En el menú de navegación de la izquierda, selecciona Distribución > Productos de API.
Para crear un nuevo producto de API, haz clic en +Crear.
En el panel Detalles del producto, especifica lo siguiente:
| Propiedad | Valor |
|---|---|
| Nombre | bank-readonly |
| Nombre visible | banco (acceso de lectura) |
| Entorno | selecciona evaluación |
| Acceso | selecciona Público |
Deja seleccionada la opción Aprobar automáticamente las solicitudes de acceso.
En la sección Operaciones, haz clic en +Agregar una operación.
Las operaciones se usan con el objetivo de especificar qué solicitudes en qué proxies de API se permiten para una aplicación asociada con el producto de API.
Especifica lo siguiente:
| Propiedad | Valor |
|---|---|
| Proxy de API | selecciona el proxy de API bank-v1 |
| Ruta de acceso | /** |
| Métodos | selecciona GET |
La expresión de ruta de acceso /\*\* indica que se permitirá cualquier solicitud que coincida con la ruta de acceso base.
En un entorno de producción, es posible que elijas agregar cada operación permitida por separado, en lugar de usar esta expresión de ruta de acceso comodín.
Haz clic en Guardar para guardar la operación.
Para guardar el producto de API, haz clic en Guardar en la parte superior de la página Detalles del producto.
Vuelve a la página Distribución > Productos de API.
Se mostrará el producto de API en la lista.
Antes de crear una app, debes crear un desarrollador de apps.
En el menú de navegación de la izquierda, haz clic en Distribución > Desarrolladores.
Para crear un nuevo desarrollador de apps, haz clic en +Crear.
Especifica lo siguiente:
| Propiedad | Valor |
|---|---|
| Nombre | Joe |
| Apellido | Desarrollador |
| Nombre de usuario | joe |
| Correo electrónico | joe@example.com |
Haz clic en Agregar para crear el desarrollador de apps.
En el menú de navegación de la izquierda, haz clic en Distribución > Apps.
Para crear una app nueva, haz clic en +Crear.
En el panel Detalles de la app, especifica lo siguiente:
| Propiedad | Valor |
|---|---|
| Nombre | readonly-app |
| Desarrollador | selecciona joe@example.com |
En el panel Credenciales, haz clic en Agregar credenciales > Agregar productos, selecciona banco (acceso de lectura) en el menú desplegable y, luego, haz clic en Agregar para agregarla.
Haz clic en Crear en la esquina superior derecha para crear la app.
Ahora, la clave y el secreto están configurados para la app.
Haz clic en los íconos de Mostrar junto a Clave y Secreto.
Para esta API, se requiere un token de acceso de OAuth. La clave y el secreto se usarán como credenciales para la app, que le permite crear un token de acceso de OAuth.
Haz clic en Revisar mi progreso para verificar el objetivo.
En Cloud Shell, abre una conexión SSH a tu VM de prueba:
Si se te solicita autorización, haz clic en Autorizar.
Tu sesión de Cloud Shell ahora se ejecuta dentro de la VM.
Para obtener el secreto y la clave de consumidor de la aplicación, ejecuta los siguientes comandos:
El primer comando lee la configuración de gcloud para obtener el proyecto actual. El segundo y el tercer comando recuperan el secreto y la clave de consumidor con la API de Apigee. La solicitud se autoriza porque envías un token de acceso que tiene los permisos del usuario que ingresó a la cuenta.
Para el tipo de otorgamiento de credenciales de cliente de OAuth, la aplicación cliente debe enviar el secreto y la clave de consumidor en un encabezado de autorización con el objetivo de generar un token de acceso.
Para generar un token de acceso JWT, ejecuta el siguiente comando:
El primer comando llama al extremo del token y guarda la respuesta. Luego, el token se extrae de la respuesta JSON y se almacena en JWT_TOKEN.
Para probar una solicitud con el token JWT, usa el siguiente comando:
La llamada a la API ahora debería devolver una lista de clientes.
Ingresa el comando exit para salir de la sesión de SSH y regresar a Cloud Shell.
En esta tarea, agregarás una política de SpikeArrest que usará la configuración de cuota del producto de API para limitar la frecuencia de las llamadas a la API.
La política de SpikeArrest protege tus APIs y backends contra los aumentos repentinos de tráfico, ya que te permite especificar una tasa máxima de tráfico permitida. Esta política se puede usar para garantizar que tu backend no se vea sobrecargado por el tráfico que no puede controlar.
Esta política de SpikeArrest especificará un límite de frecuencia general para el tráfico de llamadas a la API de /token.
Navega a Apigee en la consola de Cloud.
En el menú de navegación de la izquierda, selecciona Desarrollo de proxy > Proxies de API y, luego, haz clic en bank-v1.
Haz clic en la pestaña Desarrollar.
En el menú Navegador del proxy, en la sección Extremos de proxy, en token, haz clic en PreFlow.
La política de SpikeArrest debe ejecutarse antes de las políticas de flujo condicional.
En el panel Flujo, haz clic en el botón + junto a PreFlow del flujo de solicitud.
Selecciona Crear una política nueva y SpikeArrest en la sección Administración del tráfico. Luego, establece SA-LimitTokenRate como Nombre visible y Nombre.
Haz clic en Agregar y, luego, en SA-LimitTokenRate en la sección Políticas.
La configuración de la política de SpikeArrest se muestra en el panel Código.
Cambia la configuración de la política de SpikeArrest a lo siguiente:
La configuración especifica que la tasa máxima de solicitudes permitida es de 5 por minuto. Todo el tráfico estará limitado por esta política de SpikeArrest.
Si UseEffectiveCount se establece como falso, se especifica que la política de SpikeArrest usa el algoritmo de bucket de tokens. El tráfico se reduce dividiendo la tasa en intervalos más pequeños. 5 solicitudes por minuto significa 1 solicitud por cada quinto de minuto o 1 solicitud cada 12 segundos. Cuando llega una segunda solicitud a un Message Processor en menos de 12 segundos después de la anterior, es posible que se rechace.
Esta política de SpikeArrest especificará un límite de frecuencia para el tráfico de llamadas a la API de /bank/v1. La tasa se establecerá por aplicación.
En el menú Navegador del proxy, en la sección Extremos de proxy, en predeterminado, haz clic en PreFlow.
La política de SpikeArrest debe ejecutarse al principio de la llamada, pero debe hacerlo después de la política de OAuthV2 VerifyJWTAccessToken para limitar la tasa por aplicación.
En el panel Flujo, haz clic en el botón + junto a PreFlow del flujo de solicitud.
Selecciona Crear una política nueva y SpikeArrest en la sección Administración del tráfico. Luego, establece SA-LimitRateByApp como Nombre visible y Nombre.
Haz clic en Agregar y, luego, en SA-LimitRateByApp en la sección Políticas.
La configuración de la política de SpikeArrest se muestra en el panel Código.
Cambia la configuración de la política de SpikeArrest a lo siguiente:
Al igual que la política anterior, la configuración especifica que la tasa máxima de solicitudes permitida es de 5 por minuto. Sin embargo, esta política especifica un Identificador, que mantiene la tasa de SpikeArrest por separado para cada client_id. El ID de cliente se completa con la política de OA-VerifyToken y es único para cada aplicación del desarrollador.
Si UseEffectiveCount se establece como verdadero, se especifica que el recuento de la tasa se mantiene para todo el tráfico dentro de la región. La política mantiene un contador de las solicitudes recibidas por período, que dura un minuto cuando se usa una tasa de solicitudes por minuto. El cálculo de la tasa se basa en una ventana deslizante.
Para este ejemplo que se muestra arriba, supongamos que usamos una frecuencia de 50 solicitudes por minuto. Los contadores usan un período de un minuto, aunque el período del contador sería de un segundo si la tasa se hubiera especificado por segundo. Supongamos que pasaron 10 segundos del minuto actual, representado por la flecha. En el minuto anterior, hubo 48 solicitudes, y en el período actual, hubo 5 solicitudes hasta el momento.
Para permitir otra solicitud, la frecuencia debería ser inferior a 50 solicitudes por minuto. La tasa calculada es la siguiente:
request_rate = (48 * (60-10)/60) + 6 = 46
Dado que solo transcurrieron 10 segundos de los 60 del período actual, los otros 50 segundos se calculan con la tasa del período anterior. 5/6 de 48 es 40. Si se permitiera una solicitud, el recuento para el período actual sería de 5 + 1, es decir, 6. El cálculo de la frecuencia de solicitudes de 46 indica que la solicitud está permitida, ya que la frecuencia de solicitudes es inferior a 50 solicitudes por minuto.
Haz clic en Guardar > Guardar como revisión nueva.
Haz clic en Implementar y, luego, selecciona evaluación en Entorno.
En Cuenta de servicio, especifica la dirección de correo electrónico de la cuenta de servicio:
Haz clic en Revisar mi progreso para verificar el objetivo.
En Cloud Shell, abre una conexión SSH a tu VM de prueba:
Si se te solicita autorización, haz clic en Autorizar.
Tu sesión de Cloud Shell ahora se ejecuta dentro de la VM.
Para obtener el secreto y la clave de consumidor de la aplicación, ejecuta los siguientes comandos:
Ejecuta el siguiente comando varias veces para generar varios tokens de acceso:
Deberías recibir rápidamente una respuesta 429 Demasiadas solicitudes, que indica que se superó la tasa. Dado que UseEffectiveCount es falso para esta política, el tráfico se reduce con el algoritmo de bucket de tokens. Es probable que recibas el incumplimiento de la protección contra aumentos repentinos de tráfico antes de la 5ª solicitud.
Para guardar un token de acceso JWT, ejecuta el siguiente comando:
Para probar la política de SpikeArrest en las llamadas a la API, envía el siguiente comando de forma repetida:
UseEffectiveCount es verdadero, por lo que esta política usa el algoritmo de ventana deslizante. Deberías poder realizar 5 solicitudes correctamente antes de que se bloquee una.
Ingresa el comando exit para salir de la sesión de SSH y regresar a Cloud Shell.
En esta tarea, crearás una máscara de datos para ocultar campos específicos en una sesión de depuración.
La depuración es una herramienta para solucionar problemas y supervisar proxies de API que se ejecutan en Apigee. La herramienta de depuración te permite examinar los detalles de cada paso durante una llamada a la API.
En el menú de navegación de la izquierda, selecciona Desarrollo de proxy > Proxies de API y, luego, haz clic en bank-v1.
Haz clic en la pestaña Depurar.
En el panel Iniciar sesión de depuración, haz clic en Iniciar sesión de depuración y, en el menú desplegable del entorno, selecciona el entorno evaluación.
Haz clic en Iniciar.
Es posible que la sesión de depuración demore unos instantes en comenzar a capturar solicitudes.
Realizarás solicitudes a la API y, luego, examinarás la sesión de depuración.
En Cloud Shell, abre una conexión SSH a tu VM de prueba:
Si se te solicita autorización, haz clic en Autorizar.
Tu sesión de Cloud Shell ahora se ejecuta dentro de la VM.
Para obtener el token de la aplicación, ejecuta los siguientes comandos:
Realiza esta solicitud a la API:
Regresa a la página de IU de Apigee.
La página Depurar debería mostrar 2 solicitudes: una POST (para generar el token) y una GET (para recuperar las cuentas de un usuario).
Haz clic en la solicitud GET.
Se muestran los detalles de la solicitud GET.
Haz clic en la primera política, que es la política AM-GetSecret que copia la variable propertyset.oauth.secret en la variable private.secretkey.
En los Detalles de la fase no se muestra la variable privada, ya que las variables que tienen el prefijo "private." se ocultan en la sesión de depuración. Sin embargo, la variable de conjunto de propiedades contiene los mismos datos sensibles, por lo que podría ser conveniente ocultarla a los usuarios que depuran el tráfico.
Haz clic en la respuesta del backend, que se indica con el círculo a la izquierda del ícono de fábrica.
La respuesta contiene las cuentas del usuario, incluidos los saldos de cuenta.
Abre una pestaña nueva en la misma ventana del navegador y desplázate a la referencia de la API de Apigee.
La referencia de la API de Apigee proporciona detalles sobre las diversas llamadas a la API que se pueden usar para administrar Apigee y también para realizar llamadas a la API de Apigee. En esta página, se muestran las llamadas a la API de organization.environments.
Desplácese hasta el final de la página y haga clic en updateDebugmask.
Esta llamada a la API actualizará la máscara de depuración del entorno.
En el panel Probar esta API, para el parámetro de solicitud name, usa lo siguiente:
Para el cuerpo de la solicitud, ingresa lo siguiente:
Esta carga útil hará que se enmascare la variable propertyset.oauth.secret y también cada campo saldo del array de objetos en la carga útil de la respuesta.
Haz clic en Ejecutar.
Si aparece un cuadro emergente que te pide que elijas tu cuenta, selecciona la cuenta de estudiante.
Haz clic en Permitir para permitir que la página use las credenciales de estudiante.
En la IU de Apigee, en el menú de navegación de la izquierda, selecciona Desarrollo de proxy > Proxies de API y, luego, haz clic en bank-v1.
Haz clic en la pestaña Depurar.
En el panel Iniciar sesión de depuración, en el menú desplegable del entorno, selecciona evaluación.
Haz clic en Iniciar.
En Cloud Shell, si se cerró la conexión SSH, abre una conexión SSH a tu VM de prueba:
Obtén un token y vuelve a realizar la solicitud a la API:
Regresa a la página Depurar en la IU de Apigee y haz clic en la solicitud GET.
Haz clic en la política AM-GetSecret.
La variable propertyset.oauth.secret está enmascarada.
Haz clic en Se inició el flujo de respuesta del proxy para ver la respuesta del backend.
Cada campo de saldo está enmascarado.
En esta tarea, crearás un flujo condicional predeterminado para restringir las llamadas a recursos de backend específicos y volverás a escribir un mensaje de error de backend.
En Cloud Shell, si se cerró la conexión SSH, abre una conexión SSH a tu VM de prueba:
Ingresa Y para continuar y presiona INTRO dos veces de modo de dejar la frase de contraseña vacía.
Obtén un token y realiza una solicitud GET a /users:
El servicio de backend no reconoce la solicitud GET /users, por lo que devuelve una respuesta 404 similar a la siguiente:
La respuesta devuelve una carga útil HTML, que no coincide con el formato de la carga útil de RF-InvalidTokenRequest. Además, una respuesta del backend puede contener datos sensibles. Por estos motivos, una práctica que se recomienda es volver a escribir las respuestas de error de los servicios de backend.
Las reglas de falla se pueden usar para detectar errores y volver a escribir mensajes de error.
Se usará una política RaiseFault para establecer la nueva respuesta.
Navega a Apigee en la consola de Cloud.
En el menú de navegación de la izquierda, selecciona Desarrollo de proxy > Proxies de API y, luego, haz clic en bank-v1.
Haz clic en la pestaña Desarrollar.
En el menú Navegador del proxy, junto a Políticas, haz clic en +.
Selecciona Generar una falla en la sección Mediación y, luego, establece RF-404NotFound como Nombre visible y Nombre.
Haz clic en Crear. Haz clic en RF-404NotFound en la sección Políticas.
Cambia la configuración de la política RaiseFault a la siguiente:
En la sección Quitar, primero se quitan todos los encabezados que podrían haber provenido del servicio de backend y, luego, en la sección Establecer, se crea la respuesta. Se agregó el encabezado FaultName para mostrar el valor de la variable fault.name cuando se genera la falla. La variable fault.name especifica el nombre de la falla.
En el menú Navegador del proxy, en la sección Extremos de destino, haz clic en predeterminado.
El extremo de destino predeterminado contiene la llamada de destino del backend que devuelve la respuesta 404. Un error 404 se considera un código de falla. El extremo generará una falla y se podrán usar las FaultRules especificadas en el extremo de destino para volver a escribir la respuesta de la API.
En la configuración de TargetEndpoint, directamente debajo de la etiqueta TargetEndpoint, agrega la siguiente sección FaultRules:
El comienzo de TargetEndpoint ahora se verá similar a lo siguiente:
Haz clic en Guardar > Guardar como revisión nueva.
Haz clic en Implementar y selecciona evaluación en Entorno.
En Cuenta de servicio, especifica la dirección de correo electrónico de la cuenta de servicio:
Haz clic en Implementar y, luego, en Confirmar.
Haz clic en la pestaña Descripción general y espera a que el estado de implementación de evaluación muestre que se implementó el proxy.
En Cloud Shell, si se cerró la conexión SSH, abre una conexión SSH a tu VM de prueba:
Obtén un token y realiza una solicitud GET a /users:
La respuesta se reescribió y ahora se ve similar a lo siguiente:
La respuesta ahora usa JSON. Ten en cuenta que el encabezado faultname tiene el valor ErrorResponseCode, que es el valor de la variable fault.name especificada cuando el destino devuelve un código de error. En cuanto el servicio de backend devolvió la respuesta 404, se generó una falla y se evaluaron las reglas de falla del extremo de destino. Luego, la regla de error 404 reescribió la respuesta.
En lugar de contar con que el backend devuelva una respuesta cuando se envía una solicitud inesperada, se puede agregar un nuevo flujo condicional al final de los flujos condicionales del extremo de proxy para generar una falla cuando ninguno de los otros flujos condicionales coincida con sus condiciones. Esto garantiza que solo las operaciones que se enumeran en los flujos condicionales pasarán al backend. Este patrón te deja permitir el acceso solo a un subconjunto de los recursos del servicio de backend.
En el menú Navegador del proxy, navega a Extremo de proxy: predeterminado y, luego, en la sección de flujo, haz clic en + junto a /bank/v1.
Para el nuevo flujo condicional, especifica los siguientes valores:
| Propiedad | Valor |
|---|---|
| Nombre del flujo | 404NotFound |
| Tipo de condición | selecciona Personalizada |
| Condición | DELETETHIS |
Haz clic en Agregar.
En el flujo 404NotFound, quita la siguiente línea:
Si no coinciden todas las condiciones de los flujos condicionales anteriores, se ejecutará el flujo 404NotFound.
En el menú Navegador del proxy, en la sección Extremos de proxy, en predeterminado, haz clic en 404NotFound.
En el panel Flujo, haz clic en el botón + junto al flujo de solicitud 404NotFound.
En Seleccionar política, elige la opción Seleccionar política existente y, luego, haz clic en RF-404NotFound.
Haz clic en Agregar.
Haz clic en Guardar > Guardar como revisión nueva.
Haz clic en Implementar y, luego, selecciona evaluación en Entorno.
En Cuenta de servicio, especifica la dirección de correo electrónico de la cuenta de servicio:
Haz clic en Implementar y, luego, en Confirmar.
Haz clic en la pestaña Descripción general y espera a que el estado de implementación de evaluación muestre que se implementó el proxy.
Haz clic en Revisar mi progreso para verificar el objetivo.
En Cloud Shell, si se cerró la conexión SSH, abre una conexión SSH a tu VM de prueba:
Obtén un token y realiza una solicitud GET a /users:
La respuesta se reescribió y ahora se ve similar a lo siguiente:
El encabezado faultname ahora tiene el valor RaiseFault, que es el valor de fault.name que se usa cuando una política RaiseFault provocó que se generara la falla. La política RaiseFault en el flujo condicional 404NotFound generó la respuesta.
En este lab, protegiste una API solicitando un token de OAuth de JWT. Limitaste el tráfico agregando políticas de SpikeArrest. Usaste variables privadas y enmascaramiento de datos para ocultar datos sensibles en sesiones de depuración. También volviste a escribir un mensaje de error de backend y usaste un flujo condicional 404 para restringir las llamadas al backend a recursos específicos.
Última actualización del manual: 6 de agosto de 2025
Prueba más reciente del lab: 6 de agosto de 2025
Copyright 2026 Google LLC. All rights reserved. Google y el logotipo de Google son marcas de Google LLC. Los demás nombres de productos y empresas pueden ser marcas de las respectivas empresas a las que estén asociados.
Este contenido no está disponible en este momento
Te enviaremos una notificación por correo electrónico cuando esté disponible
¡Genial!
Nos comunicaremos contigo por correo electrónico si está disponible
Un lab a la vez
Confirma para finalizar todos los labs existentes y comenzar este
