Microsoft Entra-hitelesítés használata a saját üzemeltetésű átjáróhoz

Az Azure API Management saját üzemeltetésű átjárójának kapcsolatra van szüksége a társított felhőalapú API Management-példánysal a jelentési állapot jelentéséhez, a konfigurációfrissítések ellenőrzéséhez és alkalmazásához, valamint metrikák és események küldéséhez.

Amellett, hogy egy átjáró hozzáférési jogkivonatát (hitelesítési kulcsát) használja a felhőalapú API Management-példányhoz való csatlakozáshoz, a microsoft Entra-alkalmazással engedélyezheti a saját üzemeltetésű átjáró számára a kapcsolódó felhőpéldány hitelesítését. A Microsoft Entra-hitelesítéssel hosszabb lejárati időt konfigurálhat a titkos kódokhoz, és standard lépésekkel kezelheti és elforgathatja a titkos kulcsokat az Active Directoryban.

Forgatókönyv áttekintése

A saját üzemeltetésű átjárókonfigurációs API ellenőrizheti az Azure RBAC-t annak megállapításához, hogy kinek van engedélye az átjáró konfigurációjának olvasására. Miután létrehozott egy Microsoft Entra-alkalmazást ezekkel az engedélyekkel, a saját üzemeltetésű átjáró hitelesítheti magát az API Management-példányon az alkalmazás használatával.

A Microsoft Entra-hitelesítés engedélyezéséhez hajtsa végre a következő lépéseket:

  1. Hozzon létre két egyéni szerepkört a következőhöz:
    • A konfigurációs API-nak hozzáférést kell kapnia az ügyfél RBAC-adataihoz
    • Engedélyek megadása a saját üzemeltetésű átjáró konfigurációjának olvasásához
  2. RBAC-hozzáférés biztosítása az API Management-példány felügyelt identitásához
  3. Microsoft Entra-alkalmazás létrehozása és hozzáférés biztosítása az átjáró konfigurációjának olvasásához
  4. Az átjáró üzembe helyezése új konfigurációs beállításokkal

Előfeltételek

Korlátozások megjegyzései

  • Csak a rendszer által hozzárendelt felügyelt identitás támogatott.

Egyéni szerepkörök létrehozása

Hozza létre a következő két egyéni szerepkört , amelyek a későbbi lépésekben lesznek hozzárendelve. Az alábbi JSON-sablonokban felsorolt engedélyekkel hozhatja létre az egyéni szerepköröket az Azure Portal, az Azure CLI, az Azure PowerShell vagy más Azure-eszközök használatával.

Az egyéni szerepkörök konfigurálásakor frissítse a tulajdonságot a AssignableScopes címtár megfelelő hatókörértékeivel, például egy előfizetéssel, amelyben az API Management-példány telepítve van.

API Management Configuration API Access Validator szolgáltatásszerepkör

{
  "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/denyAssignments/read",
        "Microsoft.Authorization/roleAssignments/read",
        "Microsoft.Authorization/roleDefinitions/read"
      ],
      "NotActions": [],
      "DataActions": [],
      "NotDataActions": []
    }
  ],
  "NotDataActions": [],
  "AssignableScopes": [
    "/subscriptions/{subscriptionID}"
  ]
}

API Management Gateway konfigurációolvasó szerepkör

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

Szerepkör-hozzárendelések hozzáadása

API Management Configuration API Access Validator szolgáltatásszerepkör hozzárendelése

Rendelje hozzá az API Management Configuration API Access Validator szolgáltatásszerepkört az API Management-példány felügyelt identitásához. A szerepkörök hozzárendelésének részletes lépéseit az Azure-szerepkörök hozzárendelése a portálon című témakörben találja.

  • Hatókör: Az az erőforráscsoport vagy előfizetés, amelyben az API Management-példány telepítve van
  • Szerepkör: API Management Configuration API Access Validator szolgáltatásszerepkör
  • Hozzáférés hozzárendelése az API Management-példány felügyelt identitásához

API Management Gateway konfigurációolvasó szerepkör hozzárendelése

1. lépés: A Microsoft Entra alkalmazás regisztrálása

Hozzon létre egy új Microsoft Entra-alkalmazást. A lépésekért tekintse meg az erőforrásokhoz hozzáférő Microsoft Entra-alkalmazás és szolgáltatásnév létrehozását. Ezt az alkalmazást a saját üzemeltetésű átjáró fogja használni az API Management-példányon való hitelesítéshez.

  • Ügyfélkulcs létrehozása
  • Jegyezze fel a következő alkalmazásértékeket a következő szakaszban a saját üzemeltetésű átjáró üzembe helyezésekor: alkalmazás(ügyfél) azonosítója, címtár-(bérlői) azonosító és ügyfélkód

2. lépés: API Management Gateway konfigurációolvasó szolgáltatásszerepkör hozzárendelése

Rendelje hozzá az API Management Gateway konfigurációolvasó szolgáltatásszerepkörét az alkalmazáshoz.

  • Hatókör: Az API Management-példány (vagy erőforráscsoport vagy előfizetés, amelyben üzembe helyezték)
  • Szerepkör: API Management Gateway konfigurációolvasó szerepkör
  • Hozzáférés hozzárendelése a következőhöz: Microsoft Entra-alkalmazás

A saját üzemeltetésű átjáró üzembe helyezése

Telepítse a saját üzemeltetésű átjárót a Kubernetesben, és adjon hozzá Microsoft Entra alkalmazásregisztrációs beállításokat az data átjárók ConfigMapeleméhez. Az alábbi YAML-konfigurációs fájlban az átjáró neve mygw, a fájl neve mygw.yamlpedig mygw.

Fontos

Ha a Kubernetes meglévő üzembehelyezési útmutatóját követi:

  • Ügyeljen arra, hogy kihagyja az alapértelmezett hitelesítési kulcs parancs használatával kubectl create secret generic történő tárolására vonatkozó lépést.
  • Cserélje le az alábbi alapkonfigurációs fájlt az Azure Portalon létrehozott alapértelmezett YAML-fájlra. Az alábbi fájl hozzáadja a Microsoft Entra konfigurációt a konfiguráció helyett a hitelesítési kulcs használatához.
---
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

Helyezze üzembe az átjárót a Kubernetesben a következő paranccsal:

kubectl apply -f mygw.yaml

Ellenőrizze, hogy az átjáró fut-e

  1. Futtassa a következő parancsot annak ellenőrzéséhez, hogy az üzembe helyezés sikeres volt-e. Az összes objektum létrehozása és a podok inicializálása eltarthat egy kis ideig.

    kubectl get deployments
    

    Vissza kell térnie

    NAME             READY   UP-TO-DATE   AVAILABLE   AGE
    <gateway-name>   1/1     1            1           18s
    
  2. Futtassa a következő parancsot annak ellenőrzéséhez, hogy a szolgáltatások sikeresen létrejöttek-e. A szolgáltatás IP-címei és portja eltérő lesz.

    kubectl get services
    

    Vissza kell térnie

    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. Lépjen vissza az Azure Portalra, és válassza az Áttekintés lehetőséget.

  4. Győződjön meg arról, hogy az Állapot zöld pipát, majd egy csomópontszámot jelenít meg, amely megfelel a YAML-fájlban megadott replikák számának. Ez az állapot azt jelenti, hogy az üzembe helyezett, saját üzemeltetésű átjáró podok sikeresen kommunikálnak az API Management szolgáltatással, és rendszeres "szívveréssel" rendelkeznek. Screenshot showing status of self-hosted gateway in the portal.

Tipp.

  • Futtassa a kubectl logs deployment/<gateway-name> parancsot egy véletlenszerűen kiválasztott pod naplóinak megtekintéséhez, ha több van.
  • Futtassa kubectl logs -h a parancsbeállítások teljes készletét, például egy adott pod vagy tároló naplóinak megtekintését.

Következő lépések