Použití ověřování Microsoft Entra pro bránu v místním prostředí

PLATÍ PRO: Vývojář | Premium

Brána azure API Management v místním prostředí potřebuje připojení ke své přidružené cloudové instanci služby API Management, aby se hlásil stav, kontrolovala a použila aktualizace konfigurace a odesílala metriky a události.

Kromě použití přístupového tokenu brány (ověřovacího klíče) pro připojení ke cloudové instanci služby API Management můžete bráně v místním prostředí povolit ověření v přidružené cloudové instanci pomocí aplikace Microsoft Entra. Pomocí ověřování Microsoft Entra můžete nakonfigurovat delší dobu vypršení platnosti tajných kódů a pomocí standardních kroků spravovat a obměňovat tajné kódy ve službě Active Directory.

Přehled scénáře

Rozhraní API konfigurace brány v místním prostředí může zkontrolovat Azure RBAC a zjistit, kdo má oprávnění ke čtení konfigurace brány. Po vytvoření aplikace Microsoft Entra s těmito oprávněními se brána v místním prostředí může ověřit v instanci služby API Management pomocí aplikace.

Pokud chcete povolit ověřování Microsoft Entra, proveďte následující kroky:

  1. Vytvořte dvě vlastní role pro:
    • Nechte rozhraní API konfigurace získat přístup k informacím o řízení přístupu na základě role zákazníka
    • Udělení oprávnění ke čtení konfigurace brány v místním prostředí
  2. Udělení přístupu RBAC ke spravované identitě instance služby API Management
  3. Vytvoření aplikace Microsoft Entra a udělení přístupu ke čtení konfigurace brány
  4. Nasazení brány s novými možnostmi konfigurace

Požadavky

  • Instance služby API Management na úrovni služby Developer nebo Premium. V případě potřeby proveďte následující rychlý start: Vytvořte instanci služby Azure API Management.
  • Zřízení prostředku brány v instanci
  • Povolte spravovanou identitu přiřazenou systémem v instanci.
  • Image kontejneru brány v místním prostředí verze 2.2 nebo novější

Poznámky k omezením

  • Podporuje se pouze spravovaná identita přiřazená systémem.

Vytváření vlastních rolí

Vytvořte následující dvě vlastní role , které jsou přiřazeny v dalších krocích. Pomocí oprávnění uvedených v následujících šablonách JSON můžete vytvářet vlastní role pomocí webu Azure Portal, Azure CLI, Azure PowerShellu nebo jiných nástrojů Azure.

Při konfiguraci vlastních rolí aktualizujte AssignableScopes vlastnost odpovídajícími hodnotami oboru pro váš adresář, například předplatné, ve kterém je vaše instance služby API Management nasazená.

Role služby Validator přístupu k rozhraní API pro konfiguraci služby API Management

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

Role čtenáře konfigurace brány služby API Management

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

Přidání přiřazení rolí

Přiřazení role validátoru přístupu k rozhraní API pro konfiguraci služby API Management

Přiřaďte roli validátoru přístupu ke službě API Configuration API Management spravované identitě instance služby API Management. Podrobný postup přiřazení role najdete v tématu Přiřazení rolí Azure pomocí portálu.

  • Rozsah: Skupina prostředků nebo předplatné, ve kterém je nasazená instance služby API Management
  • Role: Role služby Validator pro přístup k rozhraní API pro konfiguraci služby API Management
  • Přiřazení přístupu: Spravovaná identita instance služby API Management

Přiřazení role čtenáře konfigurace brány služby API Management

Krok 1: Registrace aplikace Microsoft Entra

Vytvořte novou aplikaci Microsoft Entra. Postup najdete v tématu Vytvoření aplikace Microsoft Entra a instančního objektu, který má přístup k prostředkům. Tuto aplikaci bude používat brána v místním prostředí k ověření v instanci služby API Management.

  • Vygenerování tajného klíče klienta
  • Poznamenejte si následující hodnoty aplikace pro použití v další části při nasazování brány v místním prostředí: ID aplikace (klienta), ID adresáře (tenanta) a tajný klíč klienta.

Krok 2: Přiřazení role čtenáře konfigurace brány služby API Management

Přiřaďte aplikaci roli čtenáře konfigurace brány API Management.

  • Obor: Instance služby API Management (nebo skupina prostředků nebo předplatné, ve kterém je nasazená)
  • Role: Role čtenáře konfigurace brány služby API Management
  • Přiřazení přístupu: Aplikace Microsoft Entra

Nasazení brány v místním prostředí

Nasaďte bránu v místním prostředí do Kubernetes a přidejte nastavení registrace aplikace Microsoft Entra do data prvku bran ConfigMap. V následujícím příkladu konfiguračního souboru YAML má brána název mygw a soubor má název mygw.yaml.

Důležité

Pokud sledujete stávající pokyny k nasazení Kubernetes:

  • Nezapomeňte vynechat krok pro uložení výchozího ověřovacího kubectl create secret generic klíče pomocí příkazu.
  • Nahraďte výchozí soubor YAML vygenerovaný pro vás na webu Azure Portal následujícím základním konfiguračním souborem. Následující soubor přidá konfiguraci Microsoft Entra místo konfigurace pro použití ověřovacího klíče.
---
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

Nasaďte bránu do Kubernetes pomocí následujícího příkazu:

kubectl apply -f mygw.yaml

Ověřte, že je brána spuštěná.

  1. Spuštěním následujícího příkazu zkontrolujte, jestli nasazení proběhlo úspěšně. Vytvoření všech objektů a inicializace podů může chvíli trvat.

    kubectl get deployments
    

    Měla by se vrátit.

    NAME             READY   UP-TO-DATE   AVAILABLE   AGE
    <gateway-name>   1/1     1            1           18s
    
  2. Spuštěním následujícího příkazu zkontrolujte, jestli se služby úspěšně vytvořily. IP adresy a porty vaší služby se budou lišit.

    kubectl get services
    

    Měla by se vrátit.

    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. Vraťte se na web Azure Portal a vyberte Přehled.

  4. Ověřte, že stav zobrazuje zelenou značku zaškrtnutí a za ním počet uzlů, který odpovídá počtu replik zadaných v souboru YAML. Tento stav znamená, že nasazené pody brány v místním prostředí úspěšně komunikují se službou API Management a mají běžný prezenční signál. Snímek obrazovky znázorňující stav brány v místním prostředí na portálu

Tip

  • Spuštěním kubectl logs deployment/<gateway-name> příkazu zobrazte protokoly z náhodně vybraného podu, pokud existuje více než jeden.
  • Spusťte kubectl logs -h úplnou sadu možností příkazů, jako je například zobrazení protokolů pro konkrétní pod nebo kontejner.

Další kroky