セルフホステッド ゲートウェイに Microsoft Entra 認証を使用する

適用対象: Developer | Premium

Azure API Management セルフホステッド ゲートウェイは、状態の報告、構成更新の確認と適用、メトリックとイベントの送信のために、関連付けられているクラウドベースの API Management インスタンスと接続する必要があります。

ゲートウェイ アクセス トークン (認証キー) を使ってクラウドベースの API Management インスタンスに接続するだけでなく、Microsoft Entra アプリを使って、セルフホステッド ゲートウェイが関連付けられているクラウド インスタンスに対する認証を行うようにすることができます。 Microsoft Entra 認証を使うと、シークレットに長い有効期限を構成し、標準の手順を使って Active Directory のシークレットの管理とローテーションを行うことができます。

シナリオの概要

セルフホステッド ゲートウェイ構成 API は、Azure RBAC を調べて、ゲートウェイ構成を読み取るためのアクセス許可を持っているユーザーを確認できます。 それらのアクセス許可を持つ Microsoft Entra アプリを作成した後、セルフホステッド ゲートウェイは、そのアプリを使って API Management インスタンスに対する認証を行うことができます。

Microsoft Entra 認証を有効にするには、次の手順を完了します。

  1. 次のことを行う 2 つのカスタム ロールを作成します。
    • 構成 API が顧客の RBAC 情報にアクセスできるようにします
    • セルフホステッド ゲートウェイの構成を読み取るアクセス許可を付与します
  2. API Management インスタンスのマネージド ID への RBAC アクセスを許可します
  3. Microsoft Entra アプリを作成し、それにゲートウェイ構成を読み取るためのアクセスを許可してください
  4. 新しい構成オプションを使ってゲートウェイをデプロイします

[前提条件]

制限事項に関する注意事項

  • システム割り当てマネージド ID のみがサポートされています。

カスタム ロールを作成する

後の手順で割り当てる次の 2 つのカスタム ロールを作成します。 次の JSON テンプレートに記載されているアクセス許可を使い、Azure portalAzure CLIAzure PowerShell、またはその他の Azure ツールを使って、カスタム ロールを作成できます。

カスタム ロールを構成するときは、API Management インスタンスがデプロイされるサブスクリプションなど、お使いのディレクトリの適切なスコープ値で AssignableScopes プロパティを更新してください。

API Management Configuration API アクセス検証サービス ロール

{
  "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 ゲートウェイ構成閲覧者ロール

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

ロールの割り当てを追加する

API Management Configuration API アクセス検証サービス ロールを割り当てる

API Management Configuration API アクセス検証サービス ロールを、API Management インスタンスのマネージド ID に割り当てます。 ロールを割り当てる手順について詳しくは、ポータルを使用した Azure ロールの割り当てに関する記事をご覧ください。

  • スコープ: API Management インスタンスがデプロイされるリソース グループまたはサブスクリプション
  • ロール: API Management Configuration API アクセス検証サービス ロール
  • アクセス権の割り当て先: API Management インスタンスのマネージド ID

API Management ゲートウェイ構成閲覧者ロールを割り当てる

手順 1: Microsoft Entra アプリを登録する

新しい Microsoft Entra アプリを作成します。 手順については、「リソースにアクセスできる Microsoft Entra アプリケーションとサービス プリンシパルを作成する」を参照してください。 このアプリは、API Management インスタンスへの認証を行うためにセルフホステッド ゲートウェイによって使われます。

  • クライアント シークレットを生成します
  • 次のセクションでセルフホステッド ゲートウェイをデプロイするときに使うので、アプリケーションの次の値を記録しておきます: アプリケーション (クライアント) ID、ディレクトリ (テナント) ID、クライアント シークレット

手順 2: API Management ゲートウェイ構成閲覧者サービス ロールを割り当てる

API Management ゲートウェイ構成閲覧者サービス ロールを割り当てるをアプリに割り当てます

  • スコープ: API Management インスタンス (または、それがデプロイされるリソース グループまたはサブスクリプション)
  • ロール: API Management ゲートウェイ構成閲覧者ロール
  • アクセスの割り当て先: Microsoft Entra アプリ

セルフホステッド ゲートウェイをデプロイする

セルフホステッド ゲートウェイを Kubernetes にデプロイし、Microsoft Entra アプリの登録設定をゲートウェイの ConfigMapdata 要素に追加します。 次の YAML 構成ファイルの例では、ゲートウェイの名前は mygw で、ファイルの名前は mygw.yaml です。

重要

既存の Kubernetes のデプロイ ガイダンスに従っている場合:

  • kubectl create secret generic コマンドを使って、既定の認証キーを格納するステップを省略してください。
  • Azure portal で自動的に生成される既定の YAML ファイルの代わりに、次の基本的な構成ファイルを使います。 次のファイルでは、認証キーを使う構成の代わりに、Microsoft Entra の構成が追加されます。
---
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

次のコマンドを使ってゲートウェイを Kubernetes にデプロイします。

kubectl apply -f mygw.yaml

ゲートウェイが実行されていることを確認する

  1. 次のコマンドを実行し、デプロイが成功したかどうかを確認します。 すべてのオブジェクトが作成され、ポッドが初期化されるまでに少し時間がかかる場合があります。

    kubectl get deployments
    

    次のように返されるはずです。

    NAME             READY   UP-TO-DATE   AVAILABLE   AGE
    <gateway-name>   1/1     1            1           18s
    
  2. サービスが正常に作成されたかどうかを確認するには、次のコマンドを実行します。 サービスの IP とポートは異なります。

    kubectl get services
    

    次のように返されるはずです。

    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 に戻り、 [概要] を選択します。

  4. [状態] に緑のチェック マークが表示されていることを確認し、そのマークの後ろのノード数が YAML ファイルに指定されているレプリカ数に一致することを確認します。 この状態は、デプロイされたセルフホステッド ゲートウェイ ポッドが API Management サービスと正常に通信しており、"ハートビート" が通常であることを意味します。ポータルでのセルフホステッド ゲートウェイのステータスを示すスクリーンショット。

ヒント

  • ランダムに選択されたポッドのログを表示するには、kubectl logs deployment/<gateway-name> コマンドを実行します (複数存在する場合)。
  • 特定のポッドまたはコンテナーのログを表示する方法など、コマンド オプションの完全なセットに対して kubectl logs -h を実行します。

次のステップ