Aracılığıyla paylaş


Şirket içinde barındırılan ağ geçidi için Microsoft Entra kimlik doğrulamasını kullanma

ŞUNLAR İÇİN GEÇERLİDİR: Geliştirici | Premium

Azure API Management kendi kendine barındırılan ağ geçidinin durumu raporlaması, yapılandırma güncelleştirmelerini kontrol edip uygulaması ve ölçümler ile olayları gönderebilmesi için ilişkili bulut tabanlı API Management örneğiyle bağlantıya ihtiyacı vardır.

Bulut tabanlı API Management örneğine bağlanmak için bir ağ geçidi erişim belirteci (kimlik doğrulama anahtarı) kullanmanın yanı sıra, Microsoft Entra uygulamasını kullanarak kendi kendine barındırılan geçidin ilişkili bulut örneğine kimlik doğrulaması yapmasını sağlayabilirsiniz. Microsoft Entra kimlik doğrulaması ile gizli diziler için daha uzun süre sonu süreleri yapılandırabilir ve Active Directory'de gizli dizileri yönetmek ve döndürmek için standart adımları kullanabilirsiniz.

Senaryoya genel bakış

Şirket içinde barındırılan ağ geçidi yapılandırma API'si, ağ geçidi yapılandırmasını okuma izinlerine sahip olan kişileri belirlemek için Azure rol tabanlı erişim denetimini (RBAC) denetleyebilir. Bu izinlere sahip bir Microsoft Entra uygulaması oluşturduktan sonra, şirket içinde barındırılan ağ geçidi uygulamayı kullanarak API Management örneğinde kimlik doğrulaması yapabilir.

Microsoft Entra kimlik doğrulamasını etkinleştirmek için aşağıdaki adımları tamamlayın:

  1. şu iki özel rol oluşturun:
    • Yapılandırma API'sinin müşterinin RBAC bilgilerine erişmesine izin ver
    • Kendi kendine barındırılan ağ geçidi yapılandırmasını okumak için izin ver
  2. API Management örneğinin yönetilen kimliğine RBAC erişimi verin
  3. Bir Microsoft Entra uygulaması oluşturun ve ağ geçidi yapılandırmasını okuması için erişim verin.
  4. Ağ geçidini yeni yapılandırma seçenekleriyle dağıtma

Önkoşullar

Sınırlama notları

  • Yalnızca sistem tarafından atanan yönetilen kimlik desteklenir.

Özel roller oluşturma

Sonraki adımlarda atanan aşağıdaki iki özel rolü oluşturun. Azure portalı, Azure CLI, AzurePowerShell veya diğer Azure araçlarını kullanarak özel roller oluşturmak için aşağıdaki JSON şablonlarında listelenen izinleri kullanabilirsiniz.

Özel rolleri yapılandırırken, API Management örneğinizin dağıtıldığı abonelik gibi dizininiz için uygun kapsam değerleriyle AssignableScopes özelliğini güncelleyin.

API Management Yapılandırma API'sinde Erişim Doğrulayıcı Hizmeti Rolü

{
  "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 Ağ Geçidi Yapılandırma Okuyucu Rolü

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

Rol atamaları ekleme

API Yönetimi Yapılandırma API'si Erişim Doğrulama Hizmet Rolünü Atayın

API Management Yapılandırması API Erişim Doğrulayıcı Hizmeti Rolünü API Management örneğinin yönetilen kimliğine atayın. Rol atamaya yönelik ayrıntılı adımlar için bkz. Portalı kullanarak Azure rolleri atama.

  • Kapsam: API Management örneğinin dağıtıldığı kaynak grubu veya abonelik
  • Rol: API Yönetimi Yapılandırması İçin API Erişim Doğrulayıcı Hizmeti Rolü
  • API Management örneğinin yönetilen kimliğine erişimi ata

API Yönetimi Ağ Geçidi Yapılandırma Okuyucusu Rolü Atama

1. Adım: Microsoft Entra uygulamasını kaydetme

Yeni bir Microsoft Entra uygulaması oluşturun. Adımlar için bkz. Kaynaklara erişebilen bir Microsoft Entra uygulaması ve hizmet sorumlusu oluşturma. Kendi kendine barındırılan ağ geçidi, API Management örneğinde kimlik doğrulamak için Microsoft Entra uygulamasını kullanır.

  • İstemci sırrı oluşturun
  • Kendin barındırılan ağ geçidini dağıtırken bir sonraki bölümde kullanmak amacıyla aşağıdaki uygulama değerlerini not edin: uygulama (istemci) kimliği, dizin (kiracı) kimliği ve istemci gizli anahtarı

2. Adım: API Management Ağ Geçidi Yapılandırma Okuyucu Hizmeti Rolü Atama

Uygulamaya API Management Ağ Geçidi Yapılandırma Okuyucu hizmeti rolünü atayın.

  • Kapsam: API Management örneği (veya uygulamanın dağıtıldığı kaynak grubu veya abonelik)
  • Rol: API Management Ağ Geçidi Yapılandırma Okuyucu
  • Erişim atama: Microsoft Entra uygulaması

Kendi kendine barındırılan ağ geçidini dağıtın

Kendi barındırdığınız ağ geçidini Kubernetes'e dağıtın ve Microsoft Entra uygulama kayıt ayarlarını ağ geçitlerinin data öğesine ConfigMap ekleyin. Aşağıdaki örnek YAML yapılandırma dosyasında, ağ geçidi mygw ve dosya olarak adlandırılır mygw.yaml.

Önemli

Mevcut Kubernetes dağıtım kılavuzunu izliyorsanız:

  • komutunu kullanarak varsayılan kimlik doğrulama anahtarını depolama adımını atladığından kubectl create secret generic emin olun.
  • Aşağıdaki temel yapılandırma dosyasını, Azure portalının sizin için oluşturduğu varsayılan YAML dosyasıyla değiştirin. Aşağıdaki dosya, kimlik doğrulama anahtarı kullanmak üzere yapılandırma yerine Microsoft Entra yapılandırmasını ekler.
---
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

Aşağıdaki komutla ağ geçidini Kubernetes'e dağıtın:

kubectl apply -f mygw.yaml

Ağ geçidinin çalıştığını onaylayın

  1. Dağıtımın başarılı olup olmadığını denetlemek için aşağıdaki komutu çalıştırın. Tüm nesnelerin oluşturulması ve podların başlatılması biraz zaman alabilir.

    kubectl get deployments
    

    İade edilmesi gerekir

    NAME             READY   UP-TO-DATE   AVAILABLE   AGE
    <gateway-name>   1/1     1            1           18s
    
  2. Hizmetlerin başarıyla oluşturulup oluşturulmadığını denetlemek için aşağıdaki komutu çalıştırın. Hizmet IP'leriniz ve bağlantı noktalarınız farklı olacaktır.

    kubectl get services
    

    İade edilmesi gerekir

    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. Azure portalına dönün ve Genel Bakış'ı seçin.

  4. Durum'un yeşil bir onay işareti ve ardından YAML dosyasında belirtilen çoğaltma sayısıyla eşleşen bir düğüm sayısı gösterdiğini onaylayın. Bu durum, dağıtılan kendi kendine barındırılan ağ geçidi podlarının API Management hizmetiyle başarıyla iletişim kurarak normal bir "kalp atışına" sahip olduğu anlamına gelir. Portalda kendi kendine barındırılan ağ geçidinin durumunu gösteren ekran görüntüsü.

Tavsiye

  • Birden fazla pod varsa, rastgele seçilen bir poddaki günlükleri görüntülemek için kubectl logs deployment/<gateway-name> komutunu çalıştırın.
  • Komut seçeneklerinin eksiksiz bir seti, yani belirli bir pod veya kapsayıcının günlüklerini nasıl görüntüleyeceğiniz gibi seçenekler için kubectl logs -h komutunu çalıştırın.