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

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

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

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

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

ほとんどのシナリオAzure CNI オーバーレイを使用します。 ワークロードで接続されたネットワークからの直接ポッド IP アクセスが必要な場合は、CNI ポッド サブネットAzureフラット ネットワークを使用します。

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

• オーバーレイ ネットワーク: Azure CNI オーバーレイは、ポッドの IP アドレスを別のポッド CIDR から割り当てます。 クラスターを離れるトラフィックはノードの IP アドレスに変換され、ポッドは接続されたネットワークからプライベート IP アドレスから直接アクセスすることはできません。
• フラット ネットワーク: Azure CNI ポッド サブネットまたはレガシ Azure CNI ノード サブネットは、仮想ネットワーク空間からポッド IP アドレスを割り当てます。 ポッドには、接続されたネットワークからのプライベート IP アドレスでアクセスできます。

ネットワーク モデルの選択の詳細については、「 AKS のポッド ネットワークを計画する」を参照してください。

Azure CNI ネットワークの概要

Azure CNI は、ポッドとノードの IP アドレス管理 (IPAM) と接続性を提供します。 IPAM オプションは、ネットワーク データ プレーンとは別です。 たとえば、Azure CNI オーバーレイまたはフラット ネットワーク オプションで Cilium を搭載した Azure CNI を使用できます。

次の図は、2 つの AKS ノードを示しています。それぞれがネットワーク ブリッジを介して共有Azure仮想ネットワークに接続されています。

Azure CNI ネットワークを使用すると、リソースの制御と管理を分離できます。 セキュリティの観点から、多くの場合に、それらのリソースを異なるチームが管理し、セキュリティで保護することが望まれます。 接続特性は、ネットワーク モデルによって異なります。 オーバーレイ ポッドは、ノード IP アドレスを介して仮想ネットワークとオンプレミス リソースへの接続を開始します。 フラット ネットワーク ポッドは、プライベート IP アドレスを介して接続されたリソースと直接通信できます。

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

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

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

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

ネットワーク モデルに基づいてアドレス範囲を計画します。 次の基準を留意してください。

• Azure CNI オーバーレイを使用して、ノードのノード サブネットのサイズを変更し、ポッドに個別のプライベート CIDR を使用します。 各ノードは、ポッド CIDR から /24 アドレス空間を受け取ります。
• フラット ネットワークでは、ノードとポッドの両方の仮想ネットワーク サブネットのサイズを設定します。 Azure CNI ポッド サブネットでは個別のノードサブネットとポッドサブネットが使用されますが、レガシ Azure CNI ノード サブネットでは両方に 1 つのサブネットが使用されます。
• 既存のネットワーク リソースと重複する IP アドレス範囲は使用しないでください。
  • Azure内のオンプレミスまたはピアリングされたネットワークへの接続を許可する必要があります。
• スケールアウト イベントまたはクラスターのアップグレードを処理するには、割り当てられたサブネットで使用可能な追加の IP アドレスが必要です。
  • この追加のアドレス空間は、Windows Serverコンテナーを使用する場合に特に重要です。これらのノード プールでは、最新のセキュリティ パッチを適用するためのアップグレードが必要です。 Windows Server ノードの詳細については、「 AKS でのノード プールのアップグレードを参照してください。

必要な IP アドレス空間を計算するには、 AKS クラスターの IP アドレス計画を参照してください。

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

ネットワーク モデル、制限、およびアドレスのサイズ設定の詳細については、「Azure CNI ネットワークの概要」を参照してください。

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

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

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

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

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

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

この図は、外部トラフィックを受信する 1 つのパブリック IP アドレスと、そのトラフィックを AKS クラスター内の複数のサービスに分散するイングレス コントローラーを示しています。

イングレスには、イングレス リソース とイングレス コントローラーという 2 つのコンポーネントがあります。

イングレス リソース

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

次の YAML マニフェストの例では、アプリケーション ルーティング アドオンのマネージド NGINX イングレス クラスを使用します。 myapp.com のトラフィックは、blogservice または storeservice という 2 つのサービスのいずれかに分散され、アクセスする URL に基づいて顧客を 1 つのサービスまたはもう一方のサービスに転送します。

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

ingressClassName フィールドはイングレス クラスを選択し、クラスター内のイングレス コントローラーで構成されたクラスと一致する必要があります。 webapprouting.kubernetes.azure.com値は、アプリケーション ルーティング アドオンによって提供されるマネージド NGINX イングレス コントローラーを選択します。 別の実装を使用する場合は、それをイングレス コントローラーのクラス名に置き換えます。

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

クラスターでホストされる イングレス コントローラー は、AKS ノードでワークロードとして実行され、受信要求を監視します。 その後、着信トラフィックは、そのコントローラーに関連付けられているイングレス リソースで定義されている規則に基づいて分散されます。 最も一般的なイングレス コントローラーは NGINX に基づいていますが、AKS では特定のコントローラーに制限していません。 Application Gateway は、コンテナー、Contour、HAProxy、Traefik などに使用できます。

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

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

アプリケーション ルーティング アドオンは、AKS のマネージド イングレス実装を提供します。 有効期間が長い新しいデプロイの場合は、要件をサポートするときに、アプリケーション ルーティング ゲートウェイ API の実装を使用します。 ゲートウェイ API は、Kubernetes イングレスおよびレイヤー 7 トラフィック管理の長期的な標準です。

マネージド NGINX 実装には、次の機能があります。

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

詳細については、「 アプリケーション ルーティング ゲートウェイ API を使用したイングレスの構成」および「アプリケーション ルーティングアドオンを使用したマネージド NGINX イングレスの構成」を参照してください。

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

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

着信トラフィックで潜在的な攻撃をスキャンするには、Web アプリケーション ファイアウォール (WAF) (Barracuda WAF for Azureや Application Gateway for Containers でのAzure Web Application Firewallなど) を使用します。 Application Gateway for Containers は、HTTP、HTTPS、gRPC、WebSocket、AI 推論トラフィックをルーティングし、TLS 終了をサポートします。

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

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

この図は、Azure Application Gateway for Containers を通過する外部トラフィックを示しています。 WAF 保護を構成すると、許可されたトラフィックが AKS クラスター内のサービスに転送される前に、WAF ルールによって要求がフィルター処理されます。

そのセキュリティ層を強化するために、Web アプリケーション ファイアウォール (WAF) によって受信トラフィックがフィルター処理されます。 マネージド ルールとカスタム ルールは、クロスサイト スクリプティングや SQL インジェクションなどの攻撃から保護します。 Application Gateway for Containers は、Azure WAF をサポートするレイヤー 7 の負荷分散およびトラフィック管理サービスです。

Application Gateway for Containers を単独でデプロイすると、WAF 保護は有効になりません。 WAF がトラフィックを検査する前に、WAF ポリシーを作成し、次の両方の構成を完了する必要があります。

• WAF ポリシーを参照するAzure SecurityPolicy子リソースを作成します。
• 同じ WAF ポリシーを参照し、保護対象の HTTPRoute または WebApplicationFirewallPolicy リソースを指定する Kubernetes Gateway カスタム リソースを適用します。

両方の構成を完了したら、保護のポリシーに依存する前に、カスタム リソースの状態と WAF ログを確認します。 詳細については、「Application Gateway for Containers のAzure Web Application Firewall」を参照してください。

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

ロード バランサーまたはイングレス リソースは、AKS クラスターで継続的に実行され、トラフィックの分散を調整します。 Azure Application Gateway for Containers は、リソース定義を使用してイングレス コントローラーとして一元的に管理できます。 開始するには、 コンテナー用の Application Gateway を作成し、WAF 保護を個別に構成します。

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

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

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

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

AKS でネットワーク ポリシーを使用するには、ノード オペレーティング システムとネットワーク データ プレーンをサポートするネットワーク ポリシー エンジンを選択します。 ポリシー エンジンは、クラスターの作成時またはサポートされている既存のクラスターで有効にすることができます。

Linux ノード プールでは、Cilium を利用した Azure CNI と、その組み込みの Cilium ネットワーク ポリシー適用機能を使用します。 cilium は、Windows ノード プールではサポートされていません。 Windowsワークロードの場合は、Calico を使用します。

ネットワーク ポリシーは、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

ポリシーの使用を開始するには、「 Azure Kubernetes Service (AKS) のネットワーク ポリシーを使用してポッド間のトラフィックをセキュリティで保護する」を参照してください。

LocalDNS を使用して DNS 解決を最適化する

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

LocalDNS を使用して、DNS のパフォーマンスと信頼性を向上させ、一元化された CoreDNS ポッドの負荷を軽減します。 LocalDNS は AKS Automatic で事前構成されています。 AKS Standard で、ノード プールごとに LocalDNS を有効にして構成します。

LocalDNS は、DNS クエリをローカルで処理するために、各ノードに DNS プロキシを systemd サービスとしてデプロイします。 既定では、ポッドはすべての DNS クエリを一元化された CoreDNS ポッドに送信します。 大規模に、これらのクエリを一元化するとボトルネックが生じ、ローカル解決によってネットワーク ホップと待機時間が短縮される可能性があります。

LocalDNS では、DNS トラフィック conntrack テーブル エントリも排除されるため、 conntrack テーブルの枯渇や接続の切断の原因となる競合状態を防ぐことができます。 ローカル キャッシュから CoreDNS への接続は TCP にアップグレードされ、接続の再調整と追跡エントリの迅速なクリーンアップが可能になります。

高可用性を必要とするワークロードの場合、LocalDNS では、アップストリーム DNS が使用できないときに、構成可能な期間、古いキャッシュされた応答の提供がサポートされます。 このベスト エフォート機能は、一時的な DNS の停止中にポッドの接続とサービスの信頼性を維持するのに役立ちますが、古いレコードが使用できることを保証するものではありません。

AKS Standard では、既存のノード プールで LocalDNS を有効にすると、そのノードが再イメージ化されます。 この中断を考慮してロールアウトを計画します。

LocalDNS のアーキテクチャと機能の詳細については、 AKS での DNS 解決に関する説明を参照してください。 構成手順については、「 LocalDNS の構成」を参照してください。

ノードに安全に接続する

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

AKS ノードへのリモート接続は公開しないでください。 Linux ノードの日常的なトラブルシューティングを行うには、Kubernetes API を使用して kubectl debug を使用します。 SSH アクセスが必要な場合は、プライベート ネットワークまたはAzure Bastion経由で接続します。

Azure管理ツールまたは Kubernetes API サーバーを使用して、AKS のほとんどの操作を完了できます。 AKS ノードはプライベート ネットワークでのみ使用でき、パブリック インターネットには接続されません。 Linux ノードの場合は、 kubectl debug を使用して、Kubernetes API を使用して特権デバッグ コンテナーを開始します。 この方法では、ノードへの直接 SSH 接続は必要ありません。

Kubernetes API アクセスが適切でない場合、または SSH が必要な場合は、接続されたネットワークからノードのプライベート IP アドレスを使用します。 Azure Bastionは、ノード上のパブリック IP アドレスを公開することなく、プライベート接続を提供できます。 Windows ノードの場合は、ホスト プロセス コンテナーを使用するか、Linux プロキシ ノード経由で接続します。 Azure Bastionは、プロキシ ノードが使用できない場合の代替手段です。 詳細については、「 メンテナンスまたはトラブルシューティングのために AKS クラスター ノードに接続する」を参照してください。

この図は、AKS クラスター仮想ネットワークへの安全にピアリングされたリンクを介して接続をルーティングする要塞ホストを含む管理仮想ネットワークを示しています。

要塞ホストまたはジャンプ ボックスを使用する場合は、安全にピアリングされた別の管理仮想ネットワークに配置します。 Azure ExpressRouteまたは VPN ゲートウェイを使用して管理ネットワークをセキュリティで保護し、オンプレミス ネットワークに接続し、ネットワーク セキュリティ グループを使用してアクセスを制御します。

次のステップ

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