次の方法で共有

AKS のセキュリティ

  • [アーティクル]

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

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

攻撃対象領域

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

  • ビルド
  • レジストリ
  • クラスター
  • Node
  • Application

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

セキュリティを構築する

ビルドのセキュリティは、コンテナー イメージを使用した DevSecOps の適切な利用に関係します。

主なリスク

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

別の脆弱性としては、コンテナーがホストの機密ディレクトリにアクセスできるようにしたり、コンテナーがホストの基本機能を制御する場所を変更できるようにしたりする場合があります。

不正なコンテナーは、環境内の計画外のコンテナーです。 これらは、開発者がテスト環境でコードをテストした結果である可能性があります。 これらのコンテナーは、脆弱性検出のための徹底したスキャンを受けていない可能性があり、また適切に構成されていない可能性もあります。 これらの脆弱性が、攻撃者の侵入ポイントとなる可能性があります。

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

リスクの対処法

ビルドのセキュリティは、DevSecOps の実施に関係します。セキュリティを左にシフトし、問題がパイプラインを下り始める前に、その大部分を解決します。 すべての所有権を開発者に持たせるのではなく、所有権を運用者と共有します。 これにより、開発者は、自分が実際に対処できる脆弱性とコンプライアンスの問題を確認して修復できます。

ビルドをスキャンして、1 つまたは 10 個の重大な脆弱性があるために不合格にするパイプラインを構築できます。 それよりも良い方法として、次の層を確認することができます。 ベンダーの状態に基づいて、責任範囲の分割を開始できます。

脆弱性の状態レイヤーでしきい値を設定します。 状態が "オープン"、"修正しない"、"延期済み" のものは、現在と同様、SecOps がリスクにアクセスできるパイプラインを流れ続けます。 利用可能なベンダー修正の状態を持つ脆弱性は、開発者が対処できるものです。 猶予期間を使用すると、開発者が脆弱性を修復する時間を取ることができます。

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

通常は、Docker CIS ベンチマークに対してイメージをスキャンします。 これらの種類のフローを使用すると、セキュリティ修復の導入によって開発が中断されることはなくなるほか、企業のセキュリティ体制を全体的に向上させることができます。

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

これらのツールには、次の特性が必要です。

  • ビルド プロセスの最初からレジストリ、ランタイムまで、イメージのライフタイム全体との統合。
  • イメージの基本層、アプリケーション フレームワーク、カスタム ソフトウェアを含む、イメージのすべての層の脆弱性を確認できる。
  • 適切な粒度のポリシー駆動型適用により、ビルドおよびデプロイ プロセスの各段階で品質ゲートを作成できます。

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

レジストリのセキュリティは、以下に関係します。

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

主なリスク

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

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

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

リスクの対処法

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

  • コンテナー レジストリから、使用するべきではない、安全でない脆弱性のあるイメージを削除します。
  • 使用する特定バージョンのイメージを指定する変更不可の名前を使用して、イメージへのアクセスを強制します。 この構成は、lateset タグ、またはイメージの特定バージョンを使用して実装できます。 タグによって鮮度は保証されません。 このため、Kubernetes オーケストレーターで最新の一意の番号が使用されていること、または latest タグが最新のバージョンを表していることを確実にするためのプロセスを実施する必要があります。

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

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

成果物のレジストリと見なされるようになったコンテナー レジストリは、コンテナー イメージだけでなく、コンテンツ・タイプをデプロイするための主な手段になりつつあります。 どのクラウドも、オンプレミスやクラウド プロバイダー内の非公開あホスティングで利用可能なオープン ソース プロジェクトやベンダー製品のレジストリを提供している。 コンテンツは、レジストリ内およびそれらの間で、初期ビルドから運用環境デプロイに昇格されます。

レジストリに送られたコンテンツが、レジストリから取得するときも同じコンテンツであるかどうかを確認する方法 イメージ署名ソリューションを採用すると、信頼されたレジストリからのみデプロイが送られ、信頼されたコンテンツがデプロイされます。

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

クラスターのセキュリティは、以下に関係します。

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

主なリスク

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

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

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

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

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

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

リスクの対処法

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

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

コンテナーが実行されているホストに関係なく、コンテナーがデータに適切にアクセスできるようにする暗号化方法を使用します。 これらの暗号化ツールによって、他のコンテナーがデータに無許可でアクセスするのを (それに対するアクセス権がない同じノード内の場合であっても) 防止する必要があります。

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

機密レベルによってノードの特定セットにデプロイを分離するために、テイントと容認を使用できます。 機密レベルが高いワークロードと機密レベルが低いワークロードを同じノード内でホストすることを回避します。 別々のマネージド クラスターを使用した方が安全です。

目的、機密度、スレッドの状態別にコンテナーをセグメント化することで、機密ワークロードの保護を強化します。 このようにコンテナーをセグメント化することで、攻撃者は 1 つのセグメントにアクセスできたとしても、他のセグメントにアクセスするのが困難になります。 この構成により、キャッシュやボリューム マウントなどの残存データが、機密レベルによって分離されるという追加の利点も得られます。

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

  • 実行されるアプリケーションに、セキュリティで保護された環境を提供します。
  • ノードがクラスターに安全に追加されるようにします。
  • ライフサイクル全体のセキュリティ確保に役立つ永続的な ID を持たせます。
  • ネットワークやノードを含めて、クラスターの状態について最新で正確な情報を提供する。

クラスターのパフォーマンスに影響を与えることなく、侵害されたノードをクラスターから簡単に分離して削除できるようにする必要があります。 AKS では、これを簡単に行うことができます。

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

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

ノードのセキュリティ

ノードのセキュリティは、以下に関係します。

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

主なリスク

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

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

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

また、ユーザーが、AKS コントロール プレーン経由ではなく、ノードに直接サインインしてコンテナーを管理する場合、ユーザーのアクセス権が不適切に設定されていると、セキュリティ リスクが発生する可能性があります。 直接サインインすると、ユーザーは自分がアクセスできるはずのアプリケーション以外にも変更を加えることができます。

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

リスクの対処法

SSH アクセスを制限することで、ノードのアクセスを制限します。

AKS ノードでコンテナー固有の OS を使用すると、他のサービスおよび機能が無効化されるため、通常、攻撃面が減少します。 また、読み取り専用のファイル システムを備えており、既定でその他のクラスター強化プラクティスが導入されます。

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

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

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

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

アプリケーションのセキュリティは、以下に関係します。

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

主なリスク

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

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

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

別の攻撃ベクトルでは、イメージ ファイル システム内に直接埋め込まれたパスワードや接続文字列などのシークレットが使用されます。 このやり方は、イメージにアクセスできる人なら誰でも秘密にアクセスできてしまうため、セキュリティ リスクを引き起こす可能性があります。

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

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

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

設計の推奨事項

重要

Microsoft Defender for Cloud のイメージ スキャンは、Container Registry エンドポイントとは互換性がありません。 詳しくは、「Private Link を使用したコンテナー レジストリへの非公開接続」を参照してください。