2022年にKubernetesのセキュリティを強化する方法

Kubernetes は現在最も人気のあるコンテナ オーケストレーション プラットフォームです。世界中の Mesoses や Docker Swarms はほとんど姿を消しましたが、正直言って、私はそれらを懐かしく思いません。しかし、Kubernetes が市場で優位に立っていることのマイナス面は、Kubernetes がセキュリティを侵害しようとする悪意のある行為者にとっての重大な標的にもなっていることです。

悲しい事実: コンテナのセキュリティは悪い状態にある

• 現在、開発者の 56% がコンテナをスキャンすらしていません。
• ガートナーは、2023 年までに 70% 以上の企業がコンテナ化されたアプリケーションを実行するようになると予測しています。
• 2022 年の Red Hat レポートによると、Kubernetes のセキュリティ インシデント全体の 59% は構成ミスによるものです。

コミュニティとして、私たちはこれについて何かしなければなりません!

2022 NSA/CISA Kubernetes 強化ガイドの概要

2021 年 8 月 3 日に最初に公開され、その後 NSA と CISA によって 2022 年 3 月 15 日に更新された技術レポート「Kubernetes 強化ガイド」が役立ちます。これは、コンテナ プラットフォームとして Kubernetes に依存している組織にとって非常に役立つドキュメントです。プラットフォームを保護する方法に関する詳細な情報と実践的な例を提供します。

ここでは、技術レポートから得られた主なポイントを要約し、クラウド セキュリティに関する私の個人的な経験に基づいて追加の洞察を提供します。

コンテナとポッドをスキャンして脆弱性や設定ミスがないか確認する

私たちがコンテナを好む理由は、イメージがソフトウェアとそのすべての依存関係の不変のパッケージであるためです。不変性は資産です。同じコンテナが QA プロセスを経て、変更なしで開発から本番環境に昇格できるためです。しかし、コンテナ イメージはソフトウェアのタイム カプセルであるため、新しい脆弱性が発見されても自動的に更新されないため、負担にもなります。

コンテナ イメージをスキャンして既知の脆弱性を検出することは、セキュリティのベスト プラクティスです (ただし、これを実行している開発者は 44% のみです)。しかし、ほとんどの場合、イメージは最初にレジストリにプッシュされたときにのみスキャンされます。これにより問題が発生します。アプリケーションが安定しているほど、更新頻度が低くなり、レジストリにプッシュされる頻度も低くなります。

皮肉なことに、安定性により、コンテナ イメージは更新間で脆弱になりやすくなります。

緩和策として、NSA/CISA レポートでは、ポッドがデプロイされたときにスキャンを要求する Kubernetes アドミッション コントローラーを使用することを推奨しています。しかし、よく考えてみると、これは長期間にわたって頻繁に更新されないアプリケーションをデプロイする場合と同じ問題を抱えており、この追加のデプロイ時チェックでは、長時間実行されるアプリケーションを適切に保護できません。

そのため、クラスターにデプロイされているコンテナを定期的に判別し、それらのイメージを定期的にスキャンするプロセスを設定することを強くお勧めします。ポッドを 1 日に 1 回繰り返すようにスケジュールし、レジストリでコンテナ イメージをスキャンするだけです。これにより、スキャンは最新かつ正確になります。

コンテナとポッドをできるだけ少ない権限で実行する

Kubernetes とコンテナ ランタイムのデフォルトのセキュリティ体制は、初日から非常に緩いものでした。内部脅威の 3 分の 2 が過失によって引き起こされる世界では、ソフトウェアまたはユーザーに過度に広範な権限を与えることは間違いなく過失です。

コンテナ内のデフォルト ユーザーは、システム管理者の root ユーザーです。手動でオプトアウトする必要があります。 Kubernetes は、コンテナ化されたアプリケーションの機能に対してほとんど追加の制限を課しません。したがって、Kubernetes コンテナ プラットフォーム内のアプリケーションに対するサイバー攻撃が成功した場合、攻撃者に付与される権限とアクセス許可のセットは非常に広範囲になります。

リスクを軽減するには、次の事項を確実に実施するためのポリシーを導入する必要があります。

• アプリケーションの権限を制限し、ハッカー攻撃の可能性を抑えるため、コンテナは「ルート」ユーザーとして実行されません（コンテナ ランタイム自体も、可能な場合はデフォルト ユーザーが実行します）。
• コンテナ ファイル システムは不変であるため、悪意のあるユーザーが痕跡を消去するのを防ぐことができます。
• 最も制限の厳しい Pod セキュリティ ポリシー (Kubernetes v1.21+) または Pod セキュリティ標準 (Kubernetes v1.22+) は、たとえば、非 root ユーザーとして実行し、権限の昇格を禁止して実質的に root ユーザーになり、コンテナー ホストのオペレーティング システムにアクセスする場合に使用されます。
• ポッドは Kubernetes クラスターの API に予想以上にアクセスできる可能性があるため、デフォルトのサービス アカウント トークンは必要ありません。アプリケーションではこれが必要ない場合もありますが、なぜデフォルトで存在するのでしょうか?

言うまでもなく、こうした基本ポリシーは常に実施されるべきだと思います。ただし、さらに多くのポリシーがある場合もあります。それらはあなたの組織にとって特別なものです。この目的のために、Kubernetes と Open Policy Agent (OPA) で利用可能な構成を使用することを心からお勧めします。公式ライブラリやサードパーティのポリシーにヒントを得た構成を通じて、リクエストごとにすべてのポリシー事項を適用できます。

ネットワーク分離を使用して、侵害によって発生する可能性のある損害の量を制限する

Kubernetes のデフォルトのネットワーク設定では、どの名前空間にデプロイされているかに関係なく、Pod が自由に相互接続できます。この自由なネットワーク アプローチにより、悪意のある人物は 1 つの Pod に侵入するだけで、他のすべての Pod に無制限にアクセスできるようになります。したがって、プラットフォーム全体のセキュリティは最も安全性の低いコンポーネントのセキュリティと同じ程度にしかならず、悪意のある人物は最も安全性の低いコンポーネントから侵入するだけで済みます。その後のことは歴史が語っています。

Kubernetes ネットワーク ポリシーは、ネットワークに構成可能な制限を課します。これらの実装は、使用されるコンテナ ネットワーク インターフェイス (CNI) プロバイダーによって異なりますが、基本的には Kubernetes リソース対応のファイアウォール ルールになります。これにより、「バックエンド コンポーネント」のみが「データベース」を呼び出し、それ以外は呼び出しを行わないように簡単に指定できます。したがって、API ゲートウェイに弱点があっても、プラットフォーム内の任意のコンポーネントが簡単に攻撃される可能性があるわけではありません。

ファイアウォールを使用して不要なネットワーク接続を制限し、暗号化を使用して機密性を保護します。

Kubernetes コンテナ プラットフォームは、コントロール プレーンと一連のワーカー ノードで構成されます。コントロール プレーン ノードは、クラスター全体を制御するコンポーネントをホストします。したがって、コントロール プレーンの制御を取得した悪意のある人物は、任意の後続の攻撃を実行し、クラスターにスプーフィングを完全に指示することができます。

ファイアウォールによるネットワーク境界防御は、（外部の）悪意のある脅威アクターによるこのような攻撃を軽減するのに役立ちます。コントロール プレーンのコンポーネント (Kubernetes API、etcd、コントローラー マネージャーなど) は、組織のニーズを満たすために絶対に必要な範囲を超えて公開しないでください。

また、Kubernetes クラスター内のネットワーク トラフィックは通常暗号化されないことに注意してください。これは、悪意のある人物がコンテナ プラットフォームに配置するソフトウェアによって機密情報が取得され、悪用される可能性があることを意味します。このような攻撃を防ぐために、クラスター内のすべてのトラフィックを暗号化することができます。クラスターが構成オプションとして暗号化を提供する CNI プロバイダーを使用している場合、これは非常に簡単で完全に透過的な変更です。たとえば、Calico は WireGuard を活用してこれを実現できます。情報セキュリティのニーズを満たす基盤となるネットワークを完全に信頼できない場合は、これが推奨されます。

強力な認証と承認を使用して、ユーザーと管理者のアクセスを制限し、攻撃対象領域を制限します。

Kubernetes コンテナ プラットフォームには、API サーバーにロールベースのアクセス制御機能があります。ただし、何らかの理由でこれらを明示的にアクティブ化する必要があります。さらに、一般的な Kubernetes インストールでは、クラスターをインストールするユーザーに、有効期限のないシステム管理者の「トークン」が提供されます。このトークンを使用すると、クラスターへの完全かつ永続的なアクセスが提供されます。これについて私がどう感じているか推測してみてください。

デフォルトでは有効になっていませんが、Kubernetes はさまざまな方法による認証をサポートしています。いろいろありますが、OpenID Connect トークンの使用を強くお勧めします。統合できる ID プロバイダー サービスは多数あり、そのほとんどがこのようなトークンの発行をサポートしています。また、ユーザーが所属するグループに関する情報も含めることができるため、ロールベースのアクセス制御ルールをグループ レベルで設定できます。そうでない場合は、Keycloak または Dex IdP を統合できる可能性があります。

そして、うまくいけば（そして寛大に）使いやすさを追求する誤った試みとして、Kubernetes は匿名リクエストもデフォルトでサポートします。これは間違いなく閉鎖されるはずです。

ロールベースのアクセス制御を有効にし、最小権限の原則に従うように構成する必要があります。したがって、ソフトウェアとユーザーには最小限の権限のみを付与し、追加の権限の要求は要求に応じて検討する必要があります。

ご存知のとおり、(a) 管理者トークンを無効にすること、(b) OpenID Connect を有効にすること、(b) 匿名アクセスを無効にすること、(d) ロールベースのアクセス制御を有効にすることを推奨します。そして、(e) 実際に権限を可能な限り制限します。

監査ログを有効にして、管理者がアクティビティを監視し、潜在的な悪意のあるアクティビティを警告できるようにします。

Kubernetes コントロール プレーンには、監査ログ機能が組み込まれています。しかし、ここでも (テーマに気づきましたか?)、これらは構成によって明示的に有効にする必要があります。 Kubernetes Hardening Guidance 技術レポートと同様に、オペレーターがクラスター内で何が起こっているかを詳細に把握できるように、これらも有効にすることをお勧めします。

ただし、非常に頻繁なログ ストリームを有効にするだけでは (Kubernetes API に対するすべての自動リクエストも監査証跡を残します)、干し草の山から針を探すようなものです。干し草の山から針を見つけるには、実際にこれらのログを解析して使用する必要があります。これは、ログ ストレージ ソリューション (Opensearch、Splunk、DataDog など) のフィルタリング式を通じて、または自動化システム (CNCF プロジェクト Falco など) による自動かつポリシー対応の解析を通じて実行できます。ログ処理サービスと連携して、自動化されたセキュリティ インシデントおよびイベント管理 (SIEM) システムとして機能します。

すべてのKubernetes設定を定期的に確認し、脆弱性スキャンを使用してリスクが適切に考慮され、セキュリティパッチが適用されていることを確認します。

Kubernetes は、コンテナ プラットフォームの新しいバージョンを年に約 3 回リリースします。セキュリティ アップデートは、現在のバージョンと 2 つの前バージョンに対してのみ提供されます。したがって、セキュリティを最新の状態に保つために、オペレーターは少なくとも年に 1 回は新しいバージョンをインストールする必要があります。過去のかなりナイーブなセキュリティ機能が徐々に改善されているので、新しいリリースごとにそれを実行してくれると最高です。

ここまでで明らかにできたと思いますが、Kubernetes はデフォルトでは安全ではありません。無効になっているセキュリティ機能の数は、セキュリティが意図的にデフォルトで考慮されていないことを示しています。新たなセキュリティ上の脅威が引き続き発生しています。したがって、コントロール プレーンとワーカー ノード自体を含むプラットフォーム全体の自動脆弱性スキャンを使用することを強くお勧めします。問題が見つかった場合は、すぐにアラートを発行します。

しかし、問題があります。自動テストではすべてが検出されますか?いいえ、絶対に違います。しかし、より明白なエラーのいくつかは検出されており、悪意のある人物によって発見された場合、プラットフォームが他の方法でも誤って構成されている可能性があることが示されます。私の経験では、簡単に達成できる目標に取り組まないことさえ、大きな「歓迎すべき」兆候です。

自動化された脆弱性ツールで十分でしょうか?

多くのツールは、コンテナ イメージの脆弱性や、Kubernetes クラスターの構成、またはその内部で管理されているリソースを自動的にスキャンすることを約束しています。これらは誤った構成を強調するため、魅力的な製品となります。しかし、その範囲と機能は限られています。これらは、NSA/CISA Kubernetes 強化ガイドで推奨されているすべての内容を網羅しているわけではありません (技術的には網羅できません)。

セキュリティ会社ARMOがKubescapeをリリースしました。これは、NSA/CISA 技術レポートのベスト プラクティスに従ってクラスターを検証する最初のツールであると主張しています。実際、この記事の執筆時点では、優れた自動テストのセットが含まれています。

Kubernetes API を使用し、2022 年現在では、ホスト レベルのチェックも使用してチェックを実行します。これにより、検査可能な大量の構成にアクセスできるようになります。ただし、制限もあります。たとえば、コンテナ レジストリ内のコンテナ イメージの脆弱性スキャン ポリシーが有効になっているかどうか、監査ログが自動的に確認されているかどうか、ノード間にファイアウォールがあるかどうか、VM またはクラウド レベルで組織に対して最も厳格な権限制限が適用されているかどうかなどを確認することは通常できません。これらすべてには、ツールに期待される以上の組織のポリシーとプロセスに関する知識が必要です。

2022 年の最新のアップデートでは、独自のイメージ スキャン機能、RBAC ビジュアライザーと調査機能、支援修復機能などが追加されるなど、Kubescape の範囲が開始以来大幅に拡大しました。また、Google Cloud と統合されているため、そこから情報を収集することもできます。 ARMO が 2022 年 4 月に 3,000 万ドルのシリーズ A 資金調達ラウンドを成功させたことを考えると、Kubescape が実現できることの幅と深さは大幅に増加すると思われます。

Aqua Security は kube-bench もリリースしました。コントロール プレーン ホスト上で実行されているプロセスを検査することで、コントロール プレーンの構成を検査できます。残念ながら、Kubernetes 構成の一部ではないセキュリティ機能をチェックすることはできません。

したがって答えは「いいえ」です。単に自動チェックを実行するだけでは、セキュリティ体制が完璧（または良好）であると主張することはできません。また、クラスター自体だけでなく、セキュリティ ポリシーの実践的な理解とより広い視点も必要です。

NSA/CISA Kubernetes 強化ガイドを超えて

設定エラーを防ぐには、チェックするだけではなく

ロールベースのアクセス制御 (RBAC) は、誰がどのような状況で何を実行できるかを決定します。しかし、ルールで Lars が「本番環境」で「構成を更新」できると規定されているからといって、無制限にアクセスできるわけではありません。Lars がミスをしないように保護する必要もあります。結局のところ、内部脅威の 3 分の 2 は過失によって引き起こされます。

ほとんどのクラウド システムと同様に、Kubernetes には RBAC を適用するシステムのみが付属しており、ユーザーが実際に実行できることを制限する合理的なポリシーは適用されません。

事後に誤った構成をチェックする機能は、一部のシステムによって提供されています。 AWS Config は現在、この目的で注目を集めています。

しかし、私は誤った設定に対して完全に保護されたシステムを好みます。ポリシーは自動的に実行可能な形式でエンコードする必要があります。 CNCF プロジェクトの Open Policy Agent (OPA) はこれを実現できます。これは Kubernetes アドミッション コントローラーとして機能し、ポリシー違反が発生しないようにします。 OPA は非常に汎用性が高く、公式ライブラリから学習することも、他の既成のポリシーから選択してそれに基づいて構築することもできます。

アプリに与えられた権限は悪意のある人物にも与えられる

悪意のある人物があなたのアプリを侵害した場合、その人物はあなたのアプリとまったく同じ権限を持つことになります。おそらくこれは明白なことのように思えます。しかし、私の経験からすると、これは実際には真剣に受け止められていないようです。悪意のある人物は、Kubernetes コンテナ プラットフォーム、ネットワーク、クラウド、サードパーティの SaaS 統合、VPN に接続するバックエンドの場所など、あらゆるものを入手します。

結局のところ、ランサムウェアのような悪質なものはこのようにして拡散するのです。これらは、Web アプリケーションの 1 点にのみ感染し、その後拡散し続けます。鎖の強さは文字通り、最も弱い部分の強さによって決まります。

よく考えてみると、REST API コンポーネントには、リクエストを処理して応答を送り返す以外の権限は必要ないはずです。

クラウドリソースを念頭に置く

私たちは皆、その見出しを見ました。匿名アクセスを許可するように誤って構成された S3 バケットであったか、任意の顧客データベースへのアクセスを許可する Microsoft Azure CosmosDB のマスター キーであったかにかかわらず、メッセージは明確でした。クラウド リソースを使用するときは、常にそのリソースとその構成を念頭に置く必要があります。

Kubernetes エコシステムには、クラウド統合をシンプルにするさまざまなコントローラーがあり、シンプルであることは素晴らしいことです。しかし、シンプルさゆえにセキュリティが損なわれることは決して許されません。したがって、これらのコントローラーが管理するリソースに単純なセキュリティ設定を適用しないようにする必要があります。セキュリティの管理方法を明確に宣伝していないツールは、完全に拒否する必要があります。これには、必要な IAM 権限を指定していないツールや、適用する権限を構成する方法が公開されていないツールが含まれます。

アプリケーションに誤ってクラウドの権限が付与されていませんか?

クラウド リソースを変更するためのアクセス権限をクラウド サーバーに付与していますか? AWS がインスタンス プロファイルと呼ぶもの (他のクラウド プロバイダーは異なる名前で同じ概念を持っています) は、仮想マシンにクラウド リソースを変更する権限を付与します。その VM で実行することで、コンテナ化されたアプリケーションにもそれが可能になります。クラウドのメタデータ サービスに対して一連のネットワーク呼び出しを実行するだけで、サーバーに付与するのと同じレベルのアクセス権が得られます。サーバー上で実行されるため、クラウドはそれを「サーバー」として認識します。

やりたいことを何でもできるようにするために、サーバーのインスタンス プロファイルにいくつかの権限を追加する人々を何度も見てきました。ロードバランサーを作成し、いくつかの DNS レコードを更新し、自動スケーリング グループを変更します。そういうもの。しかし、彼らは意図したユースケースをサポートするためだけにこれを行っており、意図しないユースケースにはすべて同じ権限が付与されることに気づいていませんでした。

デプロイされたすべてのコンテナイメージを定期的にスキャンする

多くのコンテナ イメージ レジストリは、イメージをプッシュするときにイメージのスキャンをサポートしています。それは素晴らしい！ NSA/CISA Kubernetes 強化ガイドでは、アドミッション コントローラーがデプロイメント時にスキャンを要求することを推奨しています。

しかし、ソフトウェアが安定しているために、イメージが数週間または数か月間展開されたままになった場合はどうなるでしょうか?数週間前の最初のスキャンでは問題がなかったとしても、今日の新しいスキャンでは脆弱性が見つかる可能性があります。

代わりに、私は Kubernetes コンテナ プラットフォームに積極的にデプロイされるすべてのコンテナ イメージを定期的にスキャンすることを強く推奨します。デプロイされたすべてのコンテナ イメージ バージョンを識別し、毎日スキャンすることで、このチェックを自動化します。

つまり、頻繁に更新されない安定したソフトウェアの古いコンテナ イメージに対して、最新の脆弱性データベースのメリットを享受できるということです。スキャンによって依存関係に問題が見つかった場合は、コード自体は変更されていないため、更新された依存関係を使用してイメージを再構築し、（うまくいけば）他の変更をほとんどまたはまったく加えずにデプロイできます。

システム全体のセキュリティテストを定期的に実施する

ソフトウェア エンジニアは、外部の脅威にはない、ソース コードへのアクセスを持っています。システムのセキュリティ テストを実行する時間と権限も提供すれば、魔法のようなことが起こるかもしれません。

過去のプロジェクトで、特定の種類のリソースを自動的に作成すると、システム全体が急停止してしまうことに気づいたことを懐かしく思い出します。 1 台のラップトップで、明らかに悪意のある操作を行わなくても、システム全体に対してサービス拒否攻撃を成功させることができます。

エンジニア自身が安全に関するトレーニングを受けていないとしても、安全第一の精神を植え付けることが重要です。これは、順調な航海とセキュリティ災害の違いとなる可能性があります。

災害復旧（DR）計画を策定し、実行する

私が話をした企業の多くが、災害復旧は「バックアップ」だけを意味すると考えていることには驚かされます。ヒント: 実際はそうではありません。バックアップは必要ですが、それだけでは十分ではありません。

災害から復旧するということは、特定の期間内にテクノロジースタック全体を別の場所で立ち上げることができることを意味します。災害とは通常、クラウド領域全体の停止を意味すると考えられていますが、セキュリティ インシデントも間違いなく災害に含まれると私は主張します。デプロイされたアプリケーションを信頼できなくなったため、次の質問に答える必要があります。インフラストラクチャ全体を破壊し、インシデント前の状態に回復するにはどのくらいの時間がかかりますか?

この気まずい質問をされると、DR が「バックアップ」と同じであるとまだ考えている企業は、それらのバックアップからの復元を定期的に試みることさえしていないことを認めることが多いです。情報技術が仕事の中核である場合は、この側面を真剣に受け止めてください。

侵入検知システム（IDS）とセキュリティ情報イベント管理（SIEM）システムを使用する

Kubernetes 強化ガイダンスではこれらについて言及していますが、実際にそれらをどうするか、どのように使用するかについては説明されていません。

IDS はアプリケーションの通常の動作を記録および監視し、これらのベースラインに対してアクティビティを継続的にチェックします。アプリケーションが新しい動作を始めた場合、それは悪意のある人物によって悪用された兆候である可能性があります。たとえば、通常は実行しないファイルの読み取りまたは書き込みを試行し始めた場合、これは非常に良い兆候です。つまり、それが自動的に実行され始めたわけではないのです。

CNCF プロジェクト Falco もこのガイドに従うのに役立ちます。ルールを指定するのは確かに面倒ですが、アプリケーションに必要なガードレールを提供することは不可欠です。コミュニティが提供するサービスから始めることができます。

Falco は、たとえば Elasticsearch と組み合わせて使用​​して (監査) ログを検査し、SIEM として機能させることができます。こんな使い方もオススメです。すでに別のシステムをお持ちの場合は、ぜひそれを使用してください。しかし、何かを使ってください。今日の規制の多くでは、データ侵害についてユーザーに通知することが義務付けられているため、セキュリティ情報とインシデントの管理に役立つシステムが本当に必要です。セキュリティ ログ データの量は、特に攻撃を受けている場合には、手動で処理するには大きすぎます。

情報セキュリティは一度限りのイベントではなく、継続的なプロセスです。脅威は常に進化しており、対応も進化する必要があります。当社のプラットフォームにガードレールを設置し、アプリケーションとサーバーに最小限の権限を付与するよう継続的に取り組むことで、攻撃対象領域を減らすことができます。

クラウドの本質的な複雑さと動的な性質により、悪意のある行為者が攻撃したり隠れたりする場所が数多く存在します。こうした機会を制限するのは私たちの責任です。

終わりに

Kubernetes はデフォルトでは安全ではなく、本質的に安全でもありません。構成を強化することは絶対に可能であり、また強化する必要があります。クラウド プロバイダーが提供する、いわゆる「マネージド Kubernetes サービス」では、この記事に記載されているようなアドバイスはほとんど提供されません。確かに、強力なセキュリティに必要な他のツールは追加されません。彼らもそうすることに興味はなく、彼らの「責任共有モデル」によれば、クラウドのセキュリティについては彼らが責任を負いますが、クラウド内のセキュリティについてはあなたが責任を負います。