次の方法で共有

AKS のセキュリティ

この記事では、ソリューションを実装する前に考慮すべき Azure Kubernetes Service (AKS) セキュリティ ガバナンスの側面について説明します。

この記事では、Azure とオープンソース ソフトウェアを使用してソリューションを実装する方法について説明します。 エンタープライズ規模のランディング ゾーンを作成するときに行う決定は、ガバナンスを部分的に事前に定義できます。 ガバナンスの原則を理解するには、 エンタープライズ規模のセキュリティ ガバナンスとコンプライアンスに関する説明を参照してください。

攻撃対象領域

Kubernetes クラスターのセキュリティ戦略を作成するときは、次の 5 つの攻撃対象領域を考慮してください。

  • 建築する
  • レジストリ
  • クラスター
  • ノード
  • アプリケーション

カテゴリごとに、考慮すべき主要なリスクと、それらのリスクに対する対策について説明します。

セキュリティの構築

ビルド セキュリティは、コンテナー イメージでの DevSecOps の適切な使用に関するものです。

主なリスク

イメージの構成が不適切な場合、パイプラインのセキュリティの脆弱性につながる可能性があります。 たとえば、必要以上の特権で実行されているコンテナーがある可能性があります。 コンテナーは、特定のネットワーク アクセスを許可するように構成されている場合もあります。これにより、システムが危険にさらされる可能性があります。 コンテナーの安全な操作に必要な呼び出しに許可されたシステム呼び出しを制限しないと、侵害されたコンテナーによるリスクが高まる可能性があります。

もう 1 つの脆弱性は、コンテナーがホストの機密性の高いディレクトリにアクセスできるようにするか、コンテナーがホストの基本的な機能を制御する場所を変更できるようにする可能性があります。

不正なコンテナーは、環境内の計画外のコンテナーです。 これらは、開発者がテスト環境でコードをテストした結果である可能性があります。 これらのコンテナーは、脆弱性の厳密なスキャンを行っていないか、適切に構成されていない可能性があります。 これらの脆弱性により、攻撃者のエントリ ポイントが開く可能性があります。

信頼できるソースからのものではない、またはセキュリティ更新プログラムで最新ではない基本イメージを使用すると、ビルドに使用するコンテナーの脆弱性につながる可能性もあります。

リスク対策

ビルド セキュリティとは、DevSecOps を実装してセキュリティを左に移行し、ほとんどの問題を修復してからパイプラインを下に移動することです。 これは、すべての所有権を開発者に置くことではなく、所有権を操作と共有することです。 その後、開発者は、実際に対処できる脆弱性とコンプライアンスの問題を確認して修復できます。

1 つまたは 10 個の重大な脆弱性があるため、ビルドをスキャンして失敗するパイプラインを構築できます。 より良いアプローチは、次のレイヤーを見下ろす方法です。 仕入先ステータスに基づいて責任ポイントのセグメント化を開始できます。

脆弱性の状態レイヤーでしきい値を設定します。 状態が Open、Will not fix、Deferred のいずれかであるものは、現在と同様にSecOpsがリスクを評価するためにアクセスできるパイプラインを引き続き流れます。 利用可能なベンダー修正プログラムの状態に関する脆弱性は、開発者が対処できるものです。 猶予期間を使用すると、開発者が脆弱性を修復する時間が得ることができます。

脆弱性評価と共にコンプライアンス評価が行われます。 たとえば、イメージを ルートとして実行 したり、SSH を公開したりすると、ほとんどの企業のコンプライアンス体制が解除されます。 デプロイ時ではなく、ビルド中にこの問題に対処します。

通常は、Docker CIS ベンチマークに対してイメージをスキャンします。 これらの種類のフローを使用する場合、セキュリティ修復を導入して開発を中断することはありませんが、企業のセキュリティ体制を全体的にインラインで改善できます。

これらの機能を有効にするツールを使用することは、企業に適した戦略を効果的に実装するために不可欠です。 従来のツールでは、コンテナー内の脆弱性を検出できないことが多く、誤ったセキュリティ感につながる可能性があります。 コンテナー エコシステムを適切にセキュリティで保護するには、パイプライン ベースのビルド アプローチと、コンテナー テクノロジの不変で宣言型の性質を考慮するツールが必要です。

これらのツールには、次のプロパティが必要です。

  • ビルド プロセスの開始時からレジストリからランタイムまでのイメージの有効期間全体との統合。
  • イメージの基本レイヤー、アプリケーション フレームワーク、カスタム ソフトウェアなど、イメージのすべてのレイヤーの脆弱性を可視化します。
  • 適切なレベルの細分性を持つポリシー主導の適用により、組織はビルドおよびデプロイ プロセスの各段階で品質ゲートを作成できます。

レジストリのセキュリティ

レジストリのセキュリティは次のとおりです。

  • ビルドからのドリフト制御。
  • 汚染された画像のプッシュ/プルの防止。
  • イメージの署名。

主なリスク

イメージには、多くの場合、組織のソース コードを含む独自の情報が含まれています。 レジストリへの接続が適切にセキュリティで保護されていない場合、イメージのコンテンツは、組織内で送信される他の形式のデータと同様に機密性のリスクを引き起こす可能性があります。 レジストリに古いバージョンの脆弱性がある古いイメージは、誤ってデプロイされた場合にセキュリティ リスクを高める可能性があります。

もう 1 つのセキュリティの脆弱性には、コンテナー レジストリに対する認証と承認の制限が不十分である可能性があります。 これらのレジストリは、機密性の高い独自の資産をイメージに格納する場合があります。

コンテンツが構築およびデプロイされると、このコンテンツの配布は多くの攻撃ベクトルの 1 つです。 配布用にステージングされたコンテンツが、目的のエンドポイントに配信されるコンテンツと同じであることを確認するにはどうすればよいですか?

リスク対策

開発ツール、ネットワーク、コンテナー ランタイムが暗号化されたチャネル経由でのみレジストリに接続されるように、デプロイ プロセスを設定します。 また、コンテンツが信頼できるソースから取得されていることを確認します。 古いイメージの使用によるリスクを軽減するには:

  • コンテナー レジストリから使用されなくなった安全でない脆弱なイメージを削除します。
  • 使用するイメージの特定のバージョンを指定する変更できない名前を使用して、イメージへのアクセスを強制します。 この構成は、 最新 のタグまたはイメージの特定のバージョンを使用して実装できます。 タグは鮮度を保証しません。 このため、Kubernetes オーケストレーターが最新の一意の番号を使用しているか、 最新 のタグが最も up-to-date バージョンを表していることを確認するプロセスを配置します。

機密性の高いイメージを含むレジストリへのアクセスには、認証と承認が必要です。 すべての書き込みアクセスには認証も必要です。 たとえば、ポリシーでは、開発者が担当する特定のリポジトリにのみイメージをプッシュできます。

これらのレジストリへのアクセスはフェデレーションされ、ビジネスラインレベルのアクセス ポリシーを利用する必要があります。 たとえば、脆弱性スキャンコンプライアンス評価および品質管理テストに合格した後にのみ、リポジトリにイメージをプッシュするように CI/CD パイプラインを構成できます。

コンテナー レジストリは、今ではアーティファクト レジストリとみなされており、コンテナー イメージだけでなく、任意のコンテンツ タイプをデプロイするための主要な手段になりつつあります。 すべてのクラウドには、クラウド プロバイダー内のオンプレミスまたはプライベート ホスティングで利用できるオープンソース プロジェクトとベンダー製品を含むレジストリが用意されています。 コンテンツは、最初のビルドから運用環境へのデプロイまで、レジストリ内およびレジストリ間で昇格されます。

レジストリに入ったコンテンツの整合性が、レジストリから出てくるコンテンツと同じであることを確認するにはどうすればよいですか? イメージ署名ソリューションを採用すると、デプロイは信頼できるレジストリからのみ取得され、信頼できるコンテンツがデプロイされます。

クラスターのセキュリティ

クラスターのセキュリティは次のとおりです。

  • 認証と承認。
  • ネットワーク セキュリティ。
  • 脆弱性とコンプライアンス管理。

主なリスク

1 つの Kubernetes クラスターを使用して、異なるアクセス レベルの要件を持つ異なるチームによって管理される異なるアプリケーションを実行する場合があります。 アクセスが制限なしで、またはニーズに応じてのみ個人に提供される場合、悪意のあるユーザーや不注意なユーザーは、アクセス権を持つワークロードやクラスター上の他の資産を侵害する可能性があります。

別のセキュリティの脆弱性は、クラスターの独自のユーザー ディレクトリが承認と認証を管理するときに発生する可能性があります。 組織の認証ディレクトリは、多くの場合、より厳密に制御されます。 これらのアカウントは高い特権を持ち、より頻繁に孤立しているため、侵害されたアカウントの可能性が高くなります。

このシナリオは、クラスターやシステム全体の脆弱性につながる可能性があります。 コンテナー ボリュームによって格納されるデータはオーケストレーターによって管理されます。オーケストレーターは、ホストされているノードに関係なく、データにアクセスできる必要があります。

従来のネットワーク フィルターでは、転送中のデータを暗号化するように設計されたネットワーク オーバーレイが原因で、セキュリティの盲目が発生する可能性があります。 この設計により、クラスター内のトラフィックを監視することが困難になるため、Kubernetes クラスターを監視するために特別なプロビジョニングが必要になる場合があります。

同じクラスターを共有する異なるアプリケーションからのトラフィックは、公開 Web サイトや重要な機密性の高いビジネス プロセスを実行する内部アプリケーションなど、異なる秘密度レベルを持つ場合があります。 クラスター内で同じ仮想ネットワークを共有すると、機密データが侵害される可能性があります。 たとえば、攻撃者は、インターネットに公開されている共有ネットワークを使用して内部アプリケーションを攻撃する可能性があります。

クラスター自体を実行しているコンポーネントを脆弱性やコンプライアンスの問題から保護します。 修復を利用するために、可能な最新バージョンの Kubernetes で実行していることを確認します。

リスク対策

Kubernetes クラスターのユーザー アクセスには、最小特権アクセス モデルを使用する必要があります。 ユーザーがジョブを実行するために必要な特定のホスト、コンテナー、およびイメージに対して特定のアクションを実行するためのアクセス権のみをユーザーに付与します。 テスト チーム メンバーには、運用環境のコンテナーへのアクセスが制限されているか、アクセスできない必要があります。 クラスター全体のアクセス権を持つユーザー アカウントは、厳重に制御し、慎重に使用する必要があります。

多要素認証などの強力な認証方法を使用して、これらのアカウントへのアクセスをセキュリティで保護します。 同じレベルのポリシーと制御を持たないクラスター固有のユーザー アカウントではなく、シングル サインオンを使用してクラスターを管理するには、組織のユーザー ディレクトリを使用する必要があります。

コンテナーが実行されているホストに関係なく、コンテナーがデータに適切にアクセスできるようにする暗号化方法を使用します。 これらの暗号化ツールは、他のコンテナーにアクセスできない同じノード内であっても、他のコンテナーによるデータへの不正アクセスを防ぐ必要があります。

秘密度レベルで個別の仮想ネットワークまたはサブネットにネットワーク トラフィックを分離するように Kubernetes クラスターを構成します。 アプリケーションごとのセグメント化も可能ですが、秘密度レベルでネットワークを定義するだけで十分な場合があります。 たとえば、機密性の高いトラフィックを含む内部アプリケーションにサービスを提供するアプリケーションとは別の顧客向けアプリケーションの仮想ネットワークは、少なくとも実装する必要があります。

テイントと許容を使用して、機微レベルに応じて特定のノードセットに対して展開を限定できます。 機密性の高いワークロードは、感度の低いワークロードと同じノード内でホストしないようにします。 個別のマネージド クラスターを使用する方が安全なオプションです。

機密性の高いワークロードに対する追加の保護を提供するために、目的、機密性、スレッドの状態によってコンテナーをセグメント化します。 このようにコンテナーをセグメント化することで、あるセグメントへのアクセス権を取得した攻撃者が他のセグメントにアクセスすることはより困難になります。 この構成には、キャッシュやボリューム マウントなどの残りのデータを秘密度レベルで分離するという追加の利点があります。

Kubernetes クラスターは、次のように構成する必要があります。

  • それらの上で実行されるアプリケーションに対して、セキュリティで保護された環境を提供します。
  • ノードがクラスターに安全に追加されていることを確認します。
  • ライフサイクル全体を通じてセキュリティを確保するために役立つ永続的な ID を持ちます。
  • ネットワークやクラスター内のノードなど、クラスターの状態に関するライブで正確な情報を提供します。

クラスターのパフォーマンスに影響を与えずに、侵害されたノードをクラスターから簡単に分離および削除できる必要があります。 AKS を使用すると、その操作が簡単になります。

コンテナー ランタイムの構成標準を定義して、コンプライアンスを自動的に確保します。 Azure 内には、このプロセスを簡単にする多くのポリシーがあり、ユーザーは独自のポリシーを作成することもできます。 Azure セキュリティ機能を使用して、環境全体の構成設定を継続的に評価し、それらをアクティブに適用します。

Kubernetes コンポーネントの脆弱性が対処されていることを自動的に確認します。 開発、テスト、運用には個別の環境を使用し、それぞれに独自の制御と、コンテナー管理用のロールベースのアクセス制御 (RBAC) を使用します。 すべてのコンテナー作成を個々のユーザー ID に関連付け、監査のためにログに記録する必要があります。 この構成は、悪意のあるコンテナーのリスクを軽減するのに役立ちます。

ノードのセキュリティ

ノードのセキュリティは次のとおりです。

  • ランタイム保護。
  • 脆弱性とコンプライアンス管理。

主なリスク

ワーカー ノードには、ノード上のすべてのコンポーネントへの特権アクセス権があります。 攻撃者は、任意のネットワークアクセス可能なサービスをエントリ ポイントとして使用できるため、複数のポイントからホストへのアクセスを提供すると、攻撃対象領域が大幅に増加する可能性があります。 攻撃対象領域が大きいほど、攻撃者がノードとそのオペレーティング システムにアクセスする可能性が高くなります。

また、AKS ノードで使用されるオペレーティング システムのようなコンテナー固有のオペレーティング システムには、通常のオペレーティング システムでデータベースと Web サーバーを直接実行できるライブラリが含まれていないため、攻撃対象領域が小さくなります。 共有カーネルを使用すると、別の仮想マシン内のコンテナーよりも同じ環境で実行されているコンテナーの攻撃対象領域が大きくなります。 これは、AKS ノードで実行されているコンテナー固有のオペレーティング システムが使用されている場合でも当てはまる場合です。

ホスト オペレーティング システムは、脆弱性とコンプライアンス リスクを持つ可能性がある基本的なシステム コンポーネントを提供します。 これらは低レベルのコンポーネントであるため、それらの脆弱性と構成は、ホストされているすべてのコンテナーに影響を与える可能性があります。 AKS は、これらの脆弱性が AKS 上で実行されているノードで定期的な OS 更新プログラムを介して処理され、ワーカー ノードのコンプライアンス体制が維持されるようにすることで、ユーザーを保護します。

また、不適切なユーザー アクセス権は、ユーザーが AKS コントロール プレーンを介してではなく、コンテナーを管理するためにノードに直接サインインすると、セキュリティ 上のリスクにつながる可能性もあります。 直接サインインすると、ユーザーがアクセス権を持つ必要のあるアプリケーション以外のアプリケーションに変更を加えることができます。

また、悪意のあるコンテナーは、ホスト OS ファイル システムの改ざんにつながる可能性があります。 たとえば、コンテナーがホスト OS に機密性の高いディレクトリをマウントできる場合、そのコンテナーによってファイルが変更される可能性があります。 変更は、ホストで実行されている他のコンテナーのセキュリティに影響する可能性があります。

リスク対策

SSH アクセスを制限してノード アクセスを制限します。

AKS ノードでコンテナー固有の OS を使用すると、通常、他のサービスと機能が無効になるため、攻撃対象領域が減少します。 また、読み取り専用のファイル システムもあり、既定では他のクラスター強化プラクティスを採用しています。

Azure プラットフォームは、LINUX および Windows ノードに夜間に OS セキュリティ パッチを自動的に適用します。 Linux OS セキュリティ更新プログラムでホストの再起動が必要な場合、自動的には再起動されません。 AKS には、これらの特定のパッチを適用するために再起動するメカニズムが用意されています。

Microsoft は OS を管理するため、AKS Linux ノードと Windows ノードには Microsoft Defender for Servers を適用できません。 AKS がデプロイされているサブスクリプションに他の仮想マシンがない場合は、Microsoft Defender for Servers を安全に無効にすることができます。

エンタープライズ規模のランディング ゾーンで推奨される Azure ポリシーを含め、環境がデプロイされている場合は、不要なコストを回避するために Microsoft Defender for Servers を自動的に有効にする管理グループのポリシー割り当ての除外を構成できます。

アプリケーションのセキュリティ

アプリケーションのセキュリティは次のとおりです。

  • ランタイム保護。
  • 脆弱性とコンプライアンス管理。

主なリスク

イメージは、アプリケーションの実行に必要なすべてのコンポーネントを含むファイルです。 これらのコンポーネントの最新バージョンを使用してイメージを作成すると、その時点では既知の脆弱性がないかもしれませんが、それがすぐに変わる可能性があります。

パッケージ開発者はセキュリティの脆弱性を定期的に特定するため、これらのファイルを最新バージョンに保つ必要があります。 コンテナーの作成に使用するイメージを更新することで、コンテナーの更新をさらに上流に行います。従来のアプリケーションとは異なり、通常はホストで更新されます。

悪意のあるファイルを画像に埋め込むこともできます。これにより、システムの他のコンテナーやコンポーネントを攻撃するために使用できます。 サード パーティ製のコンテナーは、攻撃ベクトルの可能性があります。 具体的な詳細は不明であり、データが漏洩する可能性があります。 必要なセキュリティ更新プログラムでコンテナーが最新の状態に保たれていない可能性があります。

もう 1 つの攻撃ベクトルは、イメージ ファイル システム内でパスワードや接続文字列などのシークレットを直接埋め込む方法です。 この方法では、イメージにアクセスできるすべてのユーザーがシークレットにアクセスできるため、セキュリティ リスクが発生する可能性があります。

クロスサイト スクリプティングや SQL インジェクションに対して脆弱なアプリケーションなど、アプリケーション自体に欠陥がある可能性があります。 欠陥が存在する場合、この脆弱性は、他のコンテナーまたはホスト OS 内の機密情報への不正アクセスを可能にするために使用される可能性があります。

AKS コンテナー ランタイムを使用すると、Azure で利用できるさまざまなセキュリティ ツールを使用して脆弱性を簡単に監視できます。 詳細については、「 Microsoft Defender for Kubernetes の概要」を参照してください。

また、コンテナーに送信されるエグレス ネットワーク トラフィックを制御して、コンテナーがセキュリティで保護されたデータをホストしている環境やインターネットなど、さまざまな秘密度レベルのネットワーク間でトラフィックを送信できないようにする必要があります。 Azure では、さまざまなネットワークと AKS セキュリティ機能を使用して、この制御を簡単に行うことができます。

既定では、Kubernetes スケジューラは、スケールを推進し、ノードで実行されているワークロードの密度を最大化することに重点を置いています。 ホストに使用可能なリソースが最も多いという理由だけで、同じノードに異なる機密レベルのポッドが配置される可能性があります。 このシナリオでは、攻撃者が公開ワークロードへのアクセスを使用して、同じホスト上でより機密性の高いプロセスを実行しているコンテナーを攻撃すると、セキュリティ インシデントが発生する可能性があります。 侵害されたコンテナーは、ネットワークをスキャンして、攻撃者が悪用できる他の脆弱性を見つけるためにも使用される可能性があります。

リスク対策

アプリケーション コードまたはファイル システムにシークレットを格納しないでください。 シークレットはキー ストアに格納し、必要に応じて実行時にコンテナーに提供する必要があります。 AKS では、特定のキーへのアクセスが必要なコンテナーのみがそれらにアクセスでき、これらのシークレットがディスクに保持されないようにすることができます。 たとえば、Azure Key Vault では、これらのシークレットを安全に格納し、必要に応じて AKS クラスターに提供できます。 また、これらのシークレットがストレージ内と転送中の両方で暗号化されるようにすることも簡単です。

信頼されていないイメージとレジストリを使用しないようにし、信頼されたセットのイメージのみをクラスターで実行できるようにします。 多層アプローチの場合:

  • 信頼されているイメージとレジストリを正確に一元的に制御します。
  • 暗号化署名によって各イメージを個別に識別します。
  • すべてのホストが承認済みセットからのイメージのみを実行するようにポリシーを設定します。
  • 実行前にこれらの署名を検証します。
  • 脆弱性と構成要件の変化に応じて、これらのイメージとレジストリを監視および更新します。

セキュリティで保護されたコンピューティング プロファイルを使用してコンテナーを制約し、実行時に割り当てる必要があります。 カスタム プロファイルを作成してコンテナー ランタイムに渡して、その機能をさらに制限できます。 少なくとも、コンテナーが既定のプロファイルで実行されていることを確認します。 危険度の高いアプリケーションを実行するコンテナーに対して、より制限されたカスタム プロファイルを使用することを検討してください。

ツールでは、行動学習を使用してアプリケーションを自動的にプロファイリングし、異常を検出できます。 サードパーティのソリューションを使用して、実行時に異常を検出できます。 異常には、次のようなイベントが含まれる場合があります。

  • プロセスの実行またはシステム呼び出しが無効または予期しない。
  • 保護された構成ファイルとバイナリに対する変更。
  • 予期しない場所とファイルの種類に書き込みます。
  • 予期しないネットワーク リスナーの作成。
  • 予期しないネットワーク宛先に送信されたトラフィック。
  • マルウェアのストレージと実行。

Microsoft Defender for Kubernetes は現在、この分野に投資しています。

コンテナーは、ルート ファイルシステムを読み取り専用モードで実行して、定義されたディレクトリへの書き込みを分離する必要があります。これらのツールは簡単に監視できます。 この構成により、これらの特定の場所に改ざんを分離するため、コンテナーの侵害に対する回復性が向上します。 これらは、アプリケーションの残りの部分から簡単に分離できます。

設計に関する考慮事項

AKS には、Microsoft Entra ID、Azure Storage、Azure Virtual Network などの他の Azure サービスへのインターフェイスがいくつかあります。 これらのサービスを使用するには、計画フェーズ中に特別な注意が必要です。 また、AKS では複雑さが増し、インフラストラクチャの残りのランドスケープと同じセキュリティ ガバナンスとコンプライアンスメカニズムとコントロールの適用を検討する必要があります。

AKS のセキュリティ ガバナンスとコンプライアンスに関するその他の設計上の考慮事項を次に示します。

  • エンタープライズ規模のランディング ゾーンのベスト プラクティスに従ってデプロイされたサブスクリプションで AKS クラスターを作成する場合は、クラスターが継承する Azure ポリシーを理解します。 詳細については、「 Azure ランディング ゾーンのリファレンス実装に含まれるポリシー」を参照してください。
  • クラスターのコントロール プレーンにインターネット経由でアクセスできるかどうかを決定します (IP 制限をお勧めします)。既定では、Azure またはオンプレミスのプライベート ネットワーク内からプライベート クラスターとしてのみアクセスできます。 組織がエンタープライズ規模のランディング ゾーンのベスト プラクティスに従っている場合、 Corp 管理グループには、クラスターを強制的にプライベートにする Azure Policy が関連付けられています。 詳細については、「 Azure ランディング ゾーンのリファレンス実装に含まれるポリシー」を参照してください。
  • 組み込みの AppArmor Linux セキュリティ モジュールを使用して評価し、読み取り、書き込み、実行、マウント ファイル システムなどのシステム機能など、コンテナーが実行できるアクションを制限します。 たとえば、すべてのサブスクリプションには、すべての AKS クラスター内のポッドが特権コンテナーを作成できないようにする Azure ポリシーがあります。 詳細については、「 Azure ランディング ゾーンのリファレンス実装に含まれるポリシー」を参照してください。
  • プロセス レベルで seccomp (セキュリティで保護されたコンピューティング) を 使用して評価し、コンテナーが実行できるプロセス呼び出しを制限します。 たとえば、ランディング ゾーン管理グループでの汎用的なエンタープライズ規模のランディング ゾーン実装の一部として、ルートへのコンテナー特権エスカレーションを回避するために適用された Azure Policy は、Kubernetes 用の Azure ポリシーによって seccomp を使用します。
  • コンテナー レジストリにインターネット経由でアクセスするか、特定の仮想ネットワーク内でのみアクセスできるかを決定します。 コンテナー レジストリでインターネット アクセスを無効にすると、パブリック接続に依存してアクセスする他のシステムに悪影響を及ぼす可能性があります。 たとえば、継続的インテグレーション パイプラインや Microsoft Defender for image scanning などがあります。 詳細については、「 Azure Private Link を使用してコンテナー レジストリにプライベートに接続する」を参照してください。
  • プライベート コンテナー レジストリを複数のランディング ゾーン間で共有するか、専用コンテナー レジストリを各ランディング ゾーン サブスクリプションにデプロイするかを決定します。
  • 脅威の検出には 、Microsoft Defender for Kubernetes などのセキュリティ ソリューションを使用することを検討してください。
  • コンテナー イメージの脆弱性をスキャンすることを検討してください。
  • 不要なコストを回避するために、AKS 以外の仮想マシンがない場合は、AKS サブスクリプションで Microsoft Defender for Servers を無効にすることを検討してください。

設計に関する推奨事項

重要

Microsoft Defender for Cloud イメージスキャンは、Container Registry エンドポイントと互換性がありません。 詳細については、「 Private Link を使用してコンテナー レジストリにプライベートに接続する」を参照してください。