Azure Kubernetes Service (AKS) でのネットワーク接続とセキュリティに関するベストプラクティス

[アーティクル]
08/02/2024

Azure Kubernetes Service (AKS) のクラスターを作成および管理する際には、ノードおよびアプリケーションに対するネットワーク接続を提供します。これらのネットワークリソースには、IP アドレス範囲、ロードバランサー、およびイングレスコントローラーが含まれます。

このベストプラクティスの記事では、クラスターオペレーター向けのネットワーク接続とセキュリティに焦点を当てます。この記事では、次のことについて説明します。

AKS の kubenet と Azure Container Networking Interface (CNI) のネットワークモードを比較します。
必要な IP アドレス指定と接続を計画します。
ロードバランサー、イングレスコントローラー、または Web アプリケーションファイアウォール (WAF) を使用してトラフィックを分散します。
クラスターノードへ安全に接続します。

適切なネットワークモデルを選択する

ベストプラクティスのガイダンス

AKS で Azure CNI ネットワークを使用すると、既存の仮想ネットワークまたはオンプレミスのネットワークと統合できます。このネットワークモデルでは、エンタープライズ環境でのリソースとコントロールをさらに分離することもできます。

仮想ネットワークは、AKS ノードおよび顧客がアプリケーションにアクセスするための基本的な接続を提供します。仮想ネットワークに AKS クラスターをデプロイするには、次の 2 つの異なる方法があります。

Azure CNI ネットワーク: 仮想ネットワーク内へのデプロイを行い、Azure CNI Kubernetes プラグインを使用します。ポッドは、他のネットワークサービスまたはオンプレミスリソースにルーティングできる個々の IP を受け取ります。
Kubenet ネットワーク: クラスターがデプロイされ、kubenet Kubernetes プラグインを使用する場合に、Azure が仮想ネットワークリソースを管理します。

Azure CNI と kubenet はどちらも、運用環境デプロイに有効なオプションです。

CNI ネットワーク

Azure CNI は、コンテナーランタイムがネットワークプロバイダーに要求を行えるようにする、ベンダー中立のプロトコルです。これはポッドとノードに IP アドレスを割り当て、既存の Azure 仮想ネットワークに接続する際に IP アドレス管理 (IPAM) 機能を提供します。ノードとポッドリソースのそれぞれが Azure 仮想ネットワーク内の IP アドレスを取得します。他のリソースやサービスと通信するための追加のルーティングは必要ありません。

各ブリッジが 1 つの Azure VNet に接続している 2 つのノードを示す図

特に、運用向け Azure CNI ネットワークでは、リソースの制御と管理を分離できます。セキュリティの観点から、多くの場合に、それらのリソースを異なるチームが管理し、セキュリティで保護することが望まれます。 Azure CNI ネットワークを使用すると、各ポッドに割り当てられた IP アドレスを介して、既存の Azure リソース、オンプレミスのリソース、またはその他のサービスに直接接続できます。

Azure CNI ネットワークを使用する場合、仮想ネットワークリソースは AKS クラスターとは別個のリソースグループに含まれます。これらのリソースにアクセスして管理するためのアクセス許可を AKS クラスター ID に委任します。 AKS クラスターで使用されるクラスター ID には、少なくとも、ご利用の仮想ネットワーク内のサブネットに対するネットワーク共同作成者のクセス許可が必要です。

組み込みのネットワークの共同作成者ロールを使用する代わりに、カスタムロールを定義する場合は、次のアクセス許可が必要です。

Microsoft.Network/virtualNetworks/subnets/join/action
Microsoft.Network/virtualNetworks/subnets/read

既定では、AKS はクラスター ID にマネージド ID を使用します。ただし、代わりにサービスプリンシパルを使用できます。

AKS サービスプリンシパルへの委任の詳細については、他の Azure リソースへのアクセスの委任に関するページを参照してください。
マネージド ID の詳細については、マネージド ID の使用に関するページを参照してください。

各ノードとポッドは独自の IP アドレスを受け取るため、AKS サブネットのアドレス範囲を計画します。次の基準を留意してください。

サブネットは、デプロイするすべてのノード、ポッド、およびネットワークリソースの IP アドレスを提供するのに十分な大きさである必要があります。
- kubenet と Azure CNI ネットワークの両方で、実行する各ノードには、ポッドの数について既定の制限があります。
既存のネットワークリソースと重複する IP アドレス範囲は使用しないでください。
- オンプレミスまたは Azure 内のピアリングされたネットワークへの接続を許可することが必要です。
スケールアウトイベントまたはクラスターアップグレードを処理するには、割り当てられたサブネットで使用できる追加の IP アドレスが必要です。
- Windows Server コンテナーを使用している場合、この追加のアドレス空間は特に重要です。これらのノードプールをアップグレードして最新のセキュリティパッチを適用する必要があるためです。 Windows Server ノードの詳細については、AKS でのノードプールのアップグレードに関する記事を参照してください。

必要な IP アドレスを計算するには、AKS での Azure CNI ネットワークの構成に関するページを参照してください。

Azure CNI ネットワークを使用してクラスターを作成する場合は、Docker ブリッジアドレス、DNS サービス IP、サービスアドレス範囲など、クラスターで使用する他のアドレス範囲を指定します。一般に、これらのアドレス範囲がお互い同士で、あるいはクラスターと関連付けられた何らかのネットワーク (仮想ネットワーク、サブネット、オンプレミス、ピアリングされたネットワークなど) と重複しないように注意してください。

これらのアドレス範囲の制限とサイズ設定の詳細については、AKS での Azure CNI ネットワークの構成に関するページを参照してください。

Kubenet ネットワーク

kubenet では、クラスターをデプロイする前に仮想ネットワークを構成する必要はありませんが、後にすることには次のような欠点があります。

ノードとポッドは異なる IP サブネットに配置されるため、ユーザー定義ルーティング (UDR) と IP 転送はポッドとノード間のトラフィックをルーティングします。この追加のルーティングにより、ネットワークパフォーマンスが低下する場合があります。
既存のオンプレミスのネットワークへの接続または他の Azure 仮想ネットワークへのピアリングが複雑である可能性があります。

仮想ネットワークとサブネットを AKS クラスターと別に作成しないため、kubenet は次のようなシナリオに対して最適です。

小規模な開発またはテストのワークロード。
トラフィックが少ない単純な Web サイト。
ワークロードのコンテナーへのリフトアンドシフト。

運用環境のデプロイでは、kubenet と Azure CNI の両方が有効なオプションです。制御と管理の分離を必要とする環境では、Azure CNI の選択が推奨されることがあります。さらに、kubenet は、IP アドレス範囲の保護が優先される Linux 専用環境に適しています。

kubenet を使用して独自の IP アドレス範囲と仮想ネットワークを構成することもできます。 Azure CNI ネットワークと同様に、これらのアドレス範囲はお互い同士で、あるいはクラスターと関連付けられた何らかのネットワーク (仮想ネットワーク、サブネット、オンプレミス、ピアリングされたネットワークなど) と重複してはいけません。

これらのアドレス範囲の制限とサイズ設定の詳細については、AKS の独自の IP アドレス範囲での kubenet ネットワークの使用に関するページを参照してください。

イングレストラフィックを分散する

ベストプラクティスのガイダンス

HTTP または HTTPS トラフィックをアプリケーションに分散するには、イングレスリソースとコントローラーを使用します。 Azure ロードバランサーと比較すると、イングレスコントローラーでは追加機能が提供されており、ネイティブの Kubernetes リソースとして管理できます。

Azure ロードバランサーを使用すると顧客のトラフィックを AKS クラスター内のアプリケーションに分散できますが、そのトラフィックを理解するには限界があります。ロードバランサーリソースは "レイヤー 4" で動作し、プロトコルまたはポートに基づいてトラフィックを分配します。

HTTP または HTTPS を使用するほとんどの Web アプリケーションでは、"レイヤー 7" で動作する Kubernetes イングレスリソースとコントローラーを使用する必要があります。イングレスは、アプリケーションの URL に基づいてトラフィックを分散し、TLS/SSL ターミネーションを処理することができます。イングレスでは、公開してマップする IP アドレスの数も減少します。

ロードバランサーでは、通常、各アプリケーションのパブリック IP アドレスが AKS クラスター内のサービスに割り当てられてマップされている必要があります。イングレスリソースでは、単一の IP アドレスが複数のアプリケーションにトラフィックを分散できます。

AKS クラスターでのイングレストラフィックフローを示す図

イングレスには、次の 2 つのコンポーネントがあります。

イングレス リソース
イングレス コントローラー

イングレスリソース

イングレスリソースは、kind: Ingress の YAML マニフェストです。これは、AKS クラスターで実行するサービスに対してトラフィックをルーティングするためのホスト、証明書、およびルールを定義します。

次の例の YAML マニフェストは、myapp.com のトラフィックを blogservice または storeservice という 2 つのサービスのいずれかに分配し、利用者をアクセスする URL に基づいてどちらか一方のサービスに誘導します。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
 name: myapp-ingress
spec:
 ingressClassName: PublicIngress
 tls:
 - hosts:
   - myapp.com
   secretName: myapp-secret
 rules:
   - host: myapp.com
     http:
      paths:
      - path: /blog
        backend:
         service:
           name: blogservice
           port: 80
      - path: /store
        backend:
         service:
           name: storeservice
           port: 80

イングレスコントローラー

イングレスコントローラーは AKS ノードで実行され、着信要求を監視するデーモンです。その後、トラフィックは、イングレスリソースで定義されたルールに基づいて分散されます。最も一般的なイングレスコントローラーは NGINX に基づいていますが、AKS では特定のコントローラーに制限していません。 Contour、HAProxy、Traefik などを使用できます。

イングレスコントローラーは Linux ノード上でスケジュールする必要があります。 YAML マニフェストまたは Helm グラフのデプロイでノードセレクターを使用して、リソースが Linux ベースのノード上で実行されるように指定します。詳細については、ノードセレクターを使用して AKS でポッドをスケジュールする場所を制御する方法に関する記事を参照してください。

アプリケーションルーティングアドオンを使用したイングレス

アプリケーションルーティングアドオンは、AKS でイングレスコントローラーを構成するために推奨される方法です。アプリケーションルーティングアドオンは、次の機能を提供する Azure Kubernetes Service (AKS) 用のフルマネージド型のイングレスコントローラーです。

Kubernetes NGINX イングレスコントローラーに基づくマネージド NGINX イングレスコントローラーの簡単な構成。
パブリックゾーンとプライベートゾーンの管理のための Azure DNS との統合。
Azure Key Vault に格納されている証明書での SSL 終端。

アプリケーションルーティングアドオンの詳細については、「アプリケーションルーティングアドオンを使用したマネージド NGINX イングレス」をご覧ください。

Web アプリケーションファイアウォール (WAF) を使用してトラフィックをセキュリティで保護する

ベストプラクティスのガイダンス

着信トラフィックをスキャンして潜在的な攻撃を検出するには、Barracuda WAF for Azure や Azure Application Gateway などの Web アプリケーションファイアウォール (WAF) を使用します。また、より高度なこれらのネットワークリソースは、単なる HTTP 接続や HTTPS 接続または基本的な TLS ターミネーション以外でもトラフィックをルーティングできます。

通常、イングレスコントローラーは、トラフィックをサービスやアプリケーションに分散する、AKS クラスター内の Kubernetes リソースです。このコントローラーは AKS ノード上でデーモンとして実行され、CPU、メモリ、ネットワーク帯域幅など、ノードのリソースの一部を消費します。より大規模な環境では、次のことを考慮すべき場合があります。

このトラフィックのルーティングまたは TLS 終端の一部を、AKS クラスター外のネットワークリソースにオフロードします。
着信トラフィックをスキャンして潜在的な攻撃を検出します。

Azure App Gateway などの Web アプリケーションファイアウォール (WAF) は、AKS クラスターのトラフィックを保護および分散することができます

この追加のセキュリティ層では、Web アプリケーションファイアウォール (WAF) によって着信トラフィックのフィルター処理が行われます。 Open Web Application Security Project (OWASP) では、一連のルールを使用して、クロスサイトスクリプティングや Cookie ポイズニングなどの攻撃を監視します。 Azure Application Gateway (現在 AKS でプレビュー中) は AKS クラスターと統合する WAF で、トラフィックが AKS クラスターとアプリケーションに到達する前にこれらのセキュリティ機能をロックします。

これらの機能は他のサードパーティ製ソリューションでも実行されるため、既存の投資や専門知識を希望する製品で引き続き使用できます。

ロードバランサーまたはイングレスリソースは、AKS クラスターで継続的に実行され、トラフィックの分散を調整します。 App Gateway は、リソース定義でイングレスコントローラーとして一元的に管理できます。最初に、Application Gateway イングレスコントローラーを作成します。

ネットワークポリシーを使用してトラフィックフローを制御する

ベストプラクティスのガイダンス

ネットワークポリシーを使用して、ポッドへのトラフィックを許可または拒否します。既定では、1 つのクラスター内でポッド間のすべてのトラフィックが許可されます。セキュリティを強化するには、ポッドの通信を制限するルールを定義します。

ネットワークポリシーは、ポッド間のトラフィックフローを制御できる、AKS で使用可能な Kubernetes の機能です。ユーザーは、割り当てられたラベル、名前空間、トラフィックポートなどの設定に基づいて、トラフィックを許可または拒否します。トラフィックのフローを制御するには、ネットワークポリシーを使用するのがクラウドネイティブな方法です。ポッドは AKS クラスター内で動的に作成されるため、必要なネットワークポリシーを自動的に適用できます。

ネットワークポリシーを使用するには、新しい AKS クラスターの作成時にこの機能を有効にします。既存の AKS クラスターでネットワークポリシーを有効にすることはできません。必要なクラスターでネットワークポリシーを有効にすることを事前に計画してください。

Note

ネットワークポリシーは、AKS の Linux ベースのノードとポッドに対してのみ使用する必要があります。

ネットワークポリシーは、YAML マニフェストを使用して Kubernetes リソースとして作成します。ポリシーは、トラフィックフローを定義するイングレスルールまたはエグレスルールを使用して、定義されたポッドに適用されます。

次の例では、app: backend ラベルが適用されたポッドにネットワークポリシーを適用します。イングレスルールでは、app: frontend ラベルのあるポッドからのトラフィックのみを許可します。

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

ポリシーの概要については、「SAzure Kubernetes Service (AKS) のネットワークポリシーを使用したポッド間のトラフィックの保護」を参照してください。

踏み台ホストを介してノードに安全に接続する

ベストプラクティスのガイダンス

AKS ノードへのリモート接続は公開しないでください。管理仮想ネットワーク内に踏み台ホスト (jump box) を作成します。踏み台ホストを使用すると、AKS クラスターへのトラフィックをリモート管理タスクに安全にルーティングできます。

AKS のほとんどの操作は、Azure 管理ツールを使用するか、Kubernetes API サーバー経由で完了できます。 AKS ノードはプライベートネットワークでのみ使用でき、パブリックインターネットには接続されません。ノードに接続してメンテナンスとサポートを提供するには、bastion ホストまたはジャンプボックスを介して接続をルーティングします。このホストが、AKS クラスターの仮想ネットワークとは別の安全にピアリングされた管理仮想ネットワークに存在することを確認します。

踏み台ホスト (jump box) を使用して AKS ノードに接続する

bastion ホストの管理ネットワークをセキュリティで保護する必要もあります。 Azure ExpressRoute または VPN ゲートウェイを使用してオンプレミスネットワークに接続し、ネットワークセキュリティグループを使用してアクセスを制御します。

次のステップ

この記事では、ネットワーク接続およびセキュリティに焦点を当てました。 Kubernetes におけるネットワークの基礎の詳細については、「Azure Kubernetes Service (AKS) でのアプリケーションに対するネットワークの概念」を参照してください。

次の方法で共有

Azure Kubernetes Service (AKS) でのネットワーク接続とセキュリティに関するベストプラクティス