環境でエンタープライズ プロキシまたはファイアウォールを使用して送信トラフィックを制限する必要がある場合、Azure Arc ゲートウェイは接続を有効にするプロセスを簡略化するのに役立ちます。
Azure Arc ゲートウェイを使用すると、次のことができます。
- 9 つの完全修飾ドメイン名 (FQDN) にのみパブリック ネットワーク アクセスを開いて Azure Arc に接続します。
- Azure Connected Machine エージェントが Azure Arc ゲートウェイ経由で Azure に送信するすべてのトラフィックを表示および監査します。
Azure Arc ゲートウェイのしくみ
Arc ゲートウェイは、2 つの新しいコンポーネントを導入することによって機能します。
Arc ゲートウェイ リソースは、Azure トラフィックの共通フロントエンドとして機能する Azure リソースです。 ゲートウェイ リソースは、特定のドメイン/URL 上で提供されます。 このリソースは、この記事の中で説明されている手順に従って作成する必要があります。 ゲートウェイ リソースを正常に作成すると、成功応答にドメイン/URL が含まれます。
Arc プロキシは、独自のポッド ("Azure Arc プロキシ" と呼ばれます) として実行される新しいコンポーネントです。 このコンポーネントは、Azure Arc エージェントと拡張機能によって使用される、転送プロキシとして機能します。 Azure Arc プロキシの構成は必要ありません。 バージョン 1.21.10 の Arc 対応 Kubernetes エージェントの時点で、このポッドはコア Arc エージェントの一部となり、Arc 対応 Kubernetes クラスターのコンテキスト内で実行されるようになりました。
ゲートウェイが配置されると、トラフィックは次のホップを経由して送信されます。Arc エージェント → Azure Arc プロキシ → エンタープライズ プロキシ → Arc ゲートウェイ → ターゲット サービス。
現在の制限事項
現在、Azure Arc ゲートウェイには次の制限があります。 構成を計画する際は、これらの要因を考慮してください。
- 各 Azure サブスクリプションには、5 つの Azure Arc ゲートウェイ リソースの制限があります。
- Azure Arc ゲートウェイでは、Azure パブリック クラウドでのみ接続がサポートされます。
- トランスポート層セキュリティ (TLS) の終了または検査が必要な環境では、Azure Arc ゲートウェイを使用することはお勧めしません。 環境で TLS 終了または検査が必要な場合は、Azure Arc ゲートウェイ エンドポイント (
<your URL prefix>.gw.arc.azure.com) の TLS 検査をスキップします。 詳細については、 Azure Arc ゲートウェイと TLS 検査に関するページを参照してください。
Important
Azure Arc ゲートウェイでは、Azure Arc 対応 Kubernetes を使用するために必要な接続が提供されますが、クラスターで一部の拡張機能やサービスを使用するには、追加のエンドポイントを有効にする必要がある場合があります。 詳細については、「 その他のシナリオ」を参照してください。
Azure Arc ゲートウェイのセットアップを計画する
Azure Arc ゲートウェイを構成する前に、考慮すべきいくつかの要因があります。
リージョンの選択
ランタイム接続は、Azure Front Door グローバル エッジ ネットワークを介して配信されます。これにより、クライアントが最も近いプレゼンス ポイントに自動的にルーティングされ、待機時間の短いアクセスとシームレスなフェールオーバーが実現されます。 ゲートウェイの作成時に選択するリージョンには、ゲートウェイ リソースと管理メタデータが含まれます。 リージョンは、ゲートウェイのランタイム エンドポイントやパフォーマンス、またはクライアントが実行時に接続する場所を制限しません。
Azure Arc ゲートウェイあたりの Azure Arc 対応リソース
Azure Arc ゲートウェイを使用して Azure Arc デプロイを計画する場合は、環境に必要なゲートウェイ リソースの数を検討してください。 この決定は、各 Azure リージョンで管理する予定のリソースの数によって異なります。
Azure Arc 対応 Kubernetes リソースの場合のみ、一般的なルールとして、Azure リージョンあたり 1,000 個のリソースを処理できる Azure Arc ゲートウェイ リソースが 1 つです。 ただし、Azure Arc 対応サーバー、Azure Arc 対応 Kubernetes クラスター、Azure Local インスタンスの組み合わせで Azure Arc ゲートウェイを使用できます。 環境全体で 必要な Azure Arc ゲートウェイ リソースの数を計算するのに役立つ数式が用意されています。
必要なアクセス許可
Arc ゲートウェイ リソースを作成し、Arc 対応 Kubernetes クラスターとの関連付けを管理するには、次のアクセス許可が必要です。
Microsoft.Kubernetes/connectedClusters/settings/default/writeMicrosoft.hybridcompute/gateways/readMicrosoft.hybridcompute/gateways/write
Arc ゲートウェイ リソースを作成する
Arc ゲートウェイ リソースは、Azure CLI または Azure PowerShell を使用して作成できます。
Arc ゲートウェイ リソースを作成する際は、そのリソースが作成されるサブスクリプションとリソース グループを、Azure リージョンと共に指定します。 ただし、同じテナント内のすべての Arc 対応リソースは、独自のサブスクリプションまたは Azure リージョンに関係なくそのリソースを使用できます。 Azure Arc ゲートウェイを使用する Arc 対応リソースを含む各サブスクリプションには、Microsoft.Kubernetes リソース プロバイダーが登録されている必要があります。
Azure にアクセスできるマシンで、次の Azure CLI コマンドを実行します。
az extension add -n arcgatewayそれから、次の Azure CLI コマンドを実行して Arc ゲートウェイ リソースを作成し、プレースホルダーを目的の値に置き換えます。
az arcgateway create --name <gateway name> --resource-group <resource group> --location <region> --gateway-type public --allowed-features * --subscription <subscription name or id>
通常、Arc ゲートウェイ リソースの作成が完了するまでに約 30 分かかります。
必要な URL へのアクセスを確認する
リソースが正常に作成されると、成功応答に Arc ゲートウェイ URL が含まれます。 Arc リソースが存在する環境で、Arc ゲートウェイの URL と次の表のすべての URL が許可されていることを確認します。
| URL | Purpose |
|---|---|
<Your URL prefix>.gw.arc.azure.com |
あなたのゲートウェイ URL。 この URL を取得するには、リソースの作成後に az arcgateway list を実行します。 |
management.azure.com |
ARM コントロール チャネルに必要な Azure Resource Manager エンドポイント。 |
<region>.obo.arc.azure.com |
クラスター接続が構成されている場合に必要です。 |
login.microsoftonline.com、<region>.login.microsoft.com |
ID アクセス トークンを取得するために使用される Microsoft Entra ID エンドポイント。 |
gbl.his.arc.azure.com、<region>.his.arc.azure.com |
Arc エージェントと通信するためのクラウド サービス エンドポイント。 短い名前を使用します (米国東部の場合は eus など)。 |
mcr.microsoft.com、*.data.mcr.microsoft.com |
Azure Arc エージェント用のコンテナー イメージをプルするために必要です。 |
Arc ゲートウェイ リソースを使用して Kubernetes クラスターを Azure Arc にオンボードする
環境が Azure Arc 対応 Kubernetes に必要なすべての前提条件を満たしていることを確認します。 Azure Arc ゲートウェイを使用しているため、一連のネットワーク要件のすべてを満たす必要はありません。
送信プロキシ サーバーを使用するには、デプロイ マシンで Azure CLI に必要な環境変数を設定します。
export HTTP_PROXY=<proxy-server-ip-address>:<port> export HTTPS_PROXY=<proxy-server-ip-address>:<port> export NO_PROXY=<cluster-apiserver-ip-address>:<port>Kubernetes クラスターで、
proxy-httpsパラメーターとproxy-httpパラメーターを指定して connect コマンドを実行します。 プロキシ サーバーが HTTP と HTTPS の両方で設定されている場合は、HTTP プロキシには--proxy-http、HTTPS プロキシには--proxy-httpsを必ず使用してください。 プロキシ サーバーで HTTP のみが使用される場合は、両方のパラメーターにその値を使用できます。az connectedk8s connect -g <resource_group> -n <cluster_name> --gateway-resource-id <gateway_resource_id> --proxy-https <proxy_value> --proxy-http http://<proxy-server-ip-address>:<port> --proxy-skip-range <excludedIP>,<excludedCIDR> --location <region>Note
一部のネットワーク要求 (クラスター内のサービス間通信を含むものなど) は、送信の通信のためにプロキシ サーバーを介してルーティングされるトラフィックから分離する必要があります。 エージェントからこれらのエンドポイントへの通信が送信プロキシ経由で行われないように、
--proxy-skip-rangeパラメーターを使用して CIDR 範囲とエンドポイントをコンマ区切りで指定します。 少なくとも、クラスター内のサービスの CIDR 範囲をこのパラメーターの値として指定します。 たとえばkubectl get svc -Aが、すべてのサービスがClusterIP範囲内の10.0.0.0/16値を持つサービスの一覧を返す場合、--proxy-skip-rangeに指定する値は10.0.0.0/16,kubernetes.default.svc,.svc.cluster.local,.svcです。ほとんどの送信プロキシ環境では、
--proxy-http、--proxy-https、および--proxy-skip-rangeが必要です。 プロキシが予期する信頼された証明書をエージェント ポッドの信頼された証明書ストアに挿入する必要がある場合にのみ、--proxy-certを使用します。送信プロキシは、Websocket 接続を許可するように構成する必要があります。
Arc ゲートウェイを使用するように既存のクラスターを構成する
Arc ゲートウェイを使用するように既存のクラスターを更新するには、次のコマンドを実行します。
az connectedk8s update -g <resource_group> -n <cluster_name> --gateway-resource-id <gateway_resource_id>
更新が成功したことを確認するには、次のコマンドを実行し、応答が true であることを確認します。
az connectedk8s show -g <resource_group> -n <cluster_name> --query 'gateway.enabled'
Arc ゲートウェイを使用するようにクラスターを更新した後、エンタープライズ プロキシまたはファイアウォールで以前に許可されていた Arc エンドポイントの一部を削除できます。 エンドポイントを削除する前に、少なくとも 1 時間待ちます。 Arc ゲートウェイに必要なエンドポイントは削除しないでください。
Arc ゲートウェイを削除する
Important
ここで説明する手順は、Arc 対応 Kubernetes 上の Arc ゲートウェイにのみ適用されます。 Azure Local での Arc ゲートウェイのデタッチの詳細については、「Azure Local 用 Azure Arc ゲートウェイについて」を参照してください。
Arc ゲートウェイを無効にし、Arc ゲートウェイ リソースと Arc 対応クラスター間の関連付けを削除するには、次のコマンドを実行します。
az connectedk8s update -g <resource_group> -n <cluster_name> --disable-gateway
トラフィックを監視する
ゲートウェイのトラフィックを監査するには、ゲートウェイ ルーターのログを表示します。
-
kubectl get pods -n azure-arcを実行します。 - Arc プロキシ ポッドを識別します (その名前は
arc-proxy-で始まります)。 -
kubectl logs -n azure-arc <Arc Proxy pod name>を実行します。
その他のシナリオ
Arc ゲートウェイには、クラスターのオンボードに必要なエンドポイントと、追加の Arc 対応シナリオに必要なエンドポイントの一部が含まれます。 採用するシナリオに基づいて、プロキシで追加のエンドポイントを許可することが必要になる場合があります。
Arc ゲートウェイが使用されている場合は、次のいずれかのシナリオで一覧表示されているすべてのエンドポイントも許可する必要があります。
-
Azure Monitor のコンテナーの分析情報:
*.ods.opinsights.azure.com*.oms.opinsights.azure.com*.monitoring.azure.com
-
Azure Key Vault:
<vault-name>.vault.azure.net
-
Microsoft Defender for Containers:
*.ods.opinsights.azure.com*.oms.opinsights.azure.com*.cloud.defender.microsoft.com
-
Azure Arc 対応データ サービス
*.ods.opinsights.azure.com*.oms.opinsights.azure.com*.monitoring.azure.com
Azure Arc ゲートウェイのアーキテクチャ
Azure Arc ゲートウェイのアーキテクチャの詳細については、次の情報を確認してください。
Azure Arc ゲートウェイ転送プロトコル
次の図は、Azure Arc ゲートウェイで使用される転送プロトコルを示しています。
Azure Arc ゲートウェイと TLS 検査
Azure Arc ゲートウェイは、Azure Arc プロキシと Azure Arc ゲートウェイの間に TLS セッションを確立することによって機能します。 この TLS セッション内で、Azure Arc プロキシは、入れ子になった HTTP 接続要求を Azure Arc ゲートウェイ リソースに送信します。 接続要求は、目的のターゲット宛先に接続を転送するようにリソースに指示します。 その後、ターゲットの宛先自体が TLS 上にある場合は、Azure Arc エージェントとターゲット宛先の間に内部エンド ツー エンドの TLS セッションが確立されます。
Azure Arc ゲートウェイで終端型プロキシを使用すると、ネストされた HTTP 接続要求がプロキシに表示されます。 このような要求が許可される可能性がありますが、入れ子になった TLS 終了を行わない限り、ターゲット宛先への TLS 暗号化トラフィックをインターセプトすることはできません。 この動作は、標準の TLS 終端プロキシの機能の範囲外です。 終了プロキシを使用する場合は、Azure Arc ゲートウェイ エンドポイントの TLS 検査をスキップします。
Azure Arc ゲートウェイを介してアクセスできるエンドポイント
Arc Gateway では、一連のエンドポイントを使用して、すべての Arc フィーチャがシームレスに機能できるようにします。 現在、このセットには 200 を超えるエンドポイントが含まれています。これは、サポートされているすべての機能の累積要件を表します。 完全な一覧については、 Azure Arc ゲートウェイ エンドポイントに関するページを参照してください。
一部のエンドポイントでは、ワイルドカードを使用して接続を簡略化し、機能カバレッジを確保します。 これらのエンドポイントをネットワーク セキュリティ チームで確認し、組織のポリシーと一致していることを確認することをお勧めします。 これらのエンドポイントは、Arc サービスの安全で信頼性の高い操作に不可欠です。