¿Qué son las áreas de trabajo de Azure API Management?
SE APLICA A: Premium
En API Management, las áreas de trabajo aportan un nuevo nivel de autonomía a los equipos de API de una organización, lo que les permite crear, administrar y publicar API de forma más rápida, confiable, segura y productiva dentro de un servicio de API Management. Al proporcionar acceso administrativo aislado y tiempo de ejecución de API, las áreas de trabajo potencian a los equipos de API a la vez que permiten al equipo de la plataforma de API conservar la supervisión. Esto incluye la supervisión central, el cumplimiento de las directivas de API y el cumplimiento, y la publicación de API para la detección a través de un portal para desarrolladores unificado.
Las áreas de trabajo funcionan como "carpetas" dentro de un servicio API Management:
- Cada área de trabajo contiene API, productos, suscripciones, valores con nombre y recursos relacionados.
- El acceso a los recursos de un área de trabajo se administra a través del control de acceso basado en rol (RBAC) de Azure con roles integrados o personalizados que se pueden asignar a las cuentas de Microsoft Entra.
- Cada área de trabajo está asociada a una puerta de enlace de área de trabajo para enrutar el tráfico de API a los servicios back-end de las API del área de trabajo.
Nota:
- Las características más recientes del área de trabajo se admiten en la API de REST de API Management versión 2023-09-01-preview o posterior.
- Para más consideraciones sobre el precio, consulte Precios de API Management.
Administración de API federada con áreas de trabajo
Las áreas de trabajo agregan compatibilidad de primera clase para un modelo federado de administración de API Management, además de modelos centralizados y en silos ya admitidos. Consulte la tabla siguiente para ver una comparación de estos modelos.
| Modelo | Descripción |
|---|---|
Centralizado
|
Ventajas • Gobernanza y observabilidad centralizadas de API • Portal para desarrolladores unificado para la detección e incorporación de API eficaces • Rentabilidad de la infraestructura Desventajas • No segregación de permisos administrativos entre equipos • La puerta de enlace de API es un único punto de error • Incapacidad de atribuir problemas en tiempo de ejecución a equipos específicos • La carga del equipo de plataforma para facilitar la colaboración puede reducir el crecimiento de la API |
En silos
|
Ventajas • La segregación de permisos administrativos entre equipos aumenta la productividad y la seguridad • La segregación del tiempo de ejecución de la API entre los equipos aumenta la confiabilidad, la resistencia y la seguridad de las API • Los problemas en tiempo de ejecución están contenidos y se atribuyen a equipos específicos Desventajas • Falta de gobernanza y observabilidad centralizadas de API • Falta de un portal para desarrolladores unificado • Mayor costo y administración de plataformas más difícil |
Federada
|
Ventajas • Gobernanza y observabilidad centralizadas de API • Portal para desarrolladores unificado para la detección e incorporación de API eficaces • La segregación de permisos administrativos entre equipos aumenta la productividad y la seguridad • La segregación del tiempo de ejecución de la API entre los equipos aumenta la confiabilidad, la resistencia y la seguridad de las API • Los problemas en tiempo de ejecución están contenidos y se atribuyen a equipos específicos Desventajas • Dificultad de administración y costo de plataforma mayor que en el modelo centralizado, pero menor que en el modelo en silos |
Información general del escenario de ejemplo
Una organización que administra las API mediante Azure API Management podría tener varios equipos de desarrollo que desarrollan, definen, mantienen y producen diferentes conjuntos de API. Las áreas de trabajo permiten a estos equipos usar API Management para administrar, acceder y proteger sus API por separado e independientemente de administrar la infraestructura de servicio.
A continuación, se muestra un flujo de trabajo de ejemplo para crear y usar un área de trabajo.
Un equipo central de la plataforma de API que administra la instancia de API Management crea un área de trabajo y asigna permisos a los colaboradores del área de trabajo utilizando roles RBAC, por ejemplo, permisos para crear o leer recursos en el área de trabajo. También se crea una puerta de enlace de API dedicada para el área de trabajo.
Un equipo central de la plataforma de API usa herramientas de DevOps para crear una canalización de DevOps para las API de esa área de trabajo.
Los miembros del área de trabajo desarrollan, publican, producen y mantienen las API en el área de trabajo.
El equipo central de la plataforma de API administra la infraestructura del servicio, como la supervisión, la resistencia y la aplicación de todas las directivas de API.
API Management en un área de trabajo
Teams administra sus propias API, productos, suscripciones, back-end, directivas, registradores y otros recursos dentro de las áreas de trabajo. Consulte la referencia de la API de REST de API Management para obtener una lista completa de los recursos y las operaciones admitidos en las áreas de trabajo.
Aunque las áreas de trabajo se administran independientemente del servicio API Management y otras áreas de trabajo, por diseño pueden hacer referencia a los recursos de nivel de servicio seleccionados. Consulte Áreas de trabajo y otras características de API Management, más adelante en este artículo.
Puerta de enlace del área de trabajo
Cada área de trabajo se puede asociar a las puertas de enlace del área de trabajo para habilitar el tiempo de ejecución de las API administradas en el área de trabajo. La puerta de enlace del área de trabajo es un recurso de Azure independiente con la misma funcionalidad básica que la puerta de enlace integrada en el servicio API Management.
Las puertas de enlace del área de trabajo se administran independientemente del servicio API Management y entre sí. Garantizan el aislamiento del tiempo de ejecución entre áreas de trabajo, el aumento de la confiabilidad de la API, la resistencia y la seguridad, y permiten la atribución de problemas en tiempo de ejecución a las áreas de trabajo.
- Para obtener información sobre el costo de las puertas de enlace del área de trabajo, consulte Precios de API Management.
- Para obtener una comparación detallada de las puertas de enlace de API Management, consulte Introducción a las puertas de enlace de API Management.
Nota:
Estamos introduciendo la capacidad de asociar varias áreas de trabajo a una puerta de enlace de áreas de trabajo, lo que ayuda a las organizaciones a administrar las API con áreas de trabajo a un costo menor. Esta característica se está implementando a partir de diciembre de 2024 y es posible que no esté disponible para todos los servicios elegibles antes de enero. Más información
Nombre de host de la puerta de enlace
Cada asociación de un área de trabajo a una puerta de enlace de área de trabajo crea un nombre de host único para las API administradas en esa área de trabajo. Los nombres de host predeterminados siguen el patrón <workspace-name>-<hash>.gateway.<region>.azure-api.net. Actualmente, no se admiten nombres de host personalizados para las puertas de enlace del área de trabajo.
Aislamiento de red avanzado
Opcionalmente, una puerta de enlace de área de trabajo se puede configurar en una red virtual privada para aislar el tráfico entrante o saliente. Si se configura, la puerta de enlace del área de trabajo debe usar una subred dedicada en la red virtual.
Para obtener requisitos detallados, consulte Requisitos de recursos de red para las puertas de enlace del área de trabajo.
Nota:
- La configuración de red de una puerta de enlace del área de trabajo es independiente de la configuración de red de la instancia de API Management.
- Actualmente, una puerta de enlace de área de trabajo solo se puede configurar en una red virtual cuando se crea la puerta de enlace. No se puede cambiar la configuración de red de la puerta de enlace ni la configuración posterior.
Escalar la capacidad
Administre la capacidad de puerta de enlace agregando o quitando manualmente unidades de escalado, de forma similar a las unidades que se pueden agregar a la instancia de API Management en determinados niveles de servicio. Los costos de una puerta de enlace del área de trabajo se basan en el número de unidades que seleccione.
Disponibilidad regional
Las puertas de enlace del área de trabajo están disponibles actualmente en las siguientes regiones:
Nota:
Estas regiones son un subconjunto de aquellos en los que API Management está disponible.
- Oeste de EE. UU.
- Centro-Norte de EE. UU
- Este de EE. UU. 2
- Sur de Reino Unido
- Centro de Francia
- Centro-oeste de Alemania
- Norte de Europa
- Este de Asia
- Sudeste de Asia
- Este de Australia
- Japón Oriental
Restricciones de puerta de enlace
Las restricciones siguientes se aplican actualmente a las puertas de enlace del área de trabajo:
- Una puerta de enlace de área de trabajo debe estar en la misma región que la región principal de Azure de la instancia de API Management y en la misma suscripción.
- Un área de trabajo no se puede asociar a una puerta de enlace autohospedada
- Las puertas de enlace del área de trabajo no admiten puntos de conexión privados entrantes
- Las API de las puertas de enlace del área de trabajo no se pueden asignar nombres de host personalizados
- Las API de las áreas de trabajo no están cubiertas por Defender para API
- Las puertas de enlace del área de trabajo no admiten el administrador de credenciales del servicio API Management
- Las puertas de enlace del área de trabajo solo admiten caché interna; no se admite la caché externa
- Las puertas de enlace del área de trabajo no admiten API de GraphQL sintéticas ni API de WebSocket
- Las puertas de enlace del área de trabajo no admiten la creación de API directamente a partir de recursos de Azure, como Azure OpenAI Service, App Service, Function Apps, etc.
- Las métricas de solicitud no se pueden dividir por área de trabajo en Azure Monitor; todas las métricas del área de trabajo se agregan en el nivel de servicio
- Los registros de Azure Monitor se agregan en el nivel de servicio; los registros de nivel de área de trabajo no están disponibles
- Las puertas de enlace del área de trabajo no admiten certificados de entidad de certificación
- Las puertas de enlace del área de trabajo no admiten el escalado automático
- Las puertas de enlace del área de trabajo no admiten identidades administradas, incluidas características relacionadas, como almacenar secretos en Azure Key Vault y usar la directiva
authentication-managed-identity
Roles RBAC para áreas de trabajo
RBAC de Azure se usa para configurar los permisos de los colaboradores del área de trabajo para leer y editar entidades en el área de trabajo. Para obtener una lista de roles, consulte Cómo usar el control de acceso basado en roles en API Management.
Para administrar las API y otros recursos del área de trabajo, los miembros del área de trabajo deben tener asignados roles (o permisos equivalentes mediante roles personalizados) con ámbito al servicio API Management, el área de trabajo y la puerta de enlace del área de trabajo. El rol con ámbito de servicio permite hacer referencia a determinados recursos de nivel de servicio de los recursos de nivel de área de trabajo. Por ejemplo, organice un usuario en un grupo de nivel de área de trabajo para controlar la API y la visibilidad del producto.
Nota:
Para facilitar la administración, configure grupos de Microsoft Entra para asignar permisos de área de trabajo a varios usuarios.
Áreas de trabajo y otras características de API Management
Las áreas de trabajo están diseñadas para ser independientes para maximizar la segregación del acceso administrativo y el entorno de ejecución de la API. Hay varias excepciones para garantizar una mayor productividad y habilitar la gobernanza, la observabilidad, la reutilización y la detección de API en toda la plataforma.
Referencias de recursos: los recursos de un área de trabajo pueden hacer referencia a otros recursos del área de trabajo y a los recursos seleccionados del nivel de servicio, como usuarios, servidores de autorización o grupos de usuarios integrados. No pueden hacer referencia a recursos desde otra área de trabajo.
Por motivos de seguridad, no es posible hacer referencia a recursos de nivel de servicio desde directivas de nivel de área de trabajo (por ejemplo, valores con nombre) o por nombres de recursos, como
backend-iden la directiva set-backend-service.Importante
Todos los recursos de un servicio API Management (por ejemplo, API, productos, etiquetas o suscripciones) deben tener nombres únicos, incluso si se encuentran en áreas de trabajo diferentes. No puede haber ningún recurso del mismo tipo y con el mismo nombre de recurso de Azure en la misma área de trabajo, en otras áreas de trabajo o en el nivel de servicio.
Portal para desarrolladores: las áreas de trabajo son un concepto administrativo y no se exponen como tal a los consumidores del portal para desarrolladores, incluyendo a través de la interfaz de usuario del portal para desarrolladores y la API subyacente. Las API y los productos de un área de trabajo se pueden publicar en el portal para desarrolladores, al igual que las API y los productos en el nivel de servicio.
Nota:
API Management admite la asignación de servidores de autorización definidos en el nivel de servicio a las API dentro de áreas de trabajo.
Migración desde áreas de trabajo en versión preliminar
Si ha creado áreas de trabajo en versión preliminar en Azure API Management y quiere seguir usándolas, migre las áreas de trabajo a la versión disponible con carácter general mediante la asociación de una puerta de enlace de área de trabajo con cada área de trabajo.
Para obtener más información sobre otros cambios que podrían afectar a las áreas de trabajo en versión preliminar, consulte Cambios importantes en las áreas de trabajo (marzo de 2025).
Eliminación de un área de trabajo
Al eliminar un área de trabajo, se eliminan todos sus recursos secundarios (API, productos, etc.) y su puerta de enlace asociada, si va a eliminar el área de trabajo mediante la interfaz de Azure Portal. No elimina la instancia de API Management ni otras áreas de trabajo.