Använda Microsoft Entra-autentisering för den lokala gatewayen

Artikel
10/18/2023

GÄLLER FÖR: Utvecklare | Premium

Den lokala Azure API Management-gatewayen behöver anslutning till sin associerade molnbaserade API Management-instans för rapporteringsstatus, kontroll av och tillämpning av konfigurationsuppdateringar samt sändning av mått och händelser.

Förutom att använda en gatewayåtkomsttoken (autentiseringsnyckel) för att ansluta till sin molnbaserade API Management-instans kan du göra så att den lokala gatewayen kan autentisera till sin associerade molninstans med hjälp av en Microsoft Entra-app. Med Microsoft Entra-autentisering kan du konfigurera längre förfallotider för hemligheter och använda standardsteg för att hantera och rotera hemligheter i Active Directory.

Scenarioöversikt

Konfigurations-API:et för lokalt installerad gateway kan kontrollera Azure RBAC för att avgöra vem som har behörighet att läsa gatewaykonfigurationen. När du har skapat en Microsoft Entra-app med dessa behörigheter kan den lokala gatewayen autentisera till API Management-instansen med hjälp av appen.

Utför följande steg för att aktivera Microsoft Entra-autentisering:

Skapa två anpassade roller för att:
- Låt konfigurations-API:et få åtkomst till kundens RBAC-information
- Bevilja behörigheter för att läsa gatewaykonfiguration med egen värd
Bevilja RBAC åtkomst till API Management-instansens hanterade identitet
Skapa en Microsoft Entra-app och ge den åtkomst till att läsa gatewaykonfigurationen
Distribuera gatewayen med nya konfigurationsalternativ

Förutsättningar

En API Management-instans på tjänstnivån Utvecklare eller Premium. Slutför följande snabbstart om det behövs: Skapa en Azure API Management-instans.
Etablera en gatewayresurs på instansen.
Aktivera en systemtilldelad hanterad identitet på instansen.
Lokalt installerad gatewaycontaineravbildning version 2.2 eller senare

Anteckningar om begränsningar

Endast systemtilldelad hanterad identitet stöds.

Skapa anpassade roller

Skapa följande två anpassade roller som tilldelas i senare steg. Du kan använda de behörigheter som anges i följande JSON-mallar för att skapa anpassade roller med hjälp av Azure-portalen, Azure CLI, Azure PowerShell eller andra Azure-verktyg.

När du konfigurerar de anpassade rollerna uppdaterar AssignableScopes du egenskapen med lämpliga omfångsvärden för din katalog, till exempel en prenumeration där DIN API Management-instans distribueras.

API Management Configuration API Access Validator Service Role

{
  "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}"
  ]
}

Konfigurationsläsarroll för 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}"
  ]
}

Lägga till rolltilldelningar

Tilldela API Management Configuration API Access Validator Service Role

Tilldela API Management Configuration API Access Validator Service Role till den hanterade identiteten för API Management-instansen. Detaljerade steg för att tilldela en roll finns i Tilldela Azure-roller med hjälp av portalen.

Omfång: Resursgruppen eller prenumerationen där API Management-instansen distribueras
Roll: API Management Configuration API Access Validator Service Role
Tilldela åtkomst till: Hanterad identitet för API Management-instans

Tilldela API Management Gateway-konfigurationsläsarroll

Steg 1: Registrera Microsoft Entra-appen

Skapa en ny Microsoft Entra-app. Anvisningar finns i Skapa ett Microsoft Entra-program och tjänstens huvudnamn som kan komma åt resurser. Den här appen används av den lokala gatewayen för att autentisera till API Management-instansen.

Generera en klienthemlighet
Anteckna följande programvärden för användning i nästa avsnitt när du distribuerar den lokalt installerade gatewayen: program-ID(klient)-ID, katalog-ID (klient) och klienthemlighet

Steg 2: Tilldela tjänstrollen Konfigurationsläsare för API Management Gateway

Tilldela api Management Gateway Configuration Reader Service-rollen till appen.

Omfång: API Management-instansen (eller resursgruppen eller prenumerationen där den distribueras)
Roll: Konfigurationsläsarroll för API Management Gateway
Tilldela åtkomst till: Microsoft Entra-app

Distribuera den lokalt installerade gatewayen

Distribuera den lokalt installerade gatewayen till Kubernetes och lägg till registreringsinställningar för Microsoft Entra-appar i data gatewayelementet ConfigMap. I följande exempel på YAML-konfigurationsfilen heter gatewayen mygw och filen heter mygw.yaml.

Viktigt!

Om du följer den befintliga kubernetes-distributionsvägledningen:

Se till att utelämna steget för att lagra standardautentiseringsnyckeln kubectl create secret generic med kommandot .
Ersätt följande grundläggande konfigurationsfil med yaml-standardfilen som genereras åt dig i Azure-portalen. Följande fil lägger till Microsoft Entra-konfiguration i stället för konfiguration för att använda en autentiseringsnyckel.

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

Distribuera gatewayen till Kubernetes med följande kommando:

kubectl apply -f mygw.yaml

Bekräfta att gatewayen körs

Kör följande kommando för att kontrollera om distributionen lyckades. Det kan ta lite tid innan alla objekt skapas och att poddarna initieras.
```
kubectl get deployments
```
Den bör returnera
```
NAME             READY   UP-TO-DATE   AVAILABLE   AGE
<gateway-name>   1/1     1            1           18s
```

Kör följande kommando för att kontrollera om tjänsterna har skapats. Dina tjänst-IP-adresser och portar kommer att vara olika.

kubectl get services

Den bör returnera

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

Gå tillbaka till Azure-portalen och välj Översikt.
Bekräfta att Status visar en grön bockmarkering följt av ett nodantal som matchar antalet repliker som anges i YAML-filen. Den här statusen innebär att de distribuerade lokala gatewaypoddarna kommunicerar med API Management-tjänsten och har ett regelbundet "pulsslag".

Dricks

kubectl logs deployment/<gateway-name> Kör kommandot för att visa loggar från en slumpmässigt vald podd om det finns fler än en.
Kör kubectl logs -h för en fullständig uppsättning kommandoalternativ, till exempel hur du visar loggar för en specifik podd eller container.

Nästa steg

Läs mer om översikten över en egen värdbaserad API Management-gateway.
Läs mer om vägledning för att köra den lokalt installerade gatewayen på Kubernetes i produktion.
Lär dig hur du distribuerar en lokalt installerad API Management-gateway till Azure Arc-aktiverade Kubernetes-kluster.

Dela via