Azure Kubernetes Application Network セキュリティの概要 (プレビュー)

Important

AKS のプレビュー機能は、セルフサービスのオプトイン単位で利用できます。プレビューは、"現状有姿のまま" および "利用可能な限度" で提供され、サービスレベルアグリーメントおよび限定保証から除外されるものとします。 AKS プレビューは、ベストエフォートベースでカスタマーサポートによって部分的にカバーされます。そのため、これらの機能は運用環境での使用を目的としていません。詳細については、次のサポート記事を参照してください。

Azure Kubernetes Application Network は、自動相互 TLS (mTLS) と ID ベースの承認を通じて、接続された Azure Kubernetes Service (AKS) クラスター内のサービス間の通信をセキュリティで保護します。ワークロード ID を発行し、証明書の発行、ローテーション、検証を管理して、暗号化、認証、および明示的に承認されたサービス間通信を、転送中の FIPS 準拠の暗号化を使用して、手動で構成せずに有効にします。

この記事では、mTLS、ワークロード ID、証明書管理、承認ポリシーなど、Azure Kubernetes Application Network のセキュリティ機能の概要について説明します。また、Azure Kubernetes Application Network 環境でセキュリティで保護された通信を実装するための制限事項と次の手順についても説明します。

制限事項

証明書は現在、Azure Kubernetes Application Network マネージド証明機関 (CA) によって発行され、パブリック CA にチェーンされていません。

mTLS

Application Network では、mTLS を使用して、ワークロード間の ID ベースの暗号化された通信を提供します。 Application Network に接続されたクラスター内の各サービスは、その ID を証明し、同じアプリケーションネットワーク内の他のサービスとの信頼された暗号化された接続を確立できる証明書を自動的に受信します。転送中の暗号化では、FIPS 準拠の暗号化が使用されます。

mTLS 移行戦略

現在、Application Network では、暗号化されたトラフィックと暗号化されていないトラフィックの両方が許可されています。この方法により、既存のワークロードは正常に動作し続けますが、新規または更新されたワークロードでは安全な通信に mTLS が自動的に使用されます。つまり、ダウンタイムなしでワークロード間の安全な通信に mTLS を採用できます。移行が完了したら、認証が適用されるように厳密モードに変更できます。

Azure Kubernetes Application Network での mTLS の利点

Azure Kubernetes Application Network の mTLS は、次のことに役立ちます。

転送中のデータを保護する: すべてのサービス間トラフィックを自動的に暗号化できます (FIPS 準拠)。
サービス ID を確認する: 各ワークロードには、一意のアプリケーションネットワークで管理されるルート証明書と中間証明書があります。
操作を簡略化する: Application Network は、ユーザーの証明書の発行、ローテーション、失効を処理します。

証明書の管理

Azure Kubernetes Application Network は、mTLS に使用される証明書を発行して維持する Azure Key Vault によってサポートされる証明書管理を提供します。このサービスは、同じアプリケーションネットワークリソースに接続されているすべての AKS クラスター間で共有信頼境界を確立します。

Application Network は、プロビジョニング、更新、ローテーションなど、ルート証明書と中間証明書の証明書ライフサイクル全体を自動的に管理します。これにより、ワークロード ID が有効なままになり、通信は時間の経過と同時にセキュリティで保護されます。証明書を手動で作成、保存、またはローテーションする必要はありません。

次の図は、Application Network の証明書階層を示しています。ルート CA、中間 CA、およびワークロード証明書が、接続されたクラスター間で信頼を確立するためにどのように構成されているかを示しています。

証明書の階層とライフサイクル

アプリケーションネットワークリソースが作成されると、 ルート CA がプロビジョニングされ、アプリケーションネットワークのトラストアンカーとして機能します。 AKS クラスターが Application Network にメンバーとして参加すると、Application Network は Application Network ルート CA によって署名されたそのメンバーの 中間証明書 を発行します。接続されている各 AKS クラスターは、アプリケーションネットワークで管理される中間証明書を使用して、そのクラスター内のワークロードに有効期間の短い ワークロード証明書 を発行します。

すべてのワークロード証明書は、Application Network ルート CA から信頼を継承し、リソース全体で統合された信頼境界を維持します。ルート証明書と中間証明書のローテーションは、ダウンタイムやトラフィックの中断を引き起こすことなく、ユーザーに対して透過的に処理されます。このマネージド階層により、アプリケーションネットワーク内のすべてのクラスターで一貫性のある検証可能な信頼が確保され、各証明書の有効性が自動的に維持されます。

任意のメンバークラスターから、名前空間istio-root-certの下にある構成マップ applink-systemからルート CA 証明書を取得できます。

証明書の種類とローテーション期間

証明書の種類	Scope	有効期間	回転期間	Purpose
ルート CA	Azure Kubernetes Application Network	12 か月	6 か月	Azure Kubernetes Application Network に接続されているすべてのクラスターの信頼境界を確立します
中間認証局	クラスター	90 日間	45 日	そのクラスター内のワークロードのワークロード証明書を発行する
ワークロード証明書	Workload	24 時間	12 時間	ワークロードを認証し、サービス間通信をセキュリティで保護します

ワークロード ID と承認

アプリケーションが拡大するにつれて、多くの場合、サービスは同じデプロイ内のさまざまな名前空間と環境間で安全に通信する必要があります。証明書を管理し、各サービスが通信相手を確認できることを確認すると、すぐに複雑になり、エラーが発生しやすくなります。 Azure Kubernetes Application Network では、ワークロード ID を自動的に割り当てて管理することで、このオーバーヘッドを排除します。

アプリケーションネットワークに接続された環境内では、ワークロードは名前空間内および名前空間間で安全に通信します。各サービスを信頼して認証できるようにするために、Application Network はすべてのワークロードに、その名前空間とサービスアカウントを表す 検証可能な ID を 割り当てます。

各 Application Network ワークロードは、その名前空間とサービスアカウントを含む SPIFFE 形式の一意の ID を自動的に受け取ります。 ID は次のように書式設定されます。

spiffe://cluster.local/ns/<namespace>/sa/<service-account>

この ID はワークロード証明書に埋め込まれており、他のワークロードと通信するときにサービスの ID を証明するために使用されます。 Azure Kubernetes Application Network では、Istio 承認ポリシーを使用してこの SPIFFE ベースの ID モデルを使用するため、通信が許可されるサービスに対して明確で一貫性のある規則を定義できます。

アクセスポリシーを定義する

Istio AuthorizationPolicies を使用して、環境内で通信を許可するワークロードを制御できます。これらのポリシーを使用すると、ネットワークの場所や IP アドレスではなく、検証済みのワークロード ID に基づいてアクセスを定義できます。このアプローチは、サービスがスケーリングされてノード間を移動する場合でも、一貫したアクセス制御を適用するのに役立ちます。たとえば、次の例に示すように、ポリシーのプリンシパルリストで SPIFFE ID を参照することで、信頼できる名前空間の特定のゲートウェイまたはワークロードのみがサービスを呼び出せるようにすることができます。

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: allow-gateway-to-app
  namespace: default
spec:
  selector:
    matchLabels:
      app: myApp
  action: ALLOW
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/default/sa/myApp-gateway // see SPIFFE format above

ポリシー設計ガイダンス

承認ポリシーを設計するときは、次のベストプラクティスに留意してください。

意図しない名前空間間アクセスを防ぐために、常に名前空間とサービスアカウントの両方を指定します。
プリンシパルを使用して、きめ細かなアクセスのための明示的なワークロード ID を定義します。
名前空間を使用して、必要に応じてより広範な信頼境界を定義します。
名前空間のないサービスアカウント名のみに一致する規則は避けてください。これにより、クラスターまたは環境間でアクセスが許可される可能性があるためです。
AuthorizationPoliciesと Kubernetes NetworkPoliciesを組み合わせて、ID ベースとネットワークベースの両方の分離を適用します。

注

Azure Kubernetes Application Network の承認は、IP アドレスではなく、検証済みのワークロード ID に基づいています。これにより、ワークロードがスケーリングまたはノード間で移動する場合でも、一貫した適用が保証されます。

Azure Kubernetes Application Network マネージド ID、証明書、ポリシー制御を組み合わせることで、ID ベースの最小特権サービス通信を実装し、クラスター間のワークロード間で認証、暗号化、および明示的に承認されたトラフィックを確保できます。

Azure Kubernetes Application Network の詳細については、次の記事を参照してください。

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-03-23