Llegeix en anglès

Comparteix a través de

Administración de API federada con áreas de trabajo

  • Article

SE APLICA A: Premium

En este artículo se proporciona información general sobre las áreas de trabajo de API Management y cómo permiten a los equipos de desarrollo de API descentralizados administrar y productivizar sus API en una infraestructura de servicio común.

¿Por qué las organizaciones deben federar la administración de API?

Hoy en día, las organizaciones enfrentan cada vez más desafíos en la administración de una proliferación de API. A medida que crece el número de API y equipos de desarrollo de API, también lo hace la complejidad de administrarlas. Esta complejidad puede dar lugar a un aumento de la sobrecarga operativa, los riesgos de seguridad y la agilidad reducida. Por un lado, las organizaciones quieren establecer una infraestructura de API centralizada para garantizar la gobernanza, la seguridad y el cumplimiento de la API. Por otro lado, quieren que sus equipos de API innoven y respondan rápidamente a las necesidades empresariales, sin la sobrecarga de administrar una plataforma de API.

Un modelo federado de administración de API aborda estas necesidades. La administración de API federada permite la administración de la API descentralizada por parte de los equipos de desarrollo con el aislamiento adecuado de los planos de control y datos, a la vez que mantiene la gobernanza centralizada, la supervisión y la detección de API administradas por un equipo de la plataforma de API. Este modelo supera las limitaciones de los enfoques alternativos, como la administración de API totalmente centralizada por el equipo de la plataforma o la administración de API en silos por cada equipo de desarrollo.

La administración de API federadas proporciona:

  • Gobernanza y observabilidad centralizadas de API
  • Un portal para desarrolladores unificado para la detección e incorporación de API eficaces
  • Permisos administrativos separados entre equipos de API, mejora de la productividad y la seguridad
  • Entorno de ejecución de API segregado entre equipos de API, mejora de la confiabilidad, la resistencia y la seguridad

Cómo permiten las áreas de trabajo la administración de API federada

En Azure API Management, use áreas de trabajo para implementar una API administrada federada. 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. 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.
  • El acceso de Teams 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 y se limita a un área de trabajo.
  • Cada área de trabajo está asociada a una o varias puertas 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.
  • El equipo de plataforma puede aplicar directivas de API que abarcan API en áreas de trabajo, supervisar la plataforma mediante la visualización de los registros de todas las áreas de trabajo e implementar una experiencia centralizada de detección de API con un portal para desarrolladores.

Diagrama conceptual del servicio API Management con áreas 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.

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.

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.

  1. 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 con ámbito de área de trabajo para el área de trabajo.

  2. 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.

  3. Los miembros del área de trabajo desarrollan, publican, producen y mantienen las API en el área de trabajo.

  4. 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.

Puerta de enlace del área de trabajo

Cada área de trabajo está asociada a una o varias puertas de enlace de á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í. Permiten el aislamiento del tiempo de ejecución entre áreas de trabajo o casos de uso, lo que aumenta 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.

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

Para obtener una lista actual de las regiones en las que están disponibles las puertas de enlace del área de trabajo, consulte Disponibilidad de los niveles v2 y las puertas de enlace del área de trabajo.

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-id en la directiva set-backend-service.

    Important

    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.

Contenido relacionado