コンテナー のセキュリティにより、エンド ツー エンドのパイプライン全体がビルドから、Azure Kubernetes Service (AKS)で実行されているアプリケーション ワークロードまで保護されます。
セキュリティで保護されたサプライ チェーンには、ビルド環境とレジストリが含まれます。
Kubernetes には、ポッド セキュリティ標準やシークレットなどのセキュリティ コンポーネントが含まれています。 Azureには、Microsoft Entra ID、コンテナーのMicrosoft Defender、Azure Policy、Azure Key Vault、ネットワーク セキュリティ グループ、調整されたクラスターのアップグレードなどのコンポーネントが含まれます。 AKS は、これらのセキュリティ コンポーネントを組み合わせて以下を実現します。
- 完全な認証と認可のストーリーを提供します。
- AKS 組み込みAzure Policyを適用して、アプリケーションをセキュリティで保護します。
- Microsoft Defender for Containers を使用して、アプリケーションを通じてビルドからエンド ツー エンドの分析情報を得ることができます。
- AKS クラスターで常に最新の OS セキュリティ更新プログラムと Kubernetes リリースが実行されるようにします。
- セキュリティで保護されたポッド トラフィックと、機密性の高い資格情報へのアクセスを提供します。
AKS では、 AKS Automatic と AKS Standard の 2 つのクラスター モードがサポートされています。 この記事のセキュリティの概念は、特に明記されていない限り、両方のモードに適用されます。 AKS Automatic にはセキュリティ ベースラインが強化されており、いくつかのコントロールが既定で事前に構成されていますが、AKS Standard では構成の柔軟性が向上します。
この記事では、AKS 内でアプリケーションをセキュリティで保護する主要な概念について説明します。
Important
セキュリティの構築
ビルド セキュリティは、セキュリティで保護されたサプライ チェーンのエントリ ポイントです。 イメージがデプロイ環境に昇格される前に、CI で静的分析と脆弱性とコンプライアンス評価を実行します。
どちらの AKS モードでも、脆弱性に基づいてすべてのビルドをブロックするのではなく、リスクベースのトリアージを使用します。 ベンダーの状態と重大度を使用して修復に優先順位を付け、悪用できない例外または期限付き例外に猶予期間を適用します。
AKS Automatic は、構成済みのセキュリティ制御を使用して強化されたベースラインからクラスターを開始することで、ダウンストリーム構成の誤差を軽減するのに役立ちます。 これにより、信頼性の高いイメージがより一貫してセキュリティで保護されたランタイム ベースラインに昇格されるため、イメージ品質とポリシー コンプライアンスのビルド時検証がさらに重要になります。
AKS Standard ではクラスター レベルの柔軟性が向上するため、ビルド パイプラインでは、デプロイ前に、イメージの実証、脆弱性のしきい値、ポリシー ゲートに対して組織のベースラインを明示的に適用する必要があります。
レジストリのセキュリティ
レジストリ セキュリティは、信頼でき、コンプライアンス要件を満たすイメージのみがデプロイ可能であることを確認し、ビルド後のドリフトの検出に役立ちます。 ビルド時だけでなく、レジストリのイメージの脆弱性の状態を継続的に評価します。 レジストリ スキャンは、承認されたビルド パスをバイパスした、新しく開示された脆弱性とイメージをキャッチします。 イメージの署名と検証 ( Notary V2 など) を使用して、検証可能な実績のある信頼されたソースからワークロードが確実にデプロイされるようにします。
複数のランタイム セキュリティ機能が事前に構成されている AKS Automatic の場合、レジストリ制御はランタイム サプライ チェーンをクリーンに保つために重要なアップストリーム ゲートのままです。 AKS Standard の場合は、同じレジストリ コントロールを適用し、クラスターのアドミッションとポリシー構成に合わせて、信頼されたイメージの使用を一貫して適用します。
クラスターのセキュリティ
AKS では、Kubernetes のプライマリ コンポーネントは、Microsoftによって提供、管理、および管理されるマネージド サービスの一部です。 各 AKS クラスターには、API Server や Scheduler などを提供するための、独自のシングルテナント専用 Kubernetes プライマリがあります。詳細については、「Azure Kubernetes Service の
既定では、Kubernetes API サーバーは、パブリック IP アドレスと完全修飾ドメイン名 (FQDN) を使用します。 許可された IP 範囲を使用して、API サーバー エンドポイントへのアクセスを制限できます。 また、フル プライベート クラスターを作成して、API サーバーから仮想ネットワークへのアクセスを制限することもできます。
AKS 自動の場合、API サーバー仮想ネットワーク統合は、既定のセキュリティ体制の一部として事前構成されています。 AKS Standard では、同じ機能を使用でき、ネットワークの設計とセキュリティの要件に基づいて有効にすることができます。
Kubernetes ロールベースのアクセス制御 (Kubernetes RBAC) と Azure RBAC を使用して、API サーバーへのアクセスを制御できます。 AKS 自動では、Kubernetes 承認のAzure RBAC が事前構成されています。 AKS Standard では、環境に最適な承認モデルを選択して構成できます。 詳細については、Microsoft Entra AKS との統合に関する説明を参照してください。
AKS 自動セキュリティの既定設定
AKS Automatic には、セキュリティ コントロールが既定で事前に構成された強化されたベースラインが含まれています。これには、次のものが含まれます。
- Azure の Kubernetes 認可のための RBAC
- API サーバーの仮想ネットワーク統合
- ワークロード ID と OIDC 発行元
- デプロイセーフガードとベースラインポッドセキュリティ標準(強制モード)
- 未使用の脆弱な画像を削除するためのイメージ クリーナー
- お客様のワークロードと AKS で管理されるインフラストラクチャの間の境界を保持するマネージド システム ノード プールのセキュリティ制限
AKS Standard では、実装の柔軟性が高いこれらの機能がサポートされていますが、明示的な有効化と運用管理が必要になる場合があります。
ノードのセキュリティ
AKS ノードは Azure 仮想マシン (VM) です。 AKS Standard では、ノード プールの構成とライフサイクル のオプションを管理します。 AKS Automatic では、AKS は、マネージド システム インフラストラクチャのセキュリティ制限を使用して、スケーリングやアップグレードなど、ユーザーに代わってシステム ノード プールとコア システム コンポーネントを管理します。
Linux ノードは、最適化されたバージョンの Ubuntu または Azure Linux を実行します。 Windows Serverノードは、containerd コンテナー ランタイムを使用して最適化されたWindows Server リリースを実行します。
AKS クラスターを作成またはスケールアップすると、ノードは自動的に、最新の OS セキュリティ更新プログラムと構成でデプロイされます。
注意
以下を実行する AKS クラスター:
- Kubernetes バージョン 1.19 以降: Linux ノード プールでは、コンテナー ランタイムとして
containerdが使用されます。 Windows Server 2019ノード プールとWindows Server 2022 ノード プールでは、コンテナー ランタイムとしてcontainerdが使用されます。 詳細については、containerdを使用してWindows Serverノードプールを追加する方法を参照してください。 - Kubernetes バージョン 1.19 以前: Linux ノード プールでは、コンテナー ランタイムとして Docker が使用されます。
Linux ノードと Windows ワーカー ノードのセキュリティ アップグレード プロセスの詳細については、「Security patching nodes」を参照してください。
第 2 世代 VM Azure実行されている AKS クラスターには、Trusted Launch のサポートが含まれています。 この機能は、セキュア ブートや、信頼されたプラットフォーム モジュール (vTPM) の仮想化バージョンなど、個別に有効にできるテクノロジを組み合わせることによって、高度で永続的な攻撃手法から保護します。 管理者は、検証済みおよび署名済みのブートローダー、OS カーネル、ドライバーを含む AKS ワーカー ノードをデプロイし、基になる VM のブート チェーン全体の整合性を確保できます。
コンテナーとセキュリティに最適化された OS オプション
Azure Container Linux (ACL) は、AKS 用の不変のコンテナー最適化 OS です。 ACL は Flatcar Container Linux プロジェクトから派生しており、Flatcar の実績あるコンテナーファーストのイミュータブルな設計を基盤としつつ、その上に Azure Linux のパッケージ、保守、プラットフォーム統合を組み合わせています。 これにより、ACL は、Azureの運用環境、セキュリティ、コンプライアンスの要件を満たしながら、アップストリームの Flatcar イノベーションと密接に連携することができます。 Flatcar Container Linux の詳細については、 Flatcar のドキュメントを参照してください。
ACL は、AKS v1.34 以降の AKS で OS オプションとして一般公開 (GA) されています。 新しい AKS クラスターに ACL ノード プールをデプロイし、既存のクラスターに ACL ノード プールを追加し、既存の Linux ノード プールを ACL に移行できます。
ACL の詳細については、「Azure Container Linux (ACL) for AKS overview」を参照してください。
ノードの承認
ノードの認証は、East-West 攻撃から保護するために、kubelet API 要求を明示的に承認する特殊用途の認証モードです。 AKS 1.24 以上のクラスターでは、ノードの認証が既定で有効になっています。
ノードの展開
ノードは、パブリック IP アドレスが割り当てられていないプライベート仮想ネットワーク サブネットにデプロイされます。 トラブルシューティングと管理の目的で、SSH は既定で有効になっており、内部 IP アドレスを使用してのみアクセスできます。 クラスターとノード プールの作成中に、または既存のクラスターまたはノード プールに対して SSH を無効にする機能はプレビュー段階です。 詳細については、SSH アクセスの管理に関する記事を参照してください。
ノード ストレージ
ストレージを提供するために、ノードはAzure Managed Disksを使用します。 ほとんどの VM ノード サイズでは、Azure Managed Disksは高パフォーマンス SSD によってサポートされる Premium ディスクです。 マネージド ディスクに格納されているデータは、Azure プラットフォーム内で保存時に自動的に暗号化されます。 冗長性を向上させるために、Azure Managed DisksはAzure データセンター内で安全にレプリケートされます。
悪意のあるマルチテナント ワークロード
現在、Kubernetes 環境は悪意のあるマルチテナントの使用に対して安全ではありません。 ポッドのセキュリティ ポリシーやノード用の Kubernetes RBAC などのような追加のセキュリティ機能により、悪用を効率的にブロックします。 悪意のあるマルチテナント ワークロードを実行する場合の真のセキュリティを実現するために、ハイパーバイザーのみを信頼してください。 Kubernetes 用のセキュリティ ドメインは、個々のノードではなく、クラスター全体になります。
この種の悪意のあるマルチテナント ワークロードでは、物理的に分離されたクラスターを使用する必要があります。 ワークロードを分離する方法については、「AKS でのクラスターの分離に関するベスト プラクティス」を参照してください。
コンピューティングの分離
コンプライアンスや規制上の要件により、特定のワークロードでは、他の顧客によるワークロードから高度に分離する必要がある場合があります。 これらのワークロードの場合、Azureは次の機能を提供します。
- カーネル分離コンテナー: AKS クラスター内のエージェント ノードとして使用します。 これらのコンテナーは、特定のハードウェアの種類に完全に分離され、Azureホスト ファブリック、ホスト オペレーティング システム、ハイパーバイザーから分離されます。 これらは 1 人の顧客専用です。 AKS クラスターの作成時、またはノード プールの追加時には、ノード サイズとして分離された仮想マシン サイズの 1 つを選択します。
- 機密コンテナー (プレビュー): Kata Confidential Containers に基づいてコンテナー メモリを暗号化し、計算中のメモリ内のデータがクリア テキストや読み取り可能な形式になったり、改ざんされたりしないようにします。 これは、他のコンテナー グループ/ポッド、および VM ノード OS カーネルからコンテナーを分離するのに役立ちます。 機密コンテナー (プレビュー) では、ハードウェア ベースのメモリ暗号化 (SEV-SNP) が使用されます。
- ポッド サンドボックス: コンテナー アプリケーションと、コンテナー ホストの共有カーネルおよびコンピューティング リソース (CPU、メモリ、ネットワーク) との間の分離境界を提供します。
ネットワークのセキュリティ
オンプレミス ネットワークとの接続とセキュリティのために、AKS クラスターを既存のAzure仮想ネットワーク サブネットにデプロイできます。 これらの仮想ネットワークは、Azureサイト間 VPN または Express Route を使用してオンプレミス ネットワークに接続します。 プライベートの内部 IP アドレスを使用して Kubernetes イングレス コントローラーを定義し、内部ネットワーク接続へのサービス アクセスを制限します。
AKS 自動では、マネージド仮想ネットワーク機能とコアイングレスとエグレスの既定値が事前に構成され、セキュリティで保護されたベースラインが提供されます。 AKS Standard では、ネットワーク モデルとエグレス/イングレス制御の柔軟性が高く、セキュリティ アーキテクチャに基づいて選択する必要があります。
Azure ネットワーク セキュリティ グループ
仮想ネットワーク トラフィック フローをフィルター処理するために、Azureはネットワーク セキュリティ グループの規則を使用します。 これらのルールは、リソースへのアクセスを許可または拒否する発信元と宛先の IP 範囲、ポート、およびプロトコルを定義します。 Kubernetes API サーバーへの TLS トラフィックを許可する、既定の規則が作成されます。 ロード バランサー、ポート マッピング、またはイングレス ルートを使用してサービスを作成します。 AKS は、トラフィック フローのネットワーク セキュリティ グループを自動的に変更します。
AKS クラスター用に独自のサブネットを指定する場合 (Azure CNI または Kubenet のどちらを使用する場合でも)、aKS によって管理される NIC レベルのネットワーク セキュリティ グループは変更されません。 代わりに、サブネットレベルのネットワーク セキュリティ グループをさらに作成して、トラフィックのフローを変更します。 ロード バランサーへのアクセス、コントロール プレーンとの通信、またはエグレスなど、クラスターを管理するために必要なトラフィックに干渉しないようにしてください。
Kubernetes ネットワーク ポリシー
クラスター内のポッド間のネットワーク トラフィックを制限するために、AKS では、Kubernetes ネットワーク ポリシーのサポートを提供しています。 ネットワーク ポリシーを使用すると、名前空間とラベル セレクターに基づいて、クラスター内の特定のネットワーク パスを許可または拒否できます。
アプリケーションのセキュリティ
AKS で実行されているポッドを保護するには、Microsoft Defender for Containers を検討して、ポッドで実行されているアプリケーションに対するサイバー攻撃を検出して制限します。 継続的なスキャンを実行して、アプリケーションの脆弱性状態のドリフトを検出し、"ブルー/グリーン/カナリア" プロセスを実装して、脆弱なイメージに修正プログラムを適用して置き換えます。
AKS 自動では、ワークロード ID と OIDC 発行者が事前に構成され、Azure サービスへのセキュリティで保護されたワークロード アクセスが簡略化されます。 AKS Standard では、これらの機能を使用でき、ベースライン セキュリティ体制の一部として有効にすることができます。
リソースへのコンテナー アクセスをセキュリティで保護する
ユーザーまたはグループに必要最小限の特権を付与するのと同様に、コンテナーも必要なアクションとプロセスのみに制限するようにします。 攻撃のリスクを最小限に抑えるには、昇格された特権またはルート アクセスを必要とするアプリケーションとコンテナーを構成しないようにします。 AppArmor や seccomp などの組み込みの Linux セキュリティ機能は、リソースへのコンテナー アクセスをセキュリティで保護するためのベスト プラクティスとして推奨されます。
Kubernetes シークレット
Kubernetes シークレットを使用すると、アクセス資格情報やキーなどの機密データをポッドに挿入できます。
- Kubernetes API を使用してシークレットを作成します。
- ポッドまたはデプロイを定義し、特定のシークレットを要求します。
- シークレットは、それを必要とするスケジュールされたポッドを持つノードにのみ提供されます。
- シークレットは tmpfs に格納され、ディスクには書き込まれません。
- シークレットを必要とするノードの最後のポッドを削除すると、ノードの tmpfs からシークレットが削除されます。
- シークレットは、指定した名前空間内に格納され、同じ名前空間内のポッドからのみアクセスできます。
シークレットを使用すると、ポッドやサービスの YAML マニフェストに定義されている機密情報が削減されます。 代わりに、YAML マニフェストの一部として Kubernetes API サーバーに格納されたシークレットを要求します。 この方法により、シークレットへのアクセス権が特定のポッドにのみ提供されます。
注意
生の秘密マニフェスト ファイルには、base64 形式の秘密データが含まれています。 詳細については、公式ドキュメントを参照してください。 これらのファイルは機密情報として扱い、ソース管理にはコミットしないようにしてください。
Kubernetes シークレットは、分散型キー値ストアである etcd に格納されます。 AKS では、 カスタマー マネージド キーを使用して etcd 内のシークレットの残りの部分を暗号化できます。
関連するコンテンツ
AKS クラスターのセキュリティでの保護を開始するには「AKS クラスターのアップグレード」を参照してください。
モード固有の既定値と運用責任を評価している場合は、Azure Kubernetes Service (AKS) Automatic とはをご覧ください。
関連付けられているベスト プラクティスについては、AKS でのクラスターのセキュリティとアップグレードに関するベスト プラクティスのページと、AKS でのポッドのセキュリティに関するベスト プラクティスのページを参照してください。
コア Kubernetes と AKS の概念に関する詳細については、以下を参照してください。