Kubescape で Kubernetes を保護する方法

Kubernetes は強力ですが、複雑でもあります。クラスターを攻撃に対して脆弱な状態にしておくことは簡単です。第一の防御線は自動化されたセキュリティ チェックです。

Kubernetes は成長を続けています。最近の調査によると、開発者の間での Kubernetes の採用は 2021 年に驚異的な 67% 増加しました。企業は、クラウドネイティブ アプリケーションの柔軟性と拡張性を享受するために Kubernetes に移行しています。

Kubernetes が企業にとって持つ価値は疑う余地がありませんが、それには代償が伴います。Kubernetes は複雑なため、クラスターが攻撃に対して脆弱な状態になりやすいのです。企業はこれを認識しています。 Red Hat は、Kubernetes セキュリティの現状レポートの中で、回答者の 59% がコンテナ セキュリティを脅威とみなしていると述べています。

継続的インテグレーションとデリバリー (CI/CD) に自動セキュリティ チェックをインストールすることは、本番環境に入る前にすべてのコードが通過する必要がある唯一の場所であり、脅威に対する保護を開始するための最良の方法であり、Kubescape はそれを実現するのに役立ちます。

この記事では、CI/CD パイプラインで Kubescape を実行して、脅威が展開される前に検出する方法を学習します。

Kubescapeの登場

Kubescape は、Kubernetes 用のオープンソースのセキュリティ チェック ツールです。 ARMO によって開発されたこのツールは、Kubernetes クラスターをスキャンし、コンテナを検査し、安全でないデプロイメントを検出することができます。

Kubernetes の実行経験が何年もあるにもかかわらず、企業はクラスターのセキュリティ保護の詳細をまだ学習しているところです。 2019年、暗号通貨マイナーが何らかの方法でJW Playerのクラスターにアクセスし、そのリソースをマイニングに使い始めました。開発者は、原因は権限が昇格されたコンテナにあることを発見しました。この場合、JW Player チームがデプロイメント プロセスで Kubescape を使用していた場合、昇格されたコンテナー権限はデプロイメント前に検出されていたはずです。

Kubescape は、NSA、CISA、Microsoft のセキュリティ ガイダンスに基づいて 70 を超える制御を実装しています。これらのコントロールは、フレームワークと呼ばれる 4 つのカテゴリに分類されます。

• NSA : NSA Kubernetes 強化ガイドに従ってください。これは、アプリケーションのセキュリティに重点を置いたトップダウン フレームワークです。
• MITRE : Microsoft の MITRE フレームワークに従います。 MITRE は主に Kubernetes インフラストラクチャの保護に重点を置いています。
• ArmoBest : ARMO フレームワークは、Kubescape の背後にいる同じ人々によって保守されています。このフレームワークは、MITRE フレームワークと NSA フレームワーク間の盲点をカバーしようとします。
• DevOpsBest : インフラストラクチャとアプリケーション セキュリティの基本をカバーする最小限のフレームワーク。

デフォルトでは、Kubescape はすべてのチェックを実行し、各フレームワークのリスク レベルを出力します。

Kubernetes セキュリティの整合性制御

Kubernetes のセキュリティには 2 つの観点からアプローチできます。最も基本的なレベルでは、攻撃に対して適切に強化する必要があるクラスターがあります。これは、自己管理型およびオンプレミスのインストールでは特に重要です。アプリケーション レベルでは、デプロイメントがベスト プラクティスに従っており、悪用可能な脆弱性が残っていないことを確認する必要があります。

Kubescape による Kubernetes の保護

最初に検討するコントロール セットは、Kubernetes がリソース セットの望ましい状態を記述するために使用するデプロイメント マニフェストのセキュリティ保護です。このマニフェストを分析することで、Kubescape は次の問題を検出できます。

• コンテナ内で実行されている安全でない SSH サービス。
• コンテナ起動コマンドの sudo コマンド。
• コンテナをルートとして実行するか、機能が多すぎる
• 親レプリカセットなしでポッドを実行します。
• Pod は利用可能なすべての CPU とメモリを消費します。

すべてのコントロールと利用可能なフレームワークについては、ArmoSec ドキュメントで確認できます。各コントロールには、低から重度までのリスク レベルが関連付けられています。スキャン プロセスの最後に、Kubescape は 0% (非常に安全) から 100% (安全でない) までのリスク スコアを計算します。

Kubernetes マニフェストのスキャン

Kubescape の動作を見てみましょう。チュートリアルのこの部分では、有効な Kubernetes マニフェストであればどれでも使用できます。例として、このリポジトリのデプロイメント マニフェストを使用します。

• セマフォデモ-nodejs-k8s

Kubernetes マニフェスト ファイルをスキャンするための基本コマンドは次のとおりです。

 $ kubescapeスキャン展開.yml
コントロール: 31 (失敗: 14 、除外: 0 、スキップ: 0 )
 + -- -- -- -- -- + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- - + -- -- -- -- -- -- -- +​​​​
 |重大度|コントロール名|失敗したリソース|除外されるリソース|すべてのリソース| %リスク-スコア|
 + -- -- -- -- -- + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- - + -- -- -- -- -- -- -- +​​​​
 |高|リソースCPU制限とリクエスト| 1 | 0 | 1 | 100 % |
 |高|リソースメモリの制限と要求| 1 | 0 | 1 | 100 % |
 |中|権限昇格を許可する| 1 | 0 | 1 | 100 % |
 |中| CVE - 2022-0492 - cgroups -コンテナー-エスケープ| 1 | 0 | 1 | 100 % |
 |中|構成された活性プローブ| 1 | 0 | 1 | 100 % |
 |中|許可されたレジストリからの画像| 1 | 0 | 1 | 100 % |
 |中|入口と出口がブロックされました| 1 | 0 | 1 | 100 % |
 |中| Linux の強化| 1 | 0 | 1 | 100 % |
 |中|非ルートコンテナー|​ 1 | 0 | 1 | 100 % |
 |低い|構成された準備プローブ| 1 | 0 | 1 | 100 % |
 |低い|不変コンテナファイルシステム| 1 | 0 | 1 | 100 % |
 |低い| K8s の一般的なラベルの使用法| 1 | 0 | 1 | 100 % |
 |低い|リソースのラベル使用法| 1 | 0 | 1 | 100 % |
 |低い|リソースポリシー| 1 | 0 | 1 | 100 % |
 + -- -- -- -- -- + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- - + -- -- -- -- -- -- -- +​​​​
 | |リソースの概要| 1 | 0 | 1 | 40.27パーセント​
+ -- -- -- -- -- + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- - + -- -- -- -- -- -- -- +​​​​

フレームワーク: MITRE (リスク: 0.00)、AllControls (リスク: 40.27)、ArmoBest (リスク: 36.73)、DevOpsBest (リスク: 63.16)、NSA (リスク: 36.99)特定のフレームワークを選択しない場合、Kubescape はすべてのコントロールを評価します。フレームワークを追加できます。例えば：

 $ kubescapeスキャンフレームワークDevOpsBestデプロイメント。 yml

ID コードを一覧表示して、個々のコントロールを実行することもできます。

 $ kubescapeスキャンコントロールC - 0076 、 C - 0004 の展開。 yml

ご覧のとおり、Kubescape はコントロール、そのステータス、および最終的なリスク スコアを含むテーブルを出力します。

Kubernetes クラスターの健全性チェック

Kubernetes のデフォルト構成がセキュリティ問題の約 47% の原因となっているため、ほとんどの自己管理型クラスターは危険にさらされています。 Kubescape は、実行中のクラスターの構成を検査し、潜在的な問題を検出し、修正を提案できます。ツールが実行できるクラスター レベルのチェックの一部を次に示します。

• 安全でないワーカーノードを識別します。
• 管理ダッシュボードなど、公開されている安全でないインターフェースがないか確認します。
• クラスターが既知の CVE の影響を受けているかどうかを検出します。
• 不足しているネットワーク ポリシーを検出します。
• TLS 認証なしで実行されている Kubelet クライアントを探します。

クラスターをスキャンするには、次のコマンドを使用します。

 $ kubescapeスキャン
コントロール: 57 (失敗: 35 、除外: 0 、スキップ: 5 )
 + -- -- -- -- -- -- + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - + -- -- -- -- -- -- -- -- + -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- -- + -- -- -- -- -- -- +​​​​​​​
 |重大度|コントロール名|失敗したリソース|除外されるリソース|すべてのリソース| %リスク-スコア|
 + -- -- -- -- -- -- + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - + -- -- -- -- -- -- -- -- + -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- -- + -- -- -- -- -- -- +​​​​​​​
 |クリティカル|データ破壊| 17 | 0 | 67 | 25 % |
 |クリティカル| Kubeletサービスへの匿名アクセスを無効にする| 0 | 0 | 0 |スキップ* |
 |クリティカル| KubeletクライアントのTLS認証を強制する| 0 | 0 | 0 |スキップ* |
 |高|クラスター-管理バインディング| 1 | 0 | 67 | 1 % |
 |高| Kubernetesシークレットの一覧| 10 | 0 | 67 | 15 % |
 |高|特権コンテナ| 1 | 0 | 6 | 14 % |
 |高|リソースCPU制限とリクエスト| 6 | 0 | 6 | 100 % |
 |高|リソースメモリの制限と要求| 5 | 0 | 6 | 69パーセント​
|高|重大な脆弱性を持つワークロードが外部トラフィックに公開される| 0 | 0 | 0 |スキップ** |
 |高|外部トラフィックにさらされるRCE脆弱性を持つワークロード| 0 | 0 | 0 |スキップ** |
 |高|脆弱性が過剰に存在するワークロード| 0 | 0 | 0 |スキップ** |
 |高|書き込み可能なホストパスマウント| 3 | 0 | 6 | 42パーセント​
|中|コンテナサービスアカウントにアクセスする| 2 | 0 | 2 | 100 % |
 |中|権限昇格を許可する| 5 | 0 | 6 | 69パーセント​
|中|許可されたホストパス| 3 | 0 | 6 | 42パーセント​
|中|サービスアカウントの自動マッピング| 4 | 0 | 8 | 57パーセント​
|中| CVE - 2022-0492 - cgroups -コンテナー-エスケープ| 1 | 0 | 6 | 31 % |
 |中|クラスター内部ネットワーク| 5 | 0 | 5 | 100 % |
 |中|構成された活性プローブ| 1 | 0 | 6 | 14 % |
 |中| CoreDNSポイズニング| 3 | 0 | 67 | 4 % |
 |中| Kubernetesイベントを削除する| 3 | 0 | 67 | 4 % |
 |中|コンテナに実行| 1 | 0 | 67 | 1 % |
 |中|ホストネットワークアクセス| 5 | 0 | 6 | 69パーセント​
|中| HostPathマウント| 4 | 0 | 6 | 56パーセント​
|中|入口と出口がブロックされました| 6 | 0 | 6 | 100 % |
 |中| Linux の強化| 1 | 0 | 6 | 14 % |
 |中|マウントサービスプリンシパル| 4 | 0 | 6 | 56パーセント​
|中|サービスアカウントのない名前空間| 4 | 0 | 7 | 57パーセント​
|中|ネットワークマッピング| 5 | 0 | 5 | 100 % |
 |中|なりすまし禁止| 1 | 0 | 67 | 1 % |
 |中|非ルートコンテナー|​ 6 | 0 | 6 | 100 % |
 |中|ポート転送権限| 1 | 0 | 67 | 1 % |
 |低い|監査ログが有効| 1 | 0 | 1 | 100 % |
 |低い|構成された準備プローブ| 4 | 0 | 6 | 56パーセント​
|低い|不変コンテナファイルシステム| 5 | 0 | 6 | 69パーセント​
|低い| K8s の一般的なラベルの使用法| 6 | 0 | 6 | 100 % |
 |低い|リソースのラベル使用法| 2 | 0 | 6 | 44パーセント​
|低い| PSP対応| 1 | 0 | 1 | 100 % |
 |低い|リソースポリシー| 6 | 0 | 6 | 100 % |
 |低い|シークレット/ ETCD暗号化が有効| 1 | 0 | 1 | 100 % |
 + -- -- -- -- -- -- + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - + -- -- -- -- -- -- -- -- + -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- -- + -- -- -- -- -- -- +​​​​​​​
 | |リソースの概要| 37 | 0 | 90 | 16.62パーセント​
+ -- -- -- -- -- -- + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- - + -- -- -- -- -- -- -- -- + -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- -- + -- -- -- -- -- -- +​​​​​​​

フレームワーク: MITER (リスク: 12.58 )、 AllControls (リスク: 16.62 )、 ArmoBest (リスク: 13.44 )、 DevOpsBest (リスク: 40.27 )、 NSA (リスク: 17.92 )

各ノードに診断コンテナをインストールするには、--enable-host-scan を追加します。これにより、以下に示すように、より詳細な結果が得られます。

 $ kubescapeスキャンフレームワークDevOpsBest --enable - host - scan
コントロール: 11 (失敗: 6 、除外: 0 、スキップ: 0 )
 + -- -- -- -- -- + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- - + -- -- -- -- -- -- +​​​​
 |重大度|コントロール名|失敗したリソース|除外されるリソース|すべてのリソース| %リスク-スコア|
 + -- -- -- -- -- + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- - + -- -- -- -- -- -- +​​​​
 |高|リソースCPU制限とリクエスト| 6 | 0 | 6 | 100 % |
 |高|リソースメモリの制限と要求| 5 | 0 | 6 | 69パーセント​
|中|構成された活性プローブ| 1 | 0 | 6 | 14 % |
 |低い|構成された準備プローブ| 4 | 0 | 6 | 56パーセント​
|低い| K8s の一般的なラベルの使用法| 6 | 0 | 6 | 100 % |
 |低い|リソースのラベル使用法| 2 | 0 | 6 | 44パーセント​
+ -- -- -- -- -- + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- - + -- -- -- -- -- -- +​​​​
 | |リソースの概要| 6 | 0 | 6 | 40.27パーセント​
+ -- -- -- -- -- + -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- -- -- -- + -- -- -- -- -- -- - + -- -- -- -- -- -- +​​​​
フレームワークDevOpsベスト

CI / CDによるセキュリティ監査の自動化

Kubernetes 環境のセキュリティを確保できたので、その安全性を維持するにはどうすればよいでしょうか?安全でないデプロイメントがシステムに到達するのを防ぐために、CI/CD パイプラインに整合性チェックを埋め込むことができます。

この目的のために、CI/CD ソリューションとして Semaphore を使用します。 Semaphore に詳しくない場合は、ガイド付きツアーを見て基本を学んでください。無料アカウントを使用して、このチュートリアルのすべての手順を実行できます。

パイプラインを開始します。デプロイする前にいくつかテストを追加します。

まず、リポジトリをフォークし、フォークアンド実行ブランチに切り替えます。それから：

1. セマフォに項目を追加します。
2. パイプラインを編集し、 「デプロイ」をクリックして継続的なデプロイ パイプラインを表示します。
3. + ブロックを追加 をクリックします。
4. Prologueを開き、Kubescape インストール コマンド「curl -s」を入力します。
   https://raw.githubusercontent.com/armosec/kubescape/master/install.sh |バイナリ
5. ジョブに次のコマンドを追加します。 checkout コマンドは、CI マシンのリポジトリをクローンして、マニフェスト ファイル (deployment.yml) にアクセスできるようにします。
6. checkoutexport MAX_RISK=40kubescape scan -t "$MAX_RISK" デプロイメント.yml --format junit -o report.xml
7. 新しいジョブが最初に実行されるように、パイプライン内のジョブの依存関係を調整します。

テストレポートの設定

このセクションでは、すべての CI/CD 実行の Kubescape 結果を分析し、統合レポートに表示する機能であるテスト レポートを構成します。

1. 継続的デプロイメント パイプラインのエピローグセクションを開き、次の行を入力して、Kubescape によって生成されたレポートを処理します。
2. ` -f report`.`xml ` && テスト結果 report.xml を公開
   ジョブ後に「追加」をクリックし、次のコマンドを入力します。これにより、すべてのジョブからレポートが収集され、ダッシュボードが更新されます。

1 つのテスト結果からパイプライン レポートが生成される

1. テスト結果 gen-pipeline-レポート
2. パイプラインはすぐに開始されるはずです。 「プロモート」ボタンをクリックする前に、CI パイプライン内のすべてのジョブが完了するまで待機します。リスク レベルが設定されたしきい値 (この例では 40% ですが、自由に調整できます) を超えると、パイプラインは失敗し、クラスターを保護するためにデプロイメントがブロックされます。

インベントリ整合性チェックがインストールされた継続的なデプロイメント パイプライン。

完了すると、Kubescape によって検出された障害を「テスト結果」タブで表示できます。

テスト レポートは、重大な安全性の問題に関する洞察を提供します。

クラスターの事前チェック

展開を保護することは解決策の半分にすぎません。残りの半分は、Kubernetes クラスター自体を継続的にチェックすることです。 Kubescape は、次の 2 つの補完的な方法でこれを実現します。

• クラスターに Kubescape をインストールし、バックグラウンドで実行したままにします。結果はArmo Cloudポータルで確認できます。
• すべてのデプロイメントの前に、CI/CD パイプラインでクラスターをスキャンします。

そこで、CI/CD パイプラインを更新して事前チェックを実行し、安全にデプロイできることを確認しましょう。その前に、クラスターに接続できるように、Kubeconfig ファイルを Semaphore にアップロードする必要があります。つまり、ファイルを含むシークレットを作成する必要があります。これをシークレット kubeconfig と呼びます。

パイプラインを編集し、先ほど作成したブロックにパイプライン スキャン ジョブを追加してセットアップを完了します。チェックを実行するコマンドは次のとおりです。

チェックアウト
エクスポートMAX_RISK = 40
 kubescapeスキャン--除外-名前空間kube - system 、 kube - public - t $MAX_RISK --フォーマットjunit - oレポート.xml

保存する前に、シークレット セクションを開いて kubeconfig エントリを有効にします。

ブロックにクラスター スキャン ジョブと kubeconfig パスワードを追加します。

それでおしまい。パイプラインを再度実行して、すべてが正常に動作しているかどうかを確認します。

すべてのチェックを完了した最終的な CI/CD パイプライン。

結論は

Kubernetes は大規模なアプリケーションを実行するための人気のプラットフォームですが、攻撃の主な標的にもなります。安全は決して後回しにされるものではありません。これは、ソフトウェア開発サイクルのあらゆる部分の不可欠な部分として考えるべき継続的な実践です。この実践の一環として、Kubescape などのツールを活用してシステムを保護しします。