コンテナ脅威検出の総合ガイド

翻訳者 |トゥ・チェンイエ

校正：孫淑娟

コンテナ化されたクラウドネイティブアプリケーションを脅威から保護するための重要なポイント

はじめに: コンテナ アプリケーションの急激な増加に伴い、チームが適切なセキュリティと脅威管理のインフラストラクチャとプラクティスを確保することがこれまで以上に重要になっています。この Refcard では、一般的なクラウド セキュリティ アーキテクチャや Kubernetes 強化ガイドラインなど、いくつかの重点分野にわたって、コンテナ化された環境の脅威検出について包括的に説明します。この Refcard の中核となるのは、リソース制限、静的イメージの脆弱性スキャン、構成の検証などの概念を含む、コンテナの脅威検出の基礎です。

1 はじめに

今日では、コンテナ化されたソリューションは、クラウドネイティブ アプリケーション開発の事実上の標準となっています。 Docker、containerd、CRI-O、Kubernetes などのツールは、コンテナ オペレーティング システムの分野をリードしています。何百万もの開発チームやアーキテクチャ チームが、製品の構築にコンテナ ベースのソリューションを選択しており、著名なクラウド プロバイダーは、Kubernetes、Docker、その他のコンテナ オーケストレーション プラットフォームに基づく幅広いサービスを提供しています。

コンテナの採用が増加するにつれて、セキュリティと脅威の管理がこれまで以上に重要になります。 Cloud Native Computing Foundation (CNCF) と国家安全保障局 (NSA)/CISA のガイダンスによると、

• セキュリティ上の問題や脅威のほとんどは、開発者の 56% がコンテナをスキャンしていないために発見されました。
• ガートナーは、2023 年までに 70% 以上の企業がコンテナ化されたアプリケーションを実行するようになると予測しています。
• Red Hat の 2022 年のレポートによると、Kubernetes のセキュリティ問題の少なくとも 59% は構成ミスに関連しています。

この Refcard では、コンテナ化された環境に関する以下の主要なセキュリティと脅威検出のトピックについて説明します。

• Docker、containerd、CRI-O などのよく知られたコンテナ オーケストレーション プラットフォームと、それに伴うセキュリティ上の課題を紹介します。
• クラウドネイティブのセキュリティとコンプライアンス標準の概要
• 脅威検出ツールの選択基準の紹介
• OWASP および Kubernetes セキュリティ ガイドラインを含むコンテナ脅威検出の基本
• Azure、AWS、Google Cloud をベースにした安全なクラウド アーキテクチャの例

2 クラウドネイティブセキュリティアプローチの概要

コンテナのクラウドネイティブ セキュリティは、4 層のセキュリティ境界 (4C とも呼ばれます) として表現されます。 4 つのレイヤーは、コード、コンテナ、クラスター、クラウドで構成されます。下の図 1 に示す 4C を参照してください。

図 1: クラウド ネイティブ セキュリティの 4C (クラウド、クラスター、コンテナ、コード)

コード

図 1 に示すように、コードだけでなくクラウド、クラスター、コンテナ レイヤーでもセキュリティを適用する必要があるため、コードは最も内側のレイヤーになります。ただし、コードには次のような脆弱性に対するバックドアを含めないでください。

• すべての通信はTLSまたはmTLS経由で行う必要があります
• 依存関係をスキャンし、コードの静的分析を提供します
• すべての共通ポートへのアクセスを制限する

容器

コンテナとそのコンテナ環境は、クラウドネイティブ セキュリティ ソリューションの基本的なコンポーネントです。現在、アプリケーションは Docker だけでなく、containerd、CRI-O、その他の同様のプラットフォームもベースにしています。コンテナ プラットフォームに適用できる一般的なセキュリティ ルールがいくつかあります。

• コンテナの脆弱性をスキャンし、セキュリティスキャンツールを使用する
• 最小権限の原則を使用する
• コンテナ実行中にユーザーを分離する
• ルート権限を無効にする
• リソース制限の導入

クラスタ

コンテナ オーケストレーターは、すべてのアプリケーション コンテナとサービスを管理するため、セキュリティにとって重要です。 Kubernetes は広く使用されているコンテナ オーケストレーション プラットフォームであり、その脆弱性は次のような長いセキュリティ ガイドラインのリストの対象となります。

• RBAC と認証ポリシー
• アプリケーションシークレット管理
• ネットワーク戦略
• TLS アクセス
• ポッドの安全基準

クラウドとインフラストラクチャ

有名なクラウド プロバイダーはすべて、アプリケーション クラスターを保護するためのセキュリティ ガイドとリソースを備えています。たとえば、 Azure には、インフラストラクチャ内で脅威を検出するためのロジックを提供する Sentinel や Defender For Cloud などの強力なプラットフォームがあります。 AWS Security Hub は、AWS 内のリソースのセキュリティ検証を自動化するクラウドセキュリティ管理サービスです。すべてのセキュリティ検証とチェックは、AWS の基本的なセキュリティベストプラクティス標準に基づいています。

最後に、Google Cloud には、セキュリティ コマンド センターの一部としてセキュリティ脅威検出が含まれています。 Security Command Center は、脆弱性と脅威を集中的に報告するサービスです。脅威の検出だけでなく、脆弱性スキャンのオプションも含まれています。

図 2: Google Cloud セキュリティ コマンド センター

さらに、オープンソースおよびサードパーティのクラウド セキュリティ ツールは、特にマルチクラウドまたはハイブリッド クラウド環境を扱う場合には検討すべき強力なオプションです。クラウドセキュリティに加えて、インフラストラクチャに重点を置くことも重要です。 Kubernetes を使用する場合は、次のような重要な側面に注意する必要があります。

• Kubeコントロールパネル、ノード、パブリックネットワーク、特にクラスターネットワークへのアクセス
• Kubernetes クラウド プロバイダーの権限ポリシーの設定
• 最小権限の原則を採用する
• etcd クラスターへのアクセスを制限し、TLS 経由で暗号化を提供する

これについては、次のセクションでクラウドとインフラストラクチャのセキュリティについて学ぶときにさらに詳しく説明します。

3 一般的なクラウド セキュリティ アーキテクチャ

クラウド インフラストラクチャは、クラウド ネイティブ アプリケーションの基本的な構成要素です。このセクションでは、フルスタックのセキュリティと脅威検出オプションを提供する主要なクラウド プロバイダーをいくつか紹介します。

AWS セキュリティセンター

AWS Security Hub は、さまざまな AWS サービスからのアラートを集約、優先順位付け、管理するためのオプションを備えたセキュリティサービスです。 AWS セキュリティセンターは次の目的で使用できます。

• Amazon S3 バケット
• 機密データを含む S3 バケット
• Amazon マシンイメージ (AMI)
• AWS サービスアカウント
• Amazon EC2 インスタンス

さらに、AWS セキュリティセンターは、自動化されたテレメトリ修復や、電子メール、SMS、さらにはチケットシステムなどのカスタムアクションを通じて自動化を支援します。 AWS の最大の利点は、AWS リージョン内のすべての AWS アカウントを統合して表示できることです。

AWS セキュリティセンターの検出システムを使用したシンプルな AWS アーキテクチャを見てみましょう。

図3: AWS セキュリティセンターの検出システム

上記のアーキテクチャは、AWS Security Hub と Cloud Watch の統合を示しています。 Cloud Watch ルールはイベントをトリガーし、イベントは Lambda 関数と統合されます。したがって、特定の関数が AWS セキュリティセンターからのイベントを処理します。

AWS Security Hub の作成と構成は、次の Terraform モジュールを使用して簡単に自動化できます。

モジュール「security_hub」 {
ソース= "clouddrove/security-hub/aws"
バージョン= "1.0.1"
名前= "セキュリティハブ"
セキュリティハブが有効= true

 #メンバーアカウント追加
enable_member_account =有効
メンバーアカウントID = "123344847783"
メンバーメールID = "[email protected]"

 #標準
有効な標準= [
 「標準/aws-基礎セキュリティベストプラクティス/v/1.0.0」 、
 「ルールセット/cis-aws-foundations-benchmark/v/1.2.0」
 ]
 ＃製品
有効な製品= [
 「製品/aws/guardduty」 、
 「製品/aws/インスペクタ」 、
 「製品/aws/macie」
 ]
    }

このモジュールを通じて、開発者はメンバーアカウントを設定し、ルールセット (AWS-foundations-security-best-practices など) を実装し、AWS 製品を有効にすることができます。

コンテナー向け Azure Defender

Azure Defender for containers は、洗練されたクラウドネイティブ セキュリティ サービスです。これには、コンテナー監視、コンテナー レジストリ アドバイザリ サービス、AKS クラスター セキュリティ ツールセットが含まれます。 Azure Defender には、AKS セキュリティ強化機能が含まれています。これにより、ワーカー ノードとコントロール パネルに Defender エージェントを直接設定して、セキュリティと脅威の検出を実行できるようになります。

Azure Defender には、脅威とセキュリティの脆弱性に関する大規模なデータベースがあります。そのため、Azure Defender は UI ダッシュボードを Azure Portal に統合します。ダッシュボードから、クラスターのセキュリティの問題を監視し、セキュリティ チェックを修正できます。確認するには、 Azure Defender のドキュメントにアクセスしてください。

Azure Defender を使用してコンテナーを保護する場合は、エージェントの自動構成機能を使用します。これを行うには、自動構成ウィンドウでログ分析と脆弱性評価の拡張機能を有効にします。

以下の図 4 の Azure Defender のクラウド展開アーキテクチャを参照してください。これは、 eBPFテクノロジーに基づくDefender プロファイルを介して展開されます。

図 4: Azure Defender for AKS クラスター

アーキテクチャには次のコンポーネントが含まれます。

• DeamonSet (azuredefender-collector-ds-*、azuredefender-publisher-ds-*) は、クラスター環境のセキュリティ イベントとテレメトリ情報を収集するために使用されるコンテナーのセットです。
• 収集したデータを Defender バックエンドに公開するために (azuredefender-publisher-ds-*) アプリケーションをデプロイします。

Bicep テンプレートを使用して、コンテナーに Defender をデプロイします。

ターゲットスコープ= 'サブスクリプション'

 var enableSecurityCenterFor = [
 'Kubernetesサービス'
 ]

リソースsecurityCenterPricing 'Microsoft.Security/pricings@2018-06-01' = [ enableSecurityCenterFor のname : {
名前:名前
プロパティ: {
価格設定層: 「標準」
 }
 }]

上記のように、Defender は引き続き Security Center という名前になっています。テンプレートは非常にシンプルで、enableSecurityCenterFor セクションが含まれています。このセクションには、Defender が有効になるサービスと securityCenterPricing セクションが含まれています。このセクションは、Defender リソースの定義です。

Google クラウド AppArmor

最後に、 Linux カーネル セキュリティ上に構築されたセキュリティ モジュールであるAppArmorについて説明します。セキュリティ プロファイルに基づいて、オペレーティング システムで実行されるプロセスを制限します。セキュリティ プロファイルを使用すると、ネットワーク通信とアクティビティ、ファイル、ストレージを制限できます。

Docker コンテナの場合、デフォルトのセキュリティ プロファイルを使用し、次のコマンドでデフォルトの Docker プロファイルを実行できます。

 docker run --rm -it debian : jessie bash -i​​

このコードは、読み取りが発生したときに /proc/sysrq-trigger へのアクセスを制限します。

独自のセキュリティ構成ファイルを作成するには、次のサンプル コードを使用します。

 cat > /etc/ apparmor 。 d / no_raw_net << EOF
 #include <調整可能/グローバル>

プロファイルなし- pingフラグ= ( attach_disconnected 、 mediate_deleted ) {
 #include <抽象/ベース>

ネットワークinet tcp 、
ネットワークinet udp 、
ネットワークinet icmp 、

ネットワーク生を拒否、
ネットワークパケットを拒否する、
ファイル、
マウント、
 }
終了

このコード ブロックは、raw ネットワークおよびパケット ネットワークへのアクセスを制限しますが、tcp、udp、および icmp プロトコルへのアクセスは許可します。

Azure、AWS、Google Cloud が提供するサービスと機能を理解することは、効率的で安全なコンテナ化されたアーキテクチャを構築できるため重要です。

4 コンテナのセキュリティと脅威検出について

すべてのコンテナ エンジンは、コンテナ ランタイム エンジン (CRE) に基づいています。 Docker は最も広く使用されている CRE の 1 つです。ただし、セキュリティと Kubernetes 対応ソリューションの点では、Docker が常に適切な選択であるとは限りません。コンテナや CRI-O などの他のオプションもあります。これらのオプションを簡単に見てみましょう。

コンテナ

Docker は CLI、ストレージ管理、複雑なネットワーク、権限ロジックなどを含む統合ツールであるため、これらのツールは Kubernetes の脆弱性攻撃に対して大きなオーバーヘッドと攻撃対象領域を生み出します。これらの問題を念頭に置いて、Docker はコンテナ ランタイムをcontainerdという別のプロジェクトに抽出しました。 Containerd は Docker よりもはるかに小さく、イメージ転送ロジックを管理するための低レベルのストレージを提供します。 containerd は CNCF の一部です。

クリオー

CRI-O はcontainerd よりもさらに深く、ネイティブで軽量な CRI を提供します。 CRI-O には、Kubernetes 上で実行される追加のレイヤーは含まれません。 Kubelet は CRI-O ランタイムと直接通信してイメージをプルします。以下の図 5 の Docker レイヤー、コンテナ レイヤー、CRI-O レイヤーを参照してください。

図5: Docker層、コンテナ層、CRI-O層

Docker、コンテナ、CRI-O のセキュリティ面

コンテナ化された環境を標的とする多くの攻撃と脅威は、Docker、コンテナ、CRI-O に関しては同じシナリオに基づいています。例えば：

• 隣接するコンテナを攻撃するためにCPU、RAM、ディスク使用量を増やす
• コンテナのルート権限を使用してホストネットワークを公開し、特権フラグを適用する
• イメージまたはKubernetes構成にシークレットをハードコーディングする
• Linux カーネルの脆弱性
• いわゆる中間者攻撃を含む悪意のある画像や偽の画像の使用

Docker は複数のレイヤーを持つモノリシック アーキテクチャであるため、上記のすべてのシナリオの影響を受けます。例えば：

•   CVE-2020-8554 ​​- この脆弱性により、攻撃者は ClusterIPs サービスを作成してクラスターにアクセスできるようになります。
• Siloscape - Windows コンテナー内のマルウェア。 Silocape は、機密データや CPU、GPU、ストレージ リソースを含む Kubernetes クラスター全体へのバックドアを作成します。
• CVE-2018-15664​​ - ルート権限による Docker システムへのアクセス。

Containerd はより軽量なエンジンです。 Docker のレイヤーは多く含まれていません。ただし、audit_write、mknod、net_raw、sys_chroot などの Linux 機能も備えています。 Containerd は、汚染されたイメージやコンテナのエスケープなどの攻撃対象領域に対して、ホスト ネットワーク コンテナへのバックドアを提供します。

CRI-O には Docker のようなレイヤーが含まれていません。これは、開発チームがバックドアを提供する不要な Linux 機能をすべて除外したためです。ただし、CRI-O には、cgroupのメモリ不足 (OOM)状況につながる脆弱性もいくつか含まれており、その結果、コンテナーとイメージに TLS 接続ができなくなります。

覚えておいてください: 脅威はCVE レポートで確認できます。

コンテナ脅威検出の5つのポイント

チームは、これらのコアコンセプトに従うことで、脅威やセキュリティの脆弱性を軽減または完全に排除できます。

Dockerネットワーク

Docker ネットワークは Docker インフラストラクチャの複雑な部分であり、その仕組みを理解することが重要です。 Docker ネットワーク ドライバーとは何かを理解することが重要です。次に例を示します。

• 橋
• ホスト
• オーバーレイネットワーク（訳者注：オーバーレイ（オーバーレイネットワーク、オーバーレイネットワークとも呼ばれる）とは、簡単に言えば、物理ネットワークの上に論理ネットワークを構築することです。一般的な枠組みの中で、基本ネットワークに大規模な変更を加えることなく、ネットワーク上でのアプリケーションの搬送を実現でき、他のネットワークサービスから分離することができます。制御プロトコルを通じてエッジネットワークデバイスのネットワークを構築・拡張します。SD-WANやデータセンターなどのソリューションで使われる中核的なネットワーク技術です。）

デフォルトでは、コンテナのネットワーク スタックは別のコンテナのネットワーク スタックにアクセスできません。ただし、ブリッジまたはホストが他のコンテナーまたは外部ネットワークからのトラフィックを受け入れるように構成されている場合、攻撃の潜在的なセキュリティ バックドアが作成される可能性があります。また、 set flag -icc=false を使用して、 Docker デーモンでコンテナ間通信を無効にすることもできます。

リソース制限の設定

Docker はデフォルトでこのオプションを提供しないコンテナであるため、 Docker コンテナにメモリと CPU の制限を設定することは非常に重要です。これは DoS 攻撃を防ぐ効果的な方法です。たとえば、コンテナがすべてのメモリを消費するのを防ぐためにメモリ制限を設定できます。 CPU 制限にも同じことが当てはまります。さらに、Kubernetes レベルでリソース制限を設定するオプションもあります。これについては、以下の Kubernetes 強化ガイドのセクションで詳しく説明します。

コンテナイメージ内の機密データを避ける

この原則は、すべての機密データをコンテナから移動するために非常に重要です。機密情報やその他の機密データを管理するために、さまざまなオプションを使用できます。

• Docker シークレットを使用すると、イメージの外部にシークレットを保存できます。
• Kubernetes で Docker コンテナを実行する場合は、 Secretsを使用してパスワード、証明書、その他の機密データを保存します。
• 機密データには、 Azure Key VaultやAWS Secrets Managerなどのクラウド固有のストレージを使用します。

脆弱性と脅威の検出ツール

脆弱性スキャン ツールは、セキュリティ上の欠陥が含まれている可能性のある画像を検出する上で重要な役割を果たします。さらに、適切なツールを CI/CD プロセスに統合することもできます。サードパーティベンダーといくつかの一般的なオープンソースツールがこの機能を提供します。これらのオープンソース ツールの例については、「コンテナのセキュリティと脅威の検出について」のセクションをご覧ください。

コンテナレジストリ

イメージを保護するには、追加のセキュリティ レイヤーを作成し、保護されたレジストリからのイメージを使用します。オープンソース レジストリの例をいくつか示します。

Harbor ​​- Docker 成果物に適用されたセキュリティ ポリシーに基づいて、脆弱性スキャン機能を統合したオープン ソース レジストリ。

Quay - イメージの脆弱性をスキャンするオープンソースのイメージレジストリ。 Quay は RedHat によってサポートされており、スタンドアロンのミラー リポジトリも提供しているため、組織内でインストールして使用できます。以下では、コンテナの脆弱性をスキャンする方法について詳しく説明します。

最小権限の原則

この原則は、コンテナを操作するために管理者 (admin) ユーザーを使用しないことを意味します。代わりに、この特定のコンテナでのみ操作できる管理者権限を持つユーザーを作成する必要があります。グループにさらにユーザーを追加できます。 Docker Engine のセキュリティドキュメントをお読みください。ユーザーとグループを作成する方法の例を次に示します。

実行groupadd -r postgres && useradd --no -log -init -r -g postgres postgres​​​​​​
ユーザーpostgres

また、ユーザーとグループを作成するときは、必ず正式に検証され署名されたイメージを使用してください。イメージを見つけて確認するには、Docker Trust Check を使用します。その他のオプションとツールについては、以下の「コンテナの脅威検出ツールを選択するための基準」セクションを参照してください。

Linux セキュリティ モジュール

セキュリティを強化するには、デフォルトの Linux セキュリティ プロファイルを使用し、デフォルトのプロファイルを無効にしないでください。 Docker の場合は、 AppArmorまたはSeccomp を使用できます。 Kubernetes のセキュリティ コンテキスト ルールは、コンテナの権限を制御する機能を持つ allowPrivilegeEscalation を使用して設定することもできます。さらに、readOnlyRootFilesystem フラグは、コンテナのルート ファイル システムを読み取り専用モードに設定します。

静的イメージの脆弱性スキャン

脅威検出ツールがどのように連携し、どのような戦略を使用できるかを理解したところで、静的イメージの脆弱性スキャン、機密性スキャン、構成検証の意味を定義しましょう。静的セキュリティ脆弱性スキャンは、OCI（ ​​Open Container Initiative ​​）形式に基づいています。 CVE Tracker ​​、 Red Hat Security Data ​​、 Debian Security Vulnerability Tracker​​ などのよく知られた脅威および脆弱性情報ソースに対してイメージを検証し、インデックスを作成します。

静的脆弱性スキャン メカニズムを使用すると、次のような複数のソースをスキャンできます。

• コンテナイメージ
• ファイルシステムとストレージ
• Kubernetes クラスター

静的イメージの脆弱性スキャンでは、誤った構成、シークレット、ソフトウェアの依存関係をスキャンし、ソフトウェア部品表 ( SBOM) を生成することもできます。 SBOM は、アプリケーション内のオープンソースおよびサードパーティのツールとコンポーネントを組み合わせたもので、すべてのコンポーネントのライセンス情報が含まれています。この情報は、セキュリティ リスクを迅速に特定するために非常に役立ちます。

以下に、上記で説明したロジックをカバーするオープンソース ツールの一覧を示します。使用できるツールは数多くありますが、ここではそのほんの一部を紹介します。

• Clair ​​- 開発統合を目的とした API を備えたセキュリティ脆弱性スキャン ツール。独自のダイバーを作成して、Clair の機能を拡張およびカスタマイズすることも可能です。 Clair には、 Indexer 、 match 、 notify 、combo のモデルがいくつかあります。
•   Trivy - CVE 脅威データベースに基づく安全なコンテナ スキャナー。 Trivy は、npm、apt-get、brew、その他のパッケージ マネージャーを使用して、PC または Kubernetes ノードにインストールできます。

1. apt-get インストール trivy   
2. yum インストール trivy
3. brew をインストール aquasecurity/trivy/trivy

次のコマンドを使用して画像をスキャンします。

 $ trivyイメージアプリ-バックエンド: 1.9 -テスト

静的イメージの脆弱性スキャンのもう 1 つの鍵は、セキュリティ コンテンツ自動化プロトコル (SCAP) です。 SCAP は、Linux ベースのインフラストラクチャのセキュリティ コンプライアンス チェックを定義します。 OpenSCAP​​ は、高度なセキュリティ監査オプションを備えたツールです。 SCAP ドキュメントのスキャン、編集、エクスポートが可能で、次のコンポーネントとツールが含まれています。

• OpenSCAP Base - 脆弱性と構成のスキャン用
• oscap-docker - コンプライアンススキャン用
• SCAP Workbench - 典型的な OpenSCAP タスクを実行するためのグラフィカル ユーティリティ

SCAP コンテンツ検証プロセスを実行する方法の例を次に示します。

 oscap ds sds - scapを検証- ds.xml

構成の検証

静的イメージ検証は、脅威検出プロセスの重要な部分です。ただし、静的イメージスキャンでは、YAML および JSON 構成の誤った構成を検出できず、複雑な YAML 構成で破損が発生する可能性があります。したがって、簡単で自動化されたアプローチを実現するには、Kubeval のような構成検証およびスキャン ツールが必要です。構成検証を導入することで、静的構成の問題を解決し、自動化プロセスを簡素化できます。

例として、開発ワークフローの一部としてローカルで、または CI/CD パイプラインでよく使用される、1 つ以上の Kubernetes 構成ファイルを検証するためのオープンソース ツールであるKubevalを組み込みます。

検証を実行するには、次の例を使用します。

 $ kubeval my -無効- rc .yaml
警告-フィクスチャ/ my -無効- rc 。 yamlに無効なReplicationController - specが含まれています。レプリカ:無効なタイプです。期待値: [整数、 null ]、指定値:文字列
$エコー$ ?
 1

シークレットスキャン

シークレット スキャンの主な目的は、コンテナ イメージ、コードとしてのインフラストラクチャ ファイル、JSON ログ ファイルなどを調べて、ハードコードされたデフォルトのシークレット、パスワード、AWS アクセス ID、AWS シークレット アクセス キー、Google OAuth キー、SSH キー、トークンなどを探すことです。

管理コンソールとセンサーエージェント

管理コンソールは、セキュリティ インフラストラクチャの概要を構築し、脆弱性と脅威のレポートを提供する UI ツールです。一方、センサー エージェントは、クラスター ノードをスキャンし、セキュリティ テレメトリ データを収集するツールです。したがって、センサー エージェントはテレメトリを管理コンソールに報告します。

たとえば、AKS クラスターにセンサー エージェントをインストールするには、次の原則に従う必要があります。

 helmリポジトリにdeepfenceを追加しますhttps://deepfence-helm-charts.s3.amazonaws.com/threatmapper
 helm show readme deepfence / deepfence -エージェント
helm値を表示deepfence / deepfence -エージェント

#ヘルムv2
 helmインストールdeepfence / deepfence -エージェント\
 --name = deepfence -エージェント\
 -- managementConsoleUrl = xを設定します。バツ。バツ。 x \
 -- deepfenceKeyをC8TtyEtNB0gBo1wGhpeAZICNSAaGWw71BSdS2kLELY0に設定します

たとえば、AKS クラスターにセンサー エージェントをインストールするには、次の原則に従う必要があります。

 helmリポジトリにdeepfenceを追加

https://deepfence-helm-charts.s3.amazonaws.com/threatmapper

 helmインストールdeepfence -コンソールdeepfence / deepfence -コンソール

インストールを完了するには、次の 2 つの手順が必要です。

• https://deepfence-helm-charts.s3.amazonaws.com/threatmapper から Helm パッケージをダウンロードします。
• Helm パッケージをクラスター名前空間に直接インストールする

どちらのコマンドも非常にシンプルで、IaC プロセスに簡単に統合できます。

6 Kubernetes 強化ガイド

Kubernetes は最も人気のあるオーケストレーション プラットフォームであるため、頻繁なセキュリティ調整が必要です。そのため、NSA はK8 強化ガイドラインを策定しました。 NSA の強化ガイドラインに基づいて、最も一般的なセキュリティ ルールを調べてみましょう。

ネットワーキングとネットワーク戦略

Kubernetes ネットワーク モデルの仕組みを理解することは、ポッド間の適切なネットワーク通信を設定したり、開いているポートを作成したり、ノードに直接アクセスしたりする上で非常に重要です。ネットワーク ポリシーは、この通信を整理するのに役立ちます。

ポッドの受信トラフィックと送信トラフィックを確保する

Pod の入出力トラフィックを保護する場合は、すべてのトラフィックを拒否してからポートを 1 つずつ開くと便利です。 Istio のようなサービス メッシュを使用すると、サービスの追加レイヤーが追加され、トラフィック フローが自動化され、監視が容易になるため、便利です。ただし、サービス メッシュを使用すると複雑さが増す可能性があるため、注意が必要です。

強力な認証および承認ポリシー

• トランスポート層セキュリティの適用 - Kubernetes クラスター内のサービス間の通信には、トランスポート層セキュリティ (TLS) を使用する必要があります。
• RBACと最小権限の原則を採用します。
• Kubelet へのアクセスを制限する - ツールを使用するための認証と承認を有効にします。 Kubelet にアクセスできるのは管理者のみです。

ログ監査の使用

Kubernetesダッシュボード監査を有効にして、セキュリティ チームに完全な情報を提供します。通常、これはログを監視プラットフォームに転送することによって実現されます。

設定ミスがないか確認する

誤った構成を確認するには、自動化された方法と構成スキャン ツールを使用できます。 CNCF プロジェクトのOpen Policy Agent を使用すると、誤った構成の作成を防ぐセキュリティ ポリシーを作成できます。

たとえば、最新のタグが付いたコンテナの実行を拒否するには、次のようにします。

パッケージK ubernetes

データをインポートします。 Kubernetes
データをインポートします。 libをlとして

チェック03 : = "K8S_03"

例外[ルール] {
例外処理( check03 )
ルール= [ “最新タグの使用法” ]
 }

最新タグの使用を拒否[メッセージ] {
ウベルネテス。コンテナ​
 [ image_name , “latest” ] = ubernetes . split_image (コンテナ.イメージ)
 msg = ubern ( " % s : % s内の% sには、最新のタグを使用したイメージ% sがあります。詳細情報: % s " , [ check03 , container . name , ubernetes . kind , image_name , ubernetes . name , l . get_url ( check03 )])
 }

より多くのポリシー例については、「Open Policy Agent ポリシー」を参照してください。

侵入検知システムとセキュリティ情報システムの導入

侵入検知システムは、Kubernetes セキュリティ システムの重要な部分です。これらのシステムは、ホストの動作を調べて疑わしいアクティビティや異常なトラフィックがないか確認し、管理者に警告します。

コンテナ脅威検出ツールの選択基準7つ

ツールとプラットフォームは、脅威検出基盤の重要なコンポーネントです。次のサービスを含め、脅威検出オプションを備えたクラウド ネイティブ プロバイダーやオープン ソース ツールは数多くあります。

• 静的イメージの脆弱性スキャン
• 構成の検証
• シークレットスキャン

問題は、アーキテクチャに適したセキュリティ ツールをどのように選択するかということです。適切な脅威検出ツールを選択するための要件と戦略をいくつか確認してみましょう。

オープンソースのツールとサービスを組み合わせてモデル アーキテクチャを構築するオンプレミスのハイブリッド シナリオの次の例を見てみましょう。

脅威検出アーキテクチャの例

オープンソースのセキュリティ ツールの使用例として、Kubernetes クラスターから始めます。クラウド プロバイダー (またはオンプレミス) を使用してデプロイできます。サンプル アーキテクチャには、次のオープン ソース プラットフォームが含まれています。

Cadvisor ​​- 脆弱性を検出するために使用されます。

Grafana - すべてのコンポーネントをインポートしてダッシュボードとアラートを構築および構成します。

Prometheus - CPU、GPU、メモリ、イメージ、その他のメトリックを監視するための強力なオープン ソース オプション。

Kube-bench - Kubernetes クラスター内の脅威とセキュリティの問題を検出します。セキュリティ チェックは CIS Kubernetes ベンチマークに基づいています。

図6: 脅威検出アーキテクチャの例

kube-bench を構成するには、YAML ファイルを使用します。たとえば、以下にリストされている YAML ファイル。これは、単一のポッドに対して検証プロセスを実行するために使用されます。

 -- -
 apiバージョン:バッチ/ v1
種類:仕事
メタデータ:
名前:キューブ-ベンチ
仕様:
テンプレート：
メタデータ:
ラベル:
アプリ: kube -ベンチ
仕様:
ホストPID : true
コンテナ:
 -名前:キューブ-ベンチ
イメージ: docker .io / aquasec / kube -ベンチ: v0.6.8
コマンド: [ "kube-bench" ]
ボリュームマウント:
 -名前: var - lib - etcd
マウントパス: /var/ lib / etcd
読み取り専用: true
 -名前: var - lib - kubelet
マウントパス: /var/ lib / kubelet
読み取り専用: true
 -名前: var - lib - kube -スケジューラ
マウントパス: /var/ lib / kube -スケジューラ
読み取り専用: true
 -名前: usr - bin
マウントパス: /usr/ local / mount - from - host / bin
読み取り専用: true
 -名前: etc - cni - netd
マウントパス: /etc/cni/net.d/
読み取り専用: true
 -名前: opt - cni - bin
マウントパス: /opt/ cni / bin /
読み取り専用: true
 …
再起動ポリシー:なし
巻数:
 -名前: var - lib - etcd
ホストパス:
パス: "/var/lib/etcd"
 -名前: var - lib - kubelet
ホストパス:
パス: "/var/lib/kubelet"
 …

このドキュメントの内容をjob.ymalファイルに保存し、applyコマンドを使用して実行してみましょう: $ kubectl apply -f job.yaml

完全版はここからご覧いただけます。

8 結論

この Refcard では、コンテナ化されたクラウドネイティブ アプリケーションの脅威と脆弱性の検出メカニズムに関する完全なガイドを紹介します。この Refcard には、クラウド ネイティブ環境のセキュリティ ベースラインから Kubernetes の強化ガイドまで、クラウド ネイティブ アプリケーション向けの安全なコンテナ化アーキテクチャの構築を開始するために必要なものがすべて揃っています。

翻訳者について

Tu Chengye は、51CTO コミュニティ エディター、情報システム プロジェクト マネージャー、情報システム スーパーバイザー、PMP、ある省の総合入札評価の専門家であり、15 年の開発経験を持っています。当社は、プロジェクト管理、フロントエンドおよびバックエンド開発、マイクロサービス、アーキテクチャ設計、モノのインターネット、ビッグデータなどに重点を置いています。

原題:コンテナ化されたクラウドネイティブアプリケーションの脅威を防御するための基本事項​​、著者: Boris Zaikin