Ler em inglês

Compartilhar via


Gerenciamento de API federado com workspaces

APLICA-SE A: Premium

Este artigo fornece uma visão geral dos workspaces de Gerenciamento de API e como eles capacitam as equipes de desenvolvimento de API descentralizadas a gerenciar e transformar suas APIs em produtos em uma infraestrutura de serviço comum.

Por que as organizações devem federar o gerenciamento de API?

Hoje, as organizações enfrentam cada vez mais desafios no gerenciamento de uma proliferação de APIs. À medida que o número de APIs e equipes de desenvolvimento de API aumenta, a complexidade de gerenciá-las também aumenta. Essa complexidade pode levar ao aumento da sobrecarga operacional, aos riscos de segurança e à redução da agilidade. Por um lado, as organizações desejam estabelecer uma infraestrutura de API centralizada para garantir a governança, a segurança e a conformidade da API. Por outro lado, eles querem que suas equipes de API inovem e respondam rapidamente às necessidades dos negócios, sem a sobrecarga de gerenciar uma plataforma de API.

Um modelo federado de gerenciamento de API atende a essas necessidades. O gerenciamento de API federada permite o gerenciamento descentralizado de API por equipes de desenvolvimento com isolamento apropriado de planos de controle e dados, mantendo a governança centralizada, o monitoramento e a descoberta de API gerenciados por uma equipe de plataforma de API. Esse modelo supera as limitações de abordagens alternativas, como o gerenciamento de API totalmente centralizado pela equipe da plataforma ou o gerenciamento de API em silo por cada equipe de desenvolvimento.

O gerenciamento de API federada fornece:

  • Governança e observabilidade de API centralizadas
  • Um portal de desenvolvedor unificado para descoberta e integração de API eficazes
  • Permissões administrativas segregadas entre equipes de API, aumentando a produtividade e a segurança
  • Runtime de API segregada entre equipes de API, melhoria da confiabilidade, resiliência e segurança

Como os workspaces habilitam o gerenciamento de API federada

No Gerenciamento de API do Azure, use workspaces para implementar o gerenciamento de API federada. Os workspaces funcionam como "pastas" em um serviço de Gerenciamento de API:

  • Cada workspace contém APIs, produtos, assinaturas, valores nomeados e recursos relacionados. Confira a referência da API REST de Gerenciamento de API para obter uma lista completa de recursos e operações compatíveis com workspaces.
  • O acesso do Teams aos recursos em um workspace é gerenciado por meio do RBAC (controle de acesso baseado em função) do Azure com funções internas ou personalizadas atribuíveis a contas do Microsoft Entra e com escopo para um workspace.
  • Cada workspace é associado a um ou mais gateways de workspace para rotear o tráfego de API para os serviços de back-end de APIs no workspace.
  • A equipe da plataforma pode aplicar políticas de API que abrangem APIs em workspaces, monitorar a plataforma exibindo os logs de todos os workspaces e implementar uma experiência centralizada de descoberta de API com um portal do desenvolvedor.

Diagrama conceitual do serviço de Gerenciamento de API com workspaces.

Observação

  • Os recursos mais recentes do workspace são compatíveis com a API REST de Gerenciamento de API versão 2023-09-01-preview ou posterior.
  • Para obter considerações de preço, veja Preço do Gerenciamento de API.

Embora os workspaces sejam gerenciados independentemente do serviço de Gerenciamento de API e de outros workspaces, por design, eles podem referenciar recursos selecionados no nível do serviço. Consulte Workspaces e outros recursos de Gerenciamento de API, posteriormente neste artigo.

Visão geral do cenário de exemplo

Uma organização que gerencia APIs usando o Gerenciamento de API do Azure pode ter várias equipes de desenvolvimento que desenvolvem, definem, mantêm e produzem diferentes conjuntos de APIs. Os workspaces permitem que essas equipes usem Gerenciamento de API para gerenciar, acessar e proteger as APIs delas separadamente e independentemente do gerenciamento da infraestrutura de serviço.

Veja a seguir um fluxo de trabalho de amostra para criar e usar um workspace.

  1. Uma equipe central de plataforma de API que gerencia a instância de Gerenciamento de API cria um espaço de trabalho e atribui permissões aos colaboradores do espaço de trabalho usando funções do RBAC, por exemplo, permissões para criar ou ler recursos no espaço de trabalho. Um gateway de API com escopo de workspace também é criado para o workspace.

  2. Uma equipe central da plataforma de API usa ferramentas de DevOps para criar um pipeline de DevOps para APIs nesse workspace.

  3. Os membros do workspace desenvolvem, publicam, produzem e mantêm APIs no workspace.

  4. A equipe central da plataforma de API gerencia a infraestrutura do serviço, como monitoramento, resiliência e imposição de políticas de todas as APIs.

Gateway de workspace

Cada workspace é associado a um ou mais gateways de workspace para habilitar o runtime de APIs gerenciadas dentro do workspace. O gateway de workspace é um recurso autônomo do Azure com a mesma funcionalidade principal do gateway integrado ao serviço de Gerenciamento de API.

Os gateways de workspace são gerenciados independentemente do serviço de Gerenciamento de API e uns dos outros. Elas permitem o isolamento do runtime entre workspaces ou casos de uso, aumentando a confiabilidade da API, a resiliência e a segurança e habilitando a atribuição de problemas de runtime para workspaces.

Observação

Estamos introduzindo a capacidade de associar vários workspaces a um gateway de workspace, ajudando as organizações a gerenciar APIs com workspaces a um custo menor. Esse recurso será implementado a partir de dezembro de 2024 e talvez não esteja disponível para todos os serviços qualificados antes de janeiro. Saiba mais

Nome do host do gateway

Cada associação de um workspace a um gateway de workspace cria um nome de host exclusivo para APIs gerenciadas nesse workspace. Os nomes de host padrão seguem o padrão <workspace-name>-<hash>.gateway.<region>.azure-api.net. Atualmente, não há suporte para nomes de host personalizados para gateways de workspace.

Isolamento da rede

Opcionalmente, um gateway de workspace pode ser configurado em uma rede virtual privada para isolar o tráfego de entrada e/ou de saída. Se configurado, o gateway de workspace precisa usar uma sub-rede dedicada na rede virtual.

Para obter requisitos detalhados, confira os Requisitos de recursos de rede para gateways de workspace.

Observação

  • A configuração de rede de um gateway do workspace é independente da configuração de rede da instância do Gerenciamento de API.
  • Atualmente, um gateway de workspace só pode ser configurado em uma rede virtual quando o gateway é criado. Você não pode alterar a configuração ou as definições de rede do gateway posteriormente.

Dimensionar a capacidade

Gerencie a capacidade do gateway adicionando ou removendo manualmente unidades de escala, semelhantes às unidades que podem ser adicionadas à instância de Gerenciamento de API em determinadas camadas de serviço. Os custos de um gateway de workspace são baseados no número de unidades selecionadas.

Disponibilidade regional

Para obter uma lista atual de regiões em que os gateways do workspace estão disponíveis, consulte Disponibilidade de camadas v2 e gateways de workspace.

Restrições de gateway

As seguintes restrições atualmente se aplicam a gateways de workspace:

  • Um gateway de workspace precisa estar na mesma região que a região primária do Azure da instância de Gerenciamento de API e na mesma assinatura.
  • Um workspace não pode ser associado a um gateway auto-hospedado
  • Os gateways de workspace não dão suporte a pontos de extremidade privados de entrada
  • Nomes de host personalizados não podem ser atribuídos a APIs em gateways de workspace
  • APIs em workspaces não são cobertas pelo Defender para APIs
  • Os gateways de workspace não dão suporte ao gerenciador de credenciais do serviço de Gerenciamento de API
  • Os gateways de workspace dão suporte apenas ao cache interno; não há suporte para cache externo
  • Os gateways de workspace não dão suporte a APIs sintéticas do GraphQL e APIs WebSocket
  • Os gateways de workspace não dão suporte à criação de APIs diretamente com base em recursos do Azure, como o Serviço OpenAI do Azure, o Serviço de Aplicativo, os Aplicativos de Funções e assim por diante
  • As métricas de solicitação não podem ser divididas por workspace no Azure Monitor; todas as métricas do workspace são agregadas no nível do serviço
  • Os logs do Azure Monitor são agregados no nível do serviço; os logs no nível do workspace não estão disponíveis
  • Os gateways de workspace não dão suporte a certificados de AC
  • Os gateways de workspace não dão suporte ao dimensionamento automático
  • Os gateways de workspace não dão suporte a identidades gerenciadas, incluindo recursos relacionados, como armazenar segredos no Azure Key Vault e usar a política authentication-managed-identity

Funções RBAC para workspaces

O RBAC do Azure é usado para configurar as permissões dos colaboradores do workspace para ler e editar entidades no workspace. Para obter uma lista de funções, veja Como usar o controle de acesso baseado em função no Gerenciamento de API.

Para gerenciar APIs e outros recursos no workspace, os membros do workspace precisam ter funções atribuídas (ou permissões equivalentes usando funções personalizadas) com escopo para o serviço de Gerenciamento de API, o workspace e o gateway de workspace. A função de escopo de serviço habilita a referência de recursos do nível de serviço a partir dos recursos do nível de espaço de trabalho. Por exemplo, organize um usuário em um grupo no nível do espaço de trabalho para controlar a API e a visibilidade do produto.

Observação

Para facilitar o gerenciamento, configure grupos do Microsoft Entra para atribuir permissões de workspace a vários usuários.

Workspaces e outros recursos de Gerenciamento de API

Os workspaces foram projetados para serem independentes a fim de maximizar a segregação do acesso administrativo e do runtime da API. Há várias exceções para garantir maior produtividade e habilitar a governança, a observabilidade, a reutilização e a descoberta de API em toda a plataforma.

  • Referências de recurso – os recursos em um workspace podem referenciar outros recursos no workspace e recursos selecionados no nível do serviço, como usuários, servidores de autorização ou grupos de usuários internos. Eles não podem referenciar recursos de outro workspace.

    Por motivos de segurança, não é possível referenciar recursos de nível de serviço de políticas no nível do workspace (por exemplo, valores nomeados) ou por nomes de recursos, como backend-id na política set-backend-service.

    Importante

    Todos os recursos em um serviço de Gerenciamento de API (por exemplo, APIs, produtos, marcas ou assinaturas) precisam ter nomes exclusivos, mesmo que estejam localizados em workspaces diferentes. Não pode haver nenhum recurso do mesmo tipo e com o mesmo nome de recurso do Azure no mesmo workspace, em outros workspaces ou no nível de serviço.

  • Portal do desenvolvedor – os workspaces são um conceito administrativo e não são exibidos como tal para os consumidores do portal do desenvolvedor, inclusive por meio da interface do usuário do portal do desenvolvedor e da API subjacente. APIs e produtos em um workspace podem ser publicados no portal do desenvolvedor, assim como APIs e produtos no nível do serviço.

    Observação

    O Gerenciamento de API dá suporte à atribuição de servidores de autorização definidos no nível do serviço a APIs em workspaces.

Migrar de workspaces em versão prévia

Se você criou workspaces em versão prévia no Gerenciamento de API do Azure e deseja continuar usando-os, migre seus workspaces para a versão em disponibilidade geral associando um gateway de workspace a cada workspace.

Para obter detalhes e saber mais sobre outras alterações que podem afetar seus workspaces em versão prévia, consulte Alterações interruptivas em workspaces (março de 2025).

Como excluir um workspace

A exclusão de um workspace usando a interface do portal do Azure exclui todos os respectivos recursos-filho (APIs, produtos e assim por diante) e o gateway associado. Isso não exclui a instância de Gerenciamento de API ou outros workspaces.