次の方法で共有

ワークロードをセキュリティで保護する

ワークロードをセキュリティで保護するには、リスクを軽減し、業界標準に準拠するために役立つ方法でコンテナーを構築、デプロイ、実行する必要があります。 この記事では、コンテナーのセキュリティ、ポッドのセキュリティ標準、ワークロード ID に関するガイダンスを提供します。これにより、サプライ チェーンのリスク、未承認のアクセス、クラスター内外の実行時の脅威からアプリケーションを保護できます。

コンテナーを取得、カタログ化、構築するときに、セキュリティで保護されたコンテナーのライフサイクルに従う

ワークロードの取得、カタログ化、構築を行う際は、 Microsoft Containers Secure Supply Chain フレームワーク に従います。 このフレームワークは、信頼されていないソースから保護し、依存関係の侵害を回避し、脆弱性をスキャンするのに役立ちます。

ソフトウェア部品表 (SBOM) を取得または生成して、コードの由来を追跡するために。 コンテナー レジストリでイメージの脆弱性評価を実行できるように Microsoft Defender for Containers を構成することもできます。どのレベル (プレビューまたは一般提供) でサポートされているレジストリの サポート マトリックス を参照してください。

より一般的には、ワークロード アプリケーション ソフトウェアを 開発するときに、セキュリティ開発ライフサイクル に従うことをお勧めします。

ワークロードをデプロイして実行する際に、セキュリティで保護されたサプライ チェーン フレームワークに従う方法に関する ガイダンス も参照してください。

リファレンス

強化された Kubernetes 環境用にコンテナー イメージを準備する

実行時に最小限の特権でコンテナー イメージの実行を促進するには、ワークロードの非ルート実行をサポートするようにコンテナー イメージを作成します。

必要なランタイム コンポーネントを狭く満たす、ディストリビューションレスで専用のコンテナー イメージを使用します。 Microsoft Artifact Registry などの信頼できるベンダーから、ワークロードの基本イメージを選択できます。 ランタイムの依存関係を絞り込むには、補助コンポーネントに対する潜在的な攻撃面と、セキュリティ更新プログラムとバグ修正によるメンテナンスの負担の両方が軽減されます。 複数ステージ ビルドを使用して、ランタイム イメージのフットプリントをさらに減らします。

コンテナー署名を使用して、ワークロード イメージが誤ってまたは悪意を持って改ざんされないようにします。 Azure Pipelines と GitHub Actions には、コンテナー署名をサポートするさまざまなツールが用意されています。 コンテナー署名は、選択した公開キー 基盤 (PKI) と統合できます。

リファレンス

ポッドのセキュリティ標準に従う

ポッドの Kubernetes ポッドセキュリティ標準 に従い、可能な限り制限されたポリシー レベルを目指し、それ以外の場合はベースライン レベルを目指します。 たとえば、コンテナーは非ルート ユーザーとして実行する必要があり、操作に厳密に必要でない限り、ホスト ボリュームをマウントしないでください。 これらの標準を適用する方法に関する 提案 をご覧ください。 Microsoft が提供するすべての拡張機能が、実行する特権操作のために、最も制限されたポリシー レベルを満たすことができるわけではありません。 デプロイ時に追加の機能を許可する必要がある場合があります。

さらに、各ポッドの メモリ制限と CPU 要求を設定 することを検討してください (ただし、望ましくない調整につながる可能性のある CPU 制限ではありません)。 また、各名前空間のリソース クォータも考慮してください。 これらの制限とクォータにより、侵害されたコンテナーや不適切な動作をするコンテナーからのより広範なサービス拒否 (DoS) 攻撃を防ぐことができます。

リファレンス

追加の Linux セキュリティ標準を適用する

追加の保護を提供 する追加の Linux セキュリティ強化フレームワークの 使用を検討してください。 SELinux または AppArmor では、各ワークロードがファイルやポートなどの特定のリソースに対して持つアクセスをより正確に宣言する必要があります。 これらの宣言は、標準の Linux アクセス許可モデルを超えています。 さらに、 seccomp は、各ワークロードが実行できるシステム呼び出しを制限し、ポッドセキュリティ標準の制限付きレベルで既定の seccomp プロファイルが必要です。 これらすべてのセキュリティ強化機能には既定の設定が付属していますが、通常は特定のアプリケーションに合わせてさらに調整できます。 たとえば、ポッドに必要な正確な syscall のみを許可するカスタム seccomp プロファイルを定義できます。

リファレンス

Azure リソースへのアクセスにワークロード ID を使用する

ワークロードでは、 ワークロード ID フェデレーション を使用して、Azure 内のリソース (ストレージ アカウントなど) に安全にアクセスできるようにする必要があります。 この方法は、Azure RBAC での承認に使用される Entra ID ID を認証するために、個別のシークレットを作成して配布する必要を回避するのに役立ちます。 代わりに、このフェデレーション アプローチを使用すると、クラウド内の Entra ID ID のトークンを Kubernetes サービス アカウント トークンから直接取得できます。 (サービス アカウントは、Kubernetes のワークロード用の組み込み ID です)。

クラスターのサービス アカウント トークン発行者は、これらのサービス アカウント トークンを作成して署名します。 そのため、発行者の秘密キーは基本的なシークレットです。 アクセスを制限し、定期的にローテーションする必要があります。

Azure Arc on Azure Local で AKS が有効になっている場合、このアクセス制御は自動的に行います。 API サーバーを実行するノード (トークン発行者を含む) のみがキーにアクセスできます。 キーは 90 日後に期限切れになり、45 日ごとに自動的にローテーションされます。

Arc 対応 Kubernetes 経由で独自のクラスターを接続する場合は、ベンダーの製品で同様の機能が提供されているかどうかを評価します。 サービス アカウント トークン発行者キーへのアクセスが制限されているかどうかを確認し、定期的にローテーションするかどうかを確認します。

ワークロード内またはワークロードとの間で TLS 暗号化と認証を構成する

クラスターの内部と外部の両方で、ワークロードが行うすべての接続に TLS を使用します。 TLS を使用するには、証明書を生成し、これらの接続を確立するために信頼バンドルを配布する必要がある場合があります。

クラスター内の TLS 接続の場合は、 Istio などのサービス メッシュを使用して評価し、TLS 接続を維持します。 Istio などのサービス メッシュ、または DAPR などのアプリケーション ランタイムは、独自の自己署名ワークロード証明書を生成するのに役立ちます。 セキュリティを強化するために、これらのワークロード証明書の署名に使用する クラスター ローカルの中間 CA を構成 することを検討してください。 その場合は、この中間 CA の証明書を公開キー 基盤 (PKI) を使用して発行することも検討してください。この証明書は、ルート証明書自体がオフラインの HSM ベースのコンテナーでセキュリティで保護されたままになります。

クラスターへのイングレス TLS 接続の場合は、受信トラフィックを安全に管理するのに役立つロード バランサーやイングレス/ゲートウェイ コントローラーなどの多くの製品のいずれかを使用して評価します。 これらのエンドポイントを使用するには、独自の証明書を生成する必要がある場合があります。 また、これらの証明書の信頼バンドルを、クラスターへの接続を認証する必要がある外部クライアントに配布する必要がある場合もあります。 ここでも、PKI からこれらの証明書を発行することを検討してください。 cert-manager を使用してこれらの証明書を要求できます。NGINX イングレス コントローラーに対するこの要求のしくみを次に示します。 また、 trust-manager を使用して、信頼を分散させることができます。 または、必要な証明書が少ない場合は、Azure Key Vault で手動で証明書を作成してローテーションし、 Kubernetes 用 Azure Key Vault シークレット ストア拡張機能 (プレビュー) ( "SSE") を使用して Kubernetes シークレットとして同期できます。

生成されると、これらの証明書とそれに付随する秘密キーは、Kubernetes シークレット ストアにシークレットとして格納されます。 これらのシークレットの保護に関するこのガイダンスを参照してください。

クラスター内の接続のクライアント側認証には、mTLS の証明書ではなく、TLS のサービス アカウント トークンを使用することもできます。 その場合は、名前空間ごとに "既定" のサービス アカウントを使用しないことをお勧めします。 代わりに、個別のワークロードまたはコンポーネントごとに専用のサービス アカウント ID を作成します。 これにより、Kubernetes RBAC を使用してサービスまたは API サーバーの承認規則を構成するときに、最小限の特権アプローチが可能になります。

リファレンス

ワークロード/サービスにアクセスするための承認規則を構成する

Kubernetes ワークロード (サービス) に要求を送信できるワークロードに関する承認規則を設定して、ワークロード間のトラフィックを制御することを目指します。

Istio などのサービス メッシュを使用している場合は、各ワークロードに ID 資格情報を自動的に発行できます。 その後、これらの ID を使用して、Kubernetes サービスへのアクセスを指定された呼び出し元のワークロードのみに制限するのに役立つ 承認ポリシーを構成 できます。

または、サービス メッシュを使用していない場合は、独自の資格情報 (証明書またはサービス アカウント トークン) を構成し、 OPA などの専用の承認エンジンをデプロイできます。 OPA を Envoy プラグイン と共に使用して、ワークロードを変更する必要を回避できます。

また、ネットワーク 層でトラフィック制限を適用することも検討してください。

ワークロード テレメトリを維持および監視し、セキュリティ管理 (SIEM) ソリューションに接続する

ワークロード テレメトリを監視ソリューションに送信することを検討してください。監視ソリューションでは、潜在的なセキュリティの問題 (製品のパフォーマンスやデバッグの問題についても同様) を分析できます。

Azure Monitor 拡張機能をエッジ クラスターにデプロイできます。 これらの拡張機能は、Prometheus メトリックを Azure Monitor ワークスペースまたは Container Insights ログに Log Analytics ワークスペースに自動的に送信します。 Prometheus メトリックは、Grafana ダッシュボードを使用して大規模に収集および分析できます。 Container Insights のログとパフォーマンス データは、事前構築済みのビューとブックを使用して収集および分析できます。 この分析を設定するときは、信頼性、コストの最適化、パフォーマンス、およびセキュリティをカバーする クラスターを監視するためのベスト プラクティス に注意してください。

さらに、 エッジ (プレビュー) の Azure Monitor パイプライン 拡張機能には、エッジ クラスターでのテレメトリ収集に関するその他の柔軟なオプションが用意されています。 その機能には、エッジからクラウドへのスケーラブルなルーティング、ローカル データ キャッシュ、遅延クラウド同期が含まれます。これにより、ネットワーク セグメント環境やオフライン環境でも信頼性の高い監視を確保できます。 また、OpenTelemetry Protocol (OTLP) 形式と syslog 形式を使用して、さまざまなリモート ソースやその他のエージェントからテレメトリ データを受信することもできます。

Log Analytics ワークスペースにログが送信されたら、サイバー脅威の検出、調査、対応、プロアクティブハンティングのために Microsoft Sentinel を有効にすることもできます。

リファレンス

次のステップ