次の方法で共有

運用をセキュリティで保護する

運用上のセキュリティは、Kubernetes クラスターの制御を維持し、新たな脅威に対応するために重要です。 この記事では、アクセスの管理、ポリシーの適用、アクティビティの監視、インシデントへの対応に関するベスト プラクティスについて説明します。 強力な運用制御を実装することで、承認されたユーザーとプロセスのみがクラスターとワークロードに変更を加えることができます。

Azure コントロール プレーンを使用してクラスターを管理できるユーザーを制御する

エッジ クラスターの Azure Arc クラウド管理を可能にするサブスクリプションやリソースなど、Azure コントロール プレーンへのアクセスを制御することが重要です。 多要素認証や条件付きアクセスなど、 Azure アクセス制御のベスト プラクティスを確認して実装します。 Azure RBAC を使用して、他の Azure クラウド リソースへのアクセスを制御するために既に使用するのと同じ方法で、どのクラスターでどの操作を実行できるかを制御します。

さらに、Microsoft によって生成された証明書は、エッジ クラスターと Azure コントロール プレーン間の接続をセキュリティで保護するために使用されます。 これらの証明書は Kubernetes シークレットとして格納されるため、 Kubernetes シークレット ストア自体が暗号化されていることが重要です。

ロールベースのアクセス制御 (RBAC) を使用してクラスターにデプロイできるユーザーを制御する

また、Kubernetes コントロール プレーン (API サーバー) 自体へのアクセスを制御することも重要です。これは、Kubernetes ワークロードをデプロイおよび監視するための手段です。

ワークロードから API サーバーに非人アクセスする場合は、Kubernetes の組み込み RBAC を使用して、それを必要とする特定のサービス アカウントのみを承認します。 これらのサービス アカウントの発行と保護に関するアドバイスも参照してください。

API サーバーに人間がアクセスする場合、Kubernetes には組み込みのユーザー アカウントがありません。 そのため、Microsoft Entra ID などの外部ユーザー アカウント サービスと統合することをお勧めします。 その後、これらの ID を使用して、どの名前空間で何を実行できるかを制御する承認ポリシーを作成できます。 これらのポリシーは、Kubernetes の組み込み RBAC または Azure RBAC を使用して作成できます。 すべてのユーザー承認ポリシーを一元的に管理および監査し、クラウドとエッジの両方のリソースをカバーする場合は、Azure RBAC をお勧めします。 Azure Arc on Azure Local で AKS を有効にしている場合 、または 独自のクラスターを接続する場合は、Azure RBAC を簡単に使用できます。 その後、ユーザーは Entra ID アカウントを使用して、クラスター (その API サーバー) に直接アクセスするか、"クラスター接続" 機能を使用して Azure プロキシ経由でアクセスできます。 必要最小限のアクセス許可を持つロールを各ユーザーまたはワークロードに割り当てる"最小限の特権" アプローチを採用することをお勧めします。

より一般的には、開発、テスト、運用のクラスターを分離する標準的なベスト プラクティスに従ってください。 また、クラスターへの運用デプロイが 、GitOps アプローチを使用してより確実かつ安全に管理されるかどうかを検討します。 このアプローチに従う場合は、デプロイの定義に使用される、基になるソース Git リポジトリとブランチで、変更 (プル要求) に対して同様の強力なロールベースのアクセス制御を実装することも重要です。

最後に、Azure Arc on Azure Local で AKS を有効にしている場合は、 完全な管理者アクセス用の管理者クライアント証明書をダウンロードすることもできます。 通常、この証明書を使用する必要はないため、必要な場合にのみダウンロードします。たとえば、別の方法では調査できない問題を診断するためです。 また、この方法は、Entra ID アカウントと設定したユーザーごとのポリシーを使用しないため、注意して使用する必要があります。 さらに、クライアント証明書を慎重に保存し、不要になったら削除する必要があります。

リファレンス

Kubernetes 用 Azure Policy を使用してコンテナーをデプロイして実行するときに、セキュリティで保護されたコンテナーのライフサイクルに従います

展開フェーズを通じて、 Microsoft Containers Secure Supply Chain フレームワーク に従い続けます。 ( 取得、カタログ、ビルドの各フェーズのガイダンスも参照してください)。このフレームワークは、 Azure Container Registry などの独自の信頼されたレジストリからのみデプロイするのに役立ちます。 レジストリのアクセス制御メカニズムを使用して、信頼されたクラスターのみが機密情報を含む可能性のあるコンテナーをプルするようにします。 Azure Container Registry では、 ロールベースのアクセス制御 (RBAC) と 属性ベースのアクセス制御 (ABAC) の両方をサポートして、特定のリポジトリへの割り当てをさらにスコープ指定します。

さらに、Azure Policy を使用して、コンテナー セキュリティの検疫に関するベスト プラクティス標準を適用します。 たとえば、 Azure Policy の組み込み定義を使用して、すべてのポッドが低コードアプローチでポッドセキュリティ標準を満たしていることを検証できます。 ゲートキーパーを拡張する Azure Policy 拡張機能をエッジ Kubernetes クラスターにデプロイして、ポッドベースのセキュリティ適用を大規模に適用することもできます。 最初に"監査" モードでポリシーの割り当てを適用することをお勧めします。 このモードでは、Kubernetes ごとのリソースでの非準拠の結果の集計された一覧がポリシー単位の粒度で提供されるため、実行中のデプロイに関する既存の問題を最初に特定して修復できます。 環境内の準拠していない違反を修正したら、ポリシーの割り当てを "拒否" モードに更新できます。 Azure Policy の豊富な安全なデプロイ メカニズムにより、リソース間でこのポリシーの適用が段階的にロールアウトされます。 適用モードでポリシーを適用することで、それ以上の逸脱を積極的に防ぐことができます。

リファレンス

コントロール プレーンの変更の監視など、新たな脅威を検出する

クラスターで脅威が発生した場合に脅威を検出する方法があることを確認します。

エッジにある Kubernetes クラスターに Defender for Containers 拡張機能 をデプロイできます。 この拡張機能には、ログを収集して Defender for Cloud に送信する センサー が含まれています。 その後、攻撃を示したり、インシデントが発生した後にフォレンジックに使用されたりする可能性のある異常な動作を分析できます。 プレビューリリースまたは GA リリースとして、どのクラスターの種類でサポートされている機能のサポート マトリックス を参照してください。 さらに、Defender for Cloud は、 Microsoft Defender XDR インシデント検出および対応ソリューションの一部として、分析用のイベントを送信できます。

Azure Arc on Azure Local によって有効になっている AKS で実行している場合は、 Kubernetes 監査ログを Azure Monitor (Log Analytics ワークスペース) に送信するように構成することもできます。 また、 ワークロード自体を監視するための関連するアドバイスに従ってください。 また、信頼性、コストの最適化、パフォーマンス、セキュリティに関するクラスターの監視に関する ベスト プラクティス を確認してください。

監視に加えて、インシデント対応計画を構築し、それを使用する練習を行います。 このようなプランの詳細は、デプロイ環境全体と、使用するセキュリティ運用ツールによって大きく異なります。詳細については、この ガイダンス を参照してください。 ただし、少なくとも、クラスターの状態を保持する方法 (監査ログの保持、疑わしい状態のスナップショット) と、 それを既知の正常な状態に回復する方法について考えてください。

リファレンス

デプロイ戦略を使用してダウンタイムゼロの更新を実現する

重要なセキュリティ更新プログラムは、緊急にロールアウトされた場合でも、ワークロードの信頼性と可用性を損なうべきではありません。 環境内の高可用性を維持するのに最適な Kubernetes デプロイ戦略 を選択します。 また、 準備プローブと liveness-probe を 実装することで、Kubernetes がデプロイを維持するワークロードの状態についてより詳しく学習することも検討してください。 イングレス ロード バランサーでの段階的なロールアウトとトラフィック管理ポリシーと組み合わせることで、Kubernetes を使用して、アプリケーションの可用性を中断することなく更新プログラムを実行できます。

次のステップ