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

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

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

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

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

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

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

• Azure CNI ネットワーク: 仮想ネットワークにデプロイし、Azure CNI Kubernetes プラグインを使用します。 ポッドは、他のネットワーク サービスまたはオンプレミス リソースにルーティングできる個々の IP を受け取ります。

Azure CNI は、運用環境のデプロイに有効なオプションです。

CNI ネットワーク

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

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

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

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

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

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

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

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

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

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

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

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

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

1. イングレス リソース
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 では特定のコントローラーに制限していません。 Application Gateway は、コンテナー、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) を使用してトラフィックをセキュリティで保護する

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

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

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

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

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

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

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

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

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

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

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

AKS でネットワーク ポリシーを使用するには、クラスターの作成時または既存の AKS クラスターでこの機能を有効にすることができます。 ネットワーク ポリシーを使用する予定の場合は、AKS クラスターで機能が有効になっていることを確認します。

ネットワーク ポリシーは、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 解決を最適化する

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

AKS ノード プールで LocalDNS を有効にして、DNS のパフォーマンス、信頼性を向上させ、集中型 CoreDNS ポッドの負荷を軽減します。

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

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

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

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

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

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

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

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

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

次のステップ

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