Partilhar via


O que são espaços de trabalho no Gerenciamento de API do Azure?

APLICA-SE A: Premium

No Gerenciamento de API, os espaços de trabalho trazem um novo nível de autonomia para as equipes de API de uma organização, permitindo que elas criem, gerenciem e publiquem APIs de forma mais rápida, confiável, segura e produtiva dentro de um serviço de Gerenciamento de API. Ao fornecer acesso administrativo isolado e tempo de execução da API, os espaços de trabalho capacitam as equipes de API e, ao mesmo tempo, permitem que a equipe da plataforma de API mantenha a supervisão. Isso inclui monitoramento central, imposição de políticas e conformidade de API e publicação de APIs para descoberta por meio de um portal unificado do desenvolvedor.

Os espaços de trabalho funcionam como "pastas" dentro de um serviço de Gerenciamento de API:

  • Cada espaço de trabalho contém APIs, produtos, assinaturas, valores nomeados e recursos relacionados.
  • O acesso a recursos em um espaço de trabalho é 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.
  • Cada espaço de trabalho é associado a um gateway de espaço de trabalho para rotear o tráfego de API para os serviços de back-end de APIs no espaço de trabalho.

Diagrama conceitual do serviço de Gerenciamento de API com espaços de trabalho.

Nota

  • Os recursos mais recentes do espaço de trabalho são suportados na API REST de Gerenciamento de API versão 2023-09-01-preview ou posterior.
  • Para obter considerações sobre preços, consulte Preços de gerenciamento de API.

Gerenciamento de API federada com espaços de trabalho

Os espaços de trabalho adicionam suporte de primeira classe para um modelo federado de gerenciamento de APIs no Gerenciamento de APIs, além de modelos centralizados e em silos já suportados. Consulte a tabela a seguir para obter uma comparação desses modelos.

Modelo Description
Centralizado

Diagrama do modelo centralizado de Gerenciamento de API do Azure.
Vantagens
• Governança e observabilidade centralizada da API
• Portal unificado do desenvolvedor para descoberta e integração eficazes de API
• Eficiência de custos da infraestrutura

Desvantagens
• Sem segregação de permissões administrativas entre equipes
• O gateway de API é um único ponto de falha
• Incapacidade de atribuir problemas de tempo de execução a equipes específicas
• A sobrecarga da equipe da plataforma para facilitar a colaboração pode reduzir o crescimento da API
Silos

Diagrama do modelo em silos do Gerenciamento de API do Azure.
Vantagens
• Segregação de permissões administrativas entre equipes aumenta a produtividade e segurança
• A segregação do tempo de execução da API entre as equipes aumenta a confiabilidade, resiliência e segurança da API
• Problemas de tempo de execução são contidos e atribuíveis a equipes específicas

Desvantagens
• Falta de governança e observabilidade centralizada da API
• Falta de um portal unificado para desenvolvedores
• Aumento de custos e gerenciamento de plataforma mais difícil
Federado

Diagrama do modelo federado do Gerenciamento de API do Azure.
Vantagens
• Governança e observabilidade centralizada da API
• Portal unificado do desenvolvedor para descoberta e integração eficazes de API
• Segregação de permissões administrativas entre equipes aumenta a produtividade e segurança
• A segregação do tempo de execução da API entre as equipes aumenta a confiabilidade, resiliência e segurança da API
• Problemas de tempo de execução são contidos e atribuíveis a equipes específicas

Desvantagens
• Custo da plataforma e dificuldade de gestão maior do que no modelo centralizado, mas menor do que no modelo em silos

Descrição geral de 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 espaços de trabalho permitem que essas equipes usem o Gerenciamento de API para gerenciar, acessar e proteger suas APIs separadamente e independentemente do gerenciamento da infraestrutura de serviço.

A seguir está um fluxo de trabalho de exemplo para criar e usar um espaço de trabalho.

  1. Uma equipe central da 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 RBAC - por exemplo, permissões para criar ou ler recursos no espaço de trabalho. Um gateway de API dedicado também é criado para o espaço de trabalho.

  2. Uma equipe central de plataforma de API usa ferramentas de DevOps para criar um pipeline de DevOps para APIs nesse espaço de trabalho.

  3. Os membros do espaço de trabalho desenvolvem, publicam, produzem e mantêm APIs no espaço de trabalho.

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

Gerenciamento de API em um espaço de trabalho

As equipes gerenciam suas próprias APIs, produtos, assinaturas, back-ends, políticas, registradores e outros recursos em espaços de trabalho. Consulte a referência da API REST de Gerenciamento de API para obter uma lista completa de recursos e operações suportados em espaços de trabalho.

Embora os espaços de trabalho sejam gerenciados independentemente do serviço de Gerenciamento de API e de outros espaços de trabalho, por design, eles podem fazer referência a recursos de nível de serviço selecionados. Consulte Espaços de trabalho e outros recursos de gerenciamento de API, mais adiante neste artigo.

Gateway de espaço de trabalho

Cada espaço de trabalho pode ser associado a gateways de espaço de trabalho para habilitar o tempo de execução de APIs gerenciadas dentro do espaço de trabalho. O gateway de espaço de trabalho é um recurso autônomo do Azure com a mesma funcionalidade principal do gateway incorporado ao seu serviço de Gerenciamento de API.

Os gateways de espaço de trabalho são gerenciados independentemente do serviço de Gerenciamento de API e uns dos outros. Eles garantem o isolamento do tempo de execução entre espaços de trabalho, aumentando a confiabilidade, resiliência e segurança da API e permitindo a atribuição de problemas de tempo de execução aos espaços de trabalho.

  • Para obter informações sobre o custo dos gateways de espaço de trabalho, consulte Preços de gerenciamento de API.
  • Para obter uma comparação detalhada dos gateways de gerenciamento de API, consulte Visão geral dos gateways de gerenciamento de API.

Nome do host do gateway

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

Nota

Até outubro de 2024, as APIs em espaços de trabalho podem ser acessadas em tempo de execução usando o nome do host do gateway da sua instância de Gerenciamento de API, além do nome do host do gateway do espaço de trabalho.

Isolamento da rede

Um gateway de espaço de trabalho pode, opcionalmente, ser configurado em uma rede virtual privada para isolar o tráfego de entrada e/ou saída. Se configurado, o gateway de espaço de trabalho deve usar uma sub-rede dedicada na rede virtual.

Para obter requisitos detalhados, consulte Requisitos de recursos de rede para gateways de espaço de trabalho.

Nota

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

Dimensionar 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 espaço de trabalho são baseados no número de unidades selecionadas.

Disponibilidade regional

Os gateways de espaço de trabalho estão atualmente disponíveis nas seguintes regiões:

Nota

Essas regiões são um subconjunto daquelas onde o Gerenciamento de API está disponível.

  • E.U.A. Oeste
  • E.U.A. Centro-Norte
  • E.U.A. Leste 2
  • Sul do Reino Unido
  • França Central
  • Alemanha Centro-Oeste
  • Europa do Norte
  • Ásia Leste
  • Sudeste Asiático
  • Leste da Austrália
  • Leste do Japão

Restrições de gateway

Atualmente, as seguintes restrições se aplicam aos gateways de espaço de trabalho:

  • Um gateway de espaço de trabalho precisa estar na mesma região que a região principal do Azure da instância de Gerenciamento de API e na mesma assinatura.
  • Um gateway pode ser associado apenas a um espaço de trabalho
  • Um espaço de trabalho não pode ser associado a um gateway auto-hospedado
  • Os gateways de espaço de trabalho não suportam pontos de extremidade privados de entrada
  • APIs em gateways de espaço de trabalho não podem receber nomes de host personalizados
  • As APIs em espaços de trabalho não são cobertas pelo Defender for APIs
  • Os gateways de espaço de trabalho não suportam o gerenciador de credenciais do serviço de Gerenciamento de API
  • Os gateways de espaço de trabalho suportam apenas cache interno; cache externo não é suportado
  • Os gateways de espaço de trabalho não suportam APIs sintéticas do GraphQL e APIs do WebSocket
  • Os gateways de espaço de trabalho não suportam a criação de APIs diretamente a partir de recursos do Azure, como o Serviço OpenAI do Azure, o Serviço de Aplicativo, os Aplicativos de Função e assim por diante
  • As métricas de solicitação não podem ser divididas por espaço de trabalho no Azure Monitor; Todas as métricas do espaço de trabalho são agregadas no nível de serviço
  • Os logs do Azure Monitor são agregados no nível de serviço; Os logs no nível do espaço de trabalho não estão disponíveis
  • Os gateways de espaço de trabalho não suportam certificados de CA
  • Os gateways de espaço de trabalho não suportam dimensionamento automático
  • Os gateways de espaço de trabalho não dão suporte a identidades gerenciadas, incluindo recursos relacionados, como armazenar segredos no Cofre de Chaves do Azure e usar a authentication-managed-identity política

Funções RBAC para espaços de trabalho

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

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

Nota

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

Espaços de trabalho e outros recursos de gerenciamento de API

Os espaços de trabalho são projetados para serem independentes para maximizar a segregação do acesso administrativo e do tempo de execução da API. Há várias exceções para garantir maior produtividade e permitir a governança, a observabilidade, a reutilização e a descoberta de API em toda a plataforma.

  • Referências de recursos - Os recursos em um espaço de trabalho podem fazer referência a outros recursos no espaço de trabalho e a recursos selecionados do nível de serviço, como usuários, servidores de autorização ou grupos de usuários internos. Eles não podem fazer referência a recursos de outro espaço de trabalho.

    Por motivos de segurança, não é possível fazer referência a recursos de nível de serviço a partir de políticas de nível de espaço de trabalho (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, tags ou assinaturas) precisam ter nomes exclusivos, mesmo que estejam localizados em espaços de trabalho diferentes. Não pode haver recursos do mesmo tipo e com o mesmo nome de recurso do Azure no mesmo espaço de trabalho, em outros espaços de trabalho ou no nível de serviço.

  • Portal do desenvolvedor - Os espaços de trabalho são um conceito administrativo e não são apresentados como tal aos 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 espaço de trabalho podem ser publicados no portal do desenvolvedor, assim como APIs e produtos no nível de serviço.

    Nota

    O Gerenciamento de API oferece suporte à atribuição de servidores de autorização definidos no nível de serviço a APIs em espaços de trabalho.

Migrar de espaços de trabalho de visualização

Se você criou espaços de trabalho de visualização no Gerenciamento de API do Azure e deseja continuar a usá-los, migre seus espaços de trabalho para a versão disponível em geral associando um gateway de espaço de trabalho a cada espaço de trabalho.

Para obter detalhes e saber mais sobre outras alterações que podem afetar seus espaços de trabalho de visualização, consulte Workspaces breaking changes (março de 2025).

Eliminar uma área de trabalho

A exclusão de um espaço de trabalho exclui todos os seus recursos filhos (APIs, produtos e assim por diante) e seu gateway associado, se você estiver excluindo o espaço de trabalho usando a interface do portal do Azure. Ele não exclui a instância de Gerenciamento de API ou outros espaços de trabalho.