Teilen über

Verwenden der Microsoft Entra-Authentifizierung für das selbst gehostete Gateway

GILT FÜR: Developer | Premium

Das selbst gehostete Azure API Management-Gateway benötigt Eine Verbindung mit der zugehörigen cloudbasierten API-Verwaltungsinstanz zum Melden des Status, zum Überprüfen und Anwenden von Konfigurationsupdates sowie zum Senden von Metriken und Ereignissen.

Zusätzlich zur Verwendung eines Gatewayzugriffstokens (Authentifizierungsschlüssel) für die Verbindung mit seiner cloudbasierten API-Verwaltungsinstanz können Sie das selbst gehostete Gateway aktivieren, um sich mit einer Microsoft Entra-App bei der zugehörigen Cloudinstanz zu authentifizieren. Mit der Microsoft Entra-Authentifizierung können Sie längere Ablaufzeiten für geheime Schlüssel konfigurieren und Standardschritte zum Verwalten und Drehen von geheimen Schlüsseln in Active Directory verwenden.

Beschreibung des Szenarios

Die selbst gehostete Gatewaykonfigurations-API kann die rollenbasierte Zugriffssteuerung (RBAC) von Azure überprüfen, um zu bestimmen, wer über Berechtigungen zum Lesen der Gatewaykonfiguration verfügt. Nachdem Sie eine Microsoft Entra-App mit diesen Berechtigungen erstellt haben, kann sich das selbst gehostete Gateway mithilfe der App bei der API-Verwaltungsinstanz authentifizieren.

Führen Sie die folgenden Schritte aus, um die Microsoft Entra-Authentifizierung zu aktivieren:

  1. Erstellen Sie zwei benutzerdefinierte Rollen für:
    • Ermöglicht der Konfigurations-API den Zugriff auf die RBAC-Informationen des Kunden
    • Erteilen von Berechtigungen zum Lesen der selbst gehosteten Gatewaykonfiguration
  2. Gewähren des RBAC-Zugriffs auf die verwaltete Identität der API-Verwaltungsinstanz
  3. Erstellen sie eine Microsoft Entra-App, und gewähren Sie ihm Zugriff auf das Lesen der Gatewaykonfiguration.
  4. Bereitstellen des Gateways mit neuen Konfigurationsoptionen

Voraussetzungen

Hinweise zu Einschränkungen

  • Nur vom System zugewiesene verwaltete Identität wird unterstützt.

Erstellen von benutzerdefinierten Rollen

Erstellen Sie die folgenden beiden benutzerdefinierten Rollen , die in späteren Schritten zugewiesen sind. Sie können die in den folgenden JSON-Vorlagen aufgeführten Berechtigungen verwenden, um die benutzerdefinierten Rollen mithilfe des Azure-Portals, der Azure CLI, der Azure PowerShell oder anderer Azure-Tools zu erstellen.

Aktualisieren Sie beim Konfigurieren der benutzerdefinierten Rollen die AssignableScopes Eigenschaft mit den entsprechenden Bereichswerten für Ihr Verzeichnis, z. B. ein Abonnement, in dem Ihre API-Verwaltungsinstanz bereitgestellt wird.

API-Management-Konfigurations-API-Zugriffsvalidierungsdienstrolle

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

API-Management-Gateway – Konfiguration der Rolle des Lesers

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

Hinzufügen von Rollenzuweisungen

Zuweisen der Rolle für den API-Zugriffsprüfungsdienst in der API-Management-Konfiguration

Weisen Sie der verwalteten Identität der API Management-Instanz die Rolle für den API-Zugriffsprüfungsdienst in der API-Management-Konfiguration zu. Ausführliche Schritte zum Zuweisen einer Rolle finden Sie unter Zuweisen von Azure-Rollen mithilfe des Portals.

  • Bereich: Die Ressourcengruppe oder das Abonnement, in der die API-Verwaltungsinstanz bereitgestellt wird
  • Rolle: Rolle für den API-Zugriffsprüfungsdienst in der API Management-Konfiguration
  • Zuweisen des Zugriffs auf: Verwaltete Identität der API-Verwaltungsinstanz

Zuweisen der Rolle „Leser der im API Management-Gatewaykonfiguration“

Schritt 1: Registrieren der Microsoft Entra-App

Erstellen Sie eine neue Microsoft Entra-App. Weitere Informationen finden Sie unter Erstellen einer Microsoft Entra-Anwendung und eines Dienstprinzipal, der auf Ressourcen zugreifen kann. Die Microsoft Entra-App wird vom selbst gehosteten Gateway verwendet, um sich bei der API-Verwaltungsinstanz zu authentifizieren.

  • Generieren eines geheimen Clientschlüssels
  • Notieren Sie sich die folgenden Anwendungswerte für die Verwendung im nächsten Abschnitt bei der Bereitstellung des selbst gehosteten Gateways: Anwendungs-ID (Client-ID), Verzeichnis-ID (Mandant) und geheimer Clientschlüssel

Schritt 2: Zuweisen der Dienstrolle „Leser der API Management-Gatewaykonfiguration“

Weisen Sie der App die Rolle des API-Verwaltungsgateways -Konfigurationslesediensts zu.

  • Bereich: Die API-Verwaltungsinstanz (oder Ressourcengruppe oder Abonnement, in der die App bereitgestellt wird)
  • Rolle: Konfigurationsleser für API-Management-Gateway
  • Zuweisen des Zugriffs auf: Microsoft Entra-App

Bereitstellen des selbst gehosteten Gateways

Stellen Sie das selbst gehostete Gateway für Kubernetes bereit, und fügen Sie dem data Element der Gateways ConfigMapMicrosoft Entra-App-Registrierungseinstellungen hinzu. Im folgenden Beispiel der YAML-Konfigurationsdatei heißt das Gateway "mygw " und die Datei heißt " mygw.yamlmygw".

Von Bedeutung

Wenn Sie den vorhandenen Kubernetes-Bereitstellungsleitfaden folgen:

  • Stellen Sie sicher, dass Sie den Schritt auslassen, um den Standardauthentifizierungsschlüssel mithilfe des kubectl create secret generic Befehls zu speichern.
  • Ersetzen Sie die folgende grundlegende Konfigurationsdatei für die Standard-YAML-Datei, die das Azure-Portal für Sie generiert. In der folgenden Datei wird die Microsoft Entra-Konfiguration anstelle einer anderen Konfiguration hinzugefügt, um einen Authentifizierungsschlüssel zu verwenden.
---
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

Stellen Sie das Gateway für Kubernetes mit dem folgenden Befehl bereit:

kubectl apply -f mygw.yaml

Vergewissern Sie sich, dass das Gateway läuft

  1. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob die Bereitstellung erfolgreich war. Es kann einige Zeit dauern, bis alle Objekte erstellt und die Pods initialisiert werden.

    kubectl get deployments

    Die Rückgabe sollte wie folgt lauten

    NAME             READY   UP-TO-DATE   AVAILABLE   AGE
<gateway-name>   1/1     1            1           18s

  2. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob die Dienste erfolgreich erstellt wurden. Ihre Dienst-IPs und Ports unterscheiden sich.

    kubectl get services

    Die Rückgabe sollte wie folgt lauten

    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

  3. Wechseln Sie zurück zum Azure-Portal, und wählen Sie "Übersicht" aus.

  4. Vergewissern Sie sich, dass "Status " ein grünes Häkchen anzeigt, gefolgt von einer Knotenanzahl, die der Anzahl der Replikate entspricht, die in der YAML-Datei angegeben sind. Dieser Status bedeutet, dass die selbst gehosteten Gateway-Pods erfolgreich mit dem API-Verwaltungsdienst kommunizieren und einen regelmäßigen "Heartbeat" haben. Screenshot des Status des selbst gehosteten Gateways im Portal.

Tipp

  • Führen Sie den kubectl logs deployment/<gateway-name> Befehl aus, um Protokolle aus einem zufällig ausgewählten Pod anzuzeigen, wenn mehrere vorhanden sind.
  • Führen Sie kubectl logs -h aus, um eine vollständige Liste der Befehlsoptionen zu erhalten, z. B. wie man Protokolle für einen bestimmten Pod oder Container anzeigen kann.

Verwandte Inhalte

  • Last updated on