Usar a autenticação do Microsoft Entra para o gateway auto-hospedado

Artigo
10/18/2023

APLICA-SE A: Developer | Prémio

O gateway auto-hospedado do Gerenciamento de API do Azure precisa de conectividade com sua instância de Gerenciamento de API baseada em nuvem associada para relatar o status, verificar e aplicar atualizações de configuração e enviar métricas e eventos.

Além de usar um token de acesso de gateway (chave de autenticação) para se conectar com sua instância de Gerenciamento de API baseada em nuvem, você pode habilitar o gateway auto-hospedado para autenticar em sua instância de nuvem associada usando um aplicativo Microsoft Entra. Com a autenticação do Microsoft Entra, você pode configurar tempos de expiração mais longos para segredos e usar etapas padrão para gerenciar e girar segredos no Ative Directory.

Descrição geral do cenário

A API de configuração de gateway auto-hospedado pode verificar o RBAC do Azure para determinar quem tem permissões para ler a configuração do gateway. Depois de criar um aplicativo Microsoft Entra com essas permissões, o gateway auto-hospedado pode se autenticar na instância de Gerenciamento de API usando o aplicativo.

Para habilitar a autenticação do Microsoft Entra, conclua as seguintes etapas:

Crie duas funções personalizadas para:
- Permita que a API de configuração tenha acesso às informações RBAC do cliente
- Conceder permissões para ler a configuração do gateway auto-hospedado
Conceder acesso RBAC à identidade gerenciada da instância de Gerenciamento de API
Criar um aplicativo Microsoft Entra e conceder-lhe acesso para ler a configuração do gateway
Implantar o gateway com novas opções de configuração

Pré-requisitos

Uma instância de Gerenciamento de API na camada de serviço Developer ou Premium. Se necessário, conclua o seguinte guia de início rápido: Criar uma instância de Gerenciamento de API do Azure.
Provisione um recurso de gateway na instância.
Habilite uma identidade gerenciada atribuída ao sistema na instância.
Imagem de contêiner de gateway auto-hospedado versão 2.2 ou posterior

Notas de limitações

Somente a identidade gerenciada atribuída ao sistema é suportada.

Criar funções personalizadas

Crie as duas funções personalizadas a seguir que são atribuídas em etapas posteriores. Você pode usar as permissões listadas nos seguintes modelos JSON para criar as funções personalizadas usando o portal do Azure, a CLI do Azure, o Azure PowerShell ou outras ferramentas do Azure.

Ao configurar as funções personalizadas, atualize a AssignableScopes propriedade com valores de escopo apropriados para seu diretório, como uma assinatura na qual sua instância de Gerenciamento de API é implantada.

Configuração de Gerenciamento de API Função de serviço Validador de acesso à API

{
  "Description": "Can access RBAC permissions on the API Management resource to authorize requests in Configuration API.",
  "IsCustom": true,
  "Name": "API Management Configuration API Access Validator Service Role",
  "Permissions": [
    {
      "Actions": [
        "Microsoft.Authorization/*/read"
      ],
      "NotActions": [],
      "DataActions": [],
      "NotDataActions": []
    }
  ],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/{subscriptionID}"
  ]
}

Função de leitor de configuração do API Management Gateway

{
  "Description": "Can read self-hosted gateway configuration from Configuration API",
  "IsCustom": true,
  "Name": "API Management Gateway Configuration Reader Role",
  "Permissions": [
    {
      "Actions": [],
      "NotActions": [],
      "DataActions": [
        "Microsoft.ApiManagement/service/gateways/getConfiguration/action"
      ],
      "NotDataActions": []
    }
  ],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/{subscriptionID}"
  ]
}

Adicionar atribuições de função

Atribuir Função de Serviço Validador de Acesso à API de Configuração de Gerenciamento de API

Atribua a função de serviço Validador de acesso da API de configuração de API à identidade gerenciada da instância de gerenciamento de API. Para obter etapas detalhadas para atribuir uma função, consulte Atribuir funções do Azure usando o portal.

Escopo: o grupo de recursos ou a assinatura na qual a instância de Gerenciamento de API é implantada
Função: Função de serviço do Validador de Acesso à API de Configuração de Gerenciamento de API
Atribuir acesso a: Identidade gerenciada da instância de Gerenciamento de API

Atribuir função de leitor de configuração do API Management Gateway

Etapa 1: Registrar o aplicativo Microsoft Entra

Crie um novo aplicativo Microsoft Entra. Para conhecer as etapas, consulte Criar um aplicativo e uma entidade de serviço do Microsoft Entra que possam acessar recursos. Este aplicativo será usado pelo gateway auto-hospedado para autenticar na instância de Gerenciamento de API.

Gerar um segredo do cliente
Anote os seguintes valores de aplicativo para uso na próxima seção ao implantar o gateway auto-hospedado: ID do aplicativo (cliente), ID do diretório (locatário) e segredo do cliente

Etapa 2: Atribuir função de serviço do Leitor de Configuração do Gateway de Gerenciamento de API

Atribua a função de serviço Leitor de Configuração do API Management Gateway ao aplicativo.

Escopo: A instância de Gerenciamento de API (ou grupo de recursos ou assinatura na qual ela é implantada)
Função: Função de leitor de configuração do API Management Gateway
Atribuir acesso a: Aplicação Microsoft Entra

Implantar o gateway auto-hospedado

Implante o gateway auto-hospedado no Kubernetes, adicionando configurações de registro do aplicativo Microsoft Entra ao data elemento dos gateways ConfigMap. No exemplo a seguir arquivo de configuração YAML, o gateway é chamado mygw e o arquivo é chamado mygw.yaml.

Importante

Se você estiver seguindo as diretrizes de implantação do Kubernetes existentes:

Certifique-se de omitir a etapa para armazenar a chave de autenticação padrão usando o kubectl create secret generic comando.
Substitua o seguinte arquivo de configuração básica pelo arquivo YAML padrão gerado para você no portal do Azure. O arquivo a seguir adiciona a configuração do Microsoft Entra no lugar da configuração para usar uma chave de autenticação.

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: mygw-env
  labels:
    app: mygw
data:
  config.service.endpoint: "<service-name>.configuration.azure-api.net"
  config.service.auth: azureAdApp 
  config.service.auth.azureAd.authority: "https://login.microsoftonline.com"  
  config.service.auth.azureAd.tenantId: "<Azure AD tenant ID>" 
  config.service.auth.azureAd.clientId: "<Azure AD client ID>" 
  config.service.auth.azureAd.clientSecret: "<Azure AD client secret>"
  gateway.name: <gateway-id>
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: mygw
  labels:
    app: mygw
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mygw
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0
      maxSurge: 25%
  template:
    metadata:
      labels:
        app: mygw
    spec:
      terminationGracePeriodSeconds: 60
      containers:
      - name: mygw
        image: mcr.microsoft.com/azure-api-management/gateway:v2
        ports:
        - name: http
          containerPort: 8080
        - name: https
          containerPort: 8081
          # Container port used for rate limiting to discover instances
        - name: rate-limit-dc
          protocol: UDP
          containerPort: 4290
          # Container port used for instances to send heartbeats to each other
        - name: dc-heartbeat
          protocol: UDP
          containerPort: 4291
        readinessProbe:
          httpGet:
            path: /status-0123456789abcdef
            port: http
            scheme: HTTP
          initialDelaySeconds: 0
          periodSeconds: 5
          failureThreshold: 3
          successThreshold: 1
        envFrom:
        - configMapRef:
            name: mygw-env
---
apiVersion: v1
kind: Service
metadata:
  name: mygw-live-traffic
  labels:
    app: mygw
spec:
  type: LoadBalancer
  externalTrafficPolicy: Local
  ports:
  - name: http
    port: 80
    targetPort: 8080
  - name: https
    port: 443
    targetPort: 8081
  selector:
    app: mygw
---
apiVersion: v1
kind: Service
metadata:
  name: mygw-instance-discovery
  labels:
    app: mygw
  annotations:
    azure.apim.kubernetes.io/notes: "Headless service being used for instance discovery of self-hosted gateway"
spec:
  clusterIP: None
  type: ClusterIP
  ports:
  - name: rate-limit-discovery
    port: 4290
    targetPort: rate-limit-dc
    protocol: UDP
  - name: discovery-heartbeat
    port: 4291
    targetPort: dc-heartbeat
    protocol: UDP
  selector:
    app: mygw

Implante o gateway no Kubernetes com o seguinte comando:

kubectl apply -f mygw.yaml

Confirme se o gateway está em execução

Execute o seguinte comando para verificar se a implantação foi bem-sucedida. Pode levar um pouco de tempo para que todos os objetos sejam criados e para que os pods sejam inicializados.
```
kubectl get deployments
```
Deve voltar
```
NAME             READY   UP-TO-DATE   AVAILABLE   AGE
<gateway-name>   1/1     1            1           18s
```

Execute o seguinte comando para verificar se os serviços foram criados com êxito. Os IPs e as portas do seu serviço serão diferentes.

kubectl get services

Deve voltar

NAME                                TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)                      AGE
<gateway-name>-live-traffic         ClusterIP      None            <none>        4290/UDP,4291/UDP   9m1s
<gateway-name>-instance-discovery   LoadBalancer   10.99.236.168   <pending>     80:31620/TCP,443:30456/TCP   9m1s

Volte para o portal do Azure e selecione Visão geral.
Confirme se Status mostra uma marca de seleção verde, seguida por uma contagem de nós que corresponde ao número de réplicas especificadas no arquivo YAML. Esse status significa que os pods de gateway auto-hospedados implantados estão se comunicando com êxito com o serviço de Gerenciamento de API e têm uma "pulsação" regular.

Gorjeta

Execute o kubectl logs deployment/<gateway-name> comando para visualizar logs de um pod selecionado aleatoriamente se houver mais de um.
Execute kubectl logs -h para obter um conjunto completo de opções de comando, como exibir logs para um pod ou contêiner específico.

Próximos passos

Saiba mais sobre a visão geral do gateway auto-hospedado do Gerenciamento de API.
Saiba mais sobre as orientações para executar o gateway auto-hospedado no Kubernetes em produção.
Saiba como implantar o gateway auto-hospedado do Gerenciamento de API em clusters Kubernetes habilitados para Azure Arc.

Partilhar via