Kubernetes ネイティブセキュリティとは
コンテナセキュリティには、主に「コンテナ中心型」と「Kubernetes ネイティブ」という 2 つのアプローチがあります。
コンテナ中心型のプラットフォームは、コンテナレベルで動作し、コンテナイメージやコンテナランタイム保護に焦点を当てています。これらのツールは、インラインプロキシやシム（shim）といった技術を利用し、たとえばコンテナ間の通信の制御など、コンテナレベルでの制御を実現します。
Kubernetes ネイティブセキュリティは、Kubernetes レイヤーで動作します。Kubernetes からコンテキスト情報を取得し、ポリシーを Kubernetes にプッシュすることで、Kubernetes によるポリシーの実施を可能にします。
Kubernetes ネイティブセキュリティは、Kubernetes と緊密に統合されており、コンテキスト情報の取得と Kubernetes のネイティブコントロールの活用を可能にします。このアーキテクチャにより、豊富なコンテキストとインサイトの提供、そして Kubernetes 固有の脅威の検知という 2 つの重要な側面でセキュリティが強化されます。
「Kubernetes ネイティブな」セキュリティとは
Kubernetes ネイティブセキュリティは、「コンテナ化アプリケーションを管理するシステムと連携させることで、最も効果的にセキュリティが実装される」という考え方に基づいています。
セキュリティ・プラットフォームが Kubernetes ネイティブと見なされるためには、以下の特性を備えている必要があります。
- Kubernetes API サーバーと直接統合して、Kubernetes のワークロードとインフラストラクチャを直接可視化できる
- Kubernetes ソフトウェアそのものの脆弱性を評価できる
- デプロイメント、namespace、サービス、Pod など、Kubernetes オブジェクトモデル内のリソースに基づいて、ポリシー管理を含むセキュリティ機能を構築できる
- Kubernetes 固有のアーティファクト (ワークロード・マニフェストなど) と構成からの宣言型データを分析できる
- 可能な場合には、組み込みの Kubernetes セキュリティ機能を利用して適用を行い、自動化、スケーラビリティ、信頼性を向上させられる
- クラウドネイティブ・ツールチェーンの一般的なツールの統合とサポートを含む、Kubernetes アプリケーションとしてデプロイし、実行できる
Kubernetes ネイティブセキュリティは、コンテナの構成だけでなく、Kubernetes デプロイメント全体の構成を可視化します。
ワークロードがどのように隔離されているのか、または隔離されているかどうかを把握することも重要です。Kubernetes は、デフォルトでは、どのデプロイメントも自身の namespace 内外のその他すべてのデプロイメントと通信できるようになっています。(できれば YAML ファイルのテキストを読むのではなく、視覚的に確認できる形で) ネットワークポリシー設定を詳細に可視化することで、隔離されていないワークロードを把握しやすくなります。
セキュリティポスチャ全般を把握するには、Kubernetes の構成 (ロール権限、シークレットへのアクセス、許可するネットワーク通信、コントロールプレーンの各コンポーネントの設定など) が適切にロックダウンされていること、ベストプラクティスに従っていること、そしてアプリケーションの動作に必要な最小限の特権に制限されていることを確認する必要があります。
Red Hat のリソース
クラウド環境での Kubernetes セキュリティ
他のコンピュートリソースと同じように、Kubernetes についても、クラウド上での運用を選択する組織が多くなっています。クラウド上で Kubernetes を運用する方法として、次のような選択肢があります。
- セルフマネージド Kubernetes
- 商用 Kubernetes ディストリビューション
- マネージド Kubernetes サービス
どのモデルを選んでも、デプロイメントのセキュリティについては、利用者とクラウドプロバイダーで「責任を分担」することになります。一般的な共有責任モデルは、Kubernetes (特にマネージドサービス) にも適用されますが、セキュリティの責任の境界線が分かりにくいと感じられることもあります。
マネージド Kubernetes サービスの場合、クラウドプロバイダーは Kubernetes のコントロールプレーン (クラスタを管理するコンポーネントやクラスタの状態・構成に関するデータを含む) を管理します。
通常、サービスにはコントロールプレーンのセットアップやノードの冗長化が含まれます。さらに、多くの場合、異なるリージョンでのノードの運用も含まれ、クラウドプロバイダーのインフラストラクチャの一部に障害が発生してもサービスが停止しないように設計されています。
通常、クラウドプロバイダーは以下を提供します。
- Kubernetes を最新の状態に保つ
- コントロールプレーンにパッチを適用する
- ノードの OS 用パッチを提供する場合もある (利用している OS による)
- 多くの場合、ノード用のコンテナ最適化 OS イメージを提供する
- 脆弱性スキャナーを提供する場合もあるが、アドミッション・コントローラーを使ったスキャン結果に基づく許可/拒否などのポリシーは、利用者側で作成する必要がある
Kubernetes ワークロードのセキュリティは、常に利用者の責任範囲です。具体的には、以下のようなセキュリティ項目が含まれます。
- コンテナイメージ：ソース、コンテンツ、脆弱性
- デプロイメント：ネットワークサービス、ストレージ、特権
- 構成管理：ロール、グループ、ロールバインディング、サービスアカウント
- アプリケーション：シークレット管理、ラベル、アノテーション
- ネットワーク・セグメンテーション：クラスタ内のネットワークポリシー
- ランタイム：脅威の検出とインシデント対応
Kubernetes ネイティブセキュリティの利点
Kubernetes ネイティブ・セキュリティ・プラットフォームには、主に以下のような利点があります。
保護の強化
Kubernetes ネイティブセキュリティは Kubernetes の宣言型データと連携することで、Kubernetes とコンテナの脆弱性を発見し、より豊富なインサイトをもたらします。
運用効率の向上：
インフラストラクチャ管理とセキュリティを同じフレームワークで扱えるため、Kubernetes に関する学習負担を抑えられるほか、Kubernetes のコンテキスト情報を活用することで、より迅速な脅威の検知や優先度に応じたリスク評価が実現します。
運用リスクの軽減
Kubernetes のネイティブコントロールを活用することで、セキュリティにも Kubernetes と同じスピードとスケーラビリティがもたらされます。ポリシーが Kubernetes に組み込まれているため、外部のコントロールとオーケストレーター間で矛盾が生じることもありません。
運用リスクの軽減
Kubernetes ネイティブセキュリティは、一貫性のない構成、調整の欠如、およびユーザーエラーに起因する運用上の問題を軽減するのに役立ちます。
Kubernetes ユーザーの学習曲線を考えると、Kubernetes の ロールベースのアクセス制御 (RBAC) を使用して過剰な特権を与えてしまうなどの誤操作は簡単に起こりえます。たとえば、ユーザーやサービスアカウントにクラスタ全体の管理権限を付与してしまう、あるいは必要ないのにデプロイメントがシークレットを取得できるようにして、Kubernetes のシークレット情報を不必要に公開してしまうことなどが考えられます。
Kubernetes ネイティブ・セキュリティ・プラットフォームは、こうした構成エラーを自動的かつ継続的に検出できます。
セキュリティ・コントロールを Kubernetes に直接組み込むことで、別途制御ソフトウェアを使用した場合に起こりうるリスクも排除できます。別個の制御ソフトウェアを使用すると、障害が発生した場合、セキュリティを無効にしたまますべてのトラフィックを通してしまう (フェイルオープン) か、逆にすべてのアプリケーション・トラフィックを停止させてしまう (フェイルクローズ) ことになります。
Kubernetes オーケストレーターにポリシーを適用させることで、セキュリティにおいても、Kubernetes のスケーラビリティと多彩なポリシー適用機能をすぐに活用できます。
一方で、インラインプロキシやシムでポリシーを適用すると、単一障害点が生じ、スケーラビリティの問題やパフォーマンス面での制約が発生します。
Kubernetes では、ネットワークポリシーの適用によるトラフィック分割、アドミッション・コントローラーを使った Kubernetes API サーバーへのリクエストに対するポリシーの適用、シークレットによる機密性の高い認証情報の保管、ロールベースのアクセス制御 (RBAC) による特定のユーザーやサービスアカウントへの権限付与などが可能です。
さらに、Kubernetes ネイティブ・セキュリティ・プラットフォームと組み合わせて、コンテナ・ネットワーク・インタフェース (CNI) に準拠したネットワークプラグインなどの標準化ツールを使用し、必要に応じてそれらの追加ツールを変更することもできます。
運用効率の向上
Kubernetes は、インフラストラクチャ・サービスのプロビジョニングと運用が 1 つになった統合型プラットフォームを提供することで、アプリケーション開発チームと運用チームのワークフローを効率化し、統合します。
全員が共通の信頼できる情報源と同じインフラストラクチャを使って作業するこの統合アプローチは、Kubernetes ネイティブ・セキュリティ・プラットフォームを導入することで、セキュリティにも拡張できます。
このアプローチなら、学習曲線が短縮され、分析や修復をより迅速に行えるようになるため、時間とコストを削減できます。
DevOps チームとセキュリティチームが別々のツールを使っていると、構成の食い違いによるトラブルが起きやすくなります。
たとえば、DevOps チームが 2 つのノード間の通信を許可する Kubernetes ネットワークポリシーを設定しても、セキュリティチームが別の制御ソフトウェアを使ってその通信をブロックするということが起こりえます。
DevOps チームは、Kubernetes の設定を見て、アプリケーションは正常に通信できるはずだと考えます。別の制御ソフトウェアによる制御内容は確認できないため、DevOps チームはアプリケーションが動かない原因が分からないという状況に陥ります。
DevOps チームとセキュリティチームが同じ仕組みを使ってコンテナ化アプリケーションの構築、デプロイ、セキュリティ保護を行えば、両チームが習得すべきインタフェースやツール、モデルの数は減ります。
DevOps チームは Kubernetes マニフェストファイルを使って、アプリケーションに必要なリソースを定義します。同じアセットを使ってセキュリティの状況を把握し、ポリシーを適用すれば、複雑さが減り、より効果的なセキュリティが実現します。
Kubernetes ネイティブセキュリティでは、Kubernetes をセキュリティポリシーの信頼できる情報源として扱います。そのため、セキュリティ、運用、DevOps、サイト信頼性エンジニアリング (SRE) など、あらゆるチームが 1 つの同じ信頼できる情報源に基づいて作業することになります。
さらに、セキュリティの問題はこうしたチームが日常的に使用する Kubernetes オブジェクトやリソースに直接対応しているので、運用がさらに単純化されます。
セキュリティポリシーに Kubernetes ネイティブの適用機能を使用することで、個別のセキュリティ・ソフトウェアの導入に伴う運用リスクを回避できます。
分析と修復の迅速化
コンテナの導入により、さまざまな面でクラウドネイティブ・アプリケーションのセキュリティは複雑化しています。事実、コンテナ環境ではインシデントが広範囲に散在し、生成されるデータ量も膨大であるのに加え、コンテナは一時的 (エフェメラル) であるため、従来のインシデント対応では不十分となっています。
Kubernetes ネイティブセキュリティにより、コンテナへの脅威をより正確に検知できるため、環境全体で効果的にセキュリティを適用するための時間と手間を大幅に削減できます。
Kubernetes のコンテキストにおいては、期待される動作が明確です。その結果、Kubernetes ネイティブセキュリティによる異常検知の精度が高まり、Pod の停止などの各種対応を安心して適用できます。
同時に、Kubernetes のコンテキストを活用することで、誤検知やアラート疲れも軽減できます。
また、Kubernetes ネイティブセキュリティなら、リスクに応じた効率的なセキュリティ対策を実現できます。
デプロイメントには多くのポリシー違反が潜んでいると考えられますが、どこから手を付ければよいのでしょうか？ここでも、Kubernetes のコンテキストを活用できます。
クラスタの環境 (開発環境/本番環境)、インターネットへの公開状況、アプリケーションの重要度、現在実行中の不審なプロセスの有無など、Kubernetes の各種メタデータを統合することで、チームが今すぐ対応すべき箇所が明確になります。
Kubernetes 固有の脆弱性、特に Kubernetes API サーバーを危険にさらす可能性のある脆弱性の検知は、それを防止、特定、修復する上できわめて重要です。Kubernetes ネイティブ・セキュリティ・ツールを利用することで、こうした脆弱性を自動で特定できます。
Kubernetes API サーバーと連携することで、Kubernetes クラスタ上で稼働するコンテナだけでなく、デプロイメントやデーモンセット、サービス、Pod などの Kubernetes リソースも含めたセキュリティ監視が可能になります。
Kubernetes のオープンな特性は、新たな脅威ベクトルにもなります。Kubernetes は何をおいても第一にインフラストラクチャ運用プラットフォームであり、すべてのコンポーネントで運用しやすさが優先されています。したがって、すべてのコンポーネントが必ずしもデフォルトで安全というわけではありません。
Kubernetes ネットワークポリシーを適用して通信を制限することも、Kubernetes デプロイメントのセキュリティ保護における重要な要素です。Kubernetes ネイティブ・セキュリティ・プラットフォームは、自動的にネットワーク・アクティビティの基準を設定し、アプリケーションに必要な通信経路を特定し、ネットワークアクセス範囲を絞るための適切な YAML ファイルを生成します。
Kubernetes ネイティブ・プラットフォームの自動セキュリティ設定により、Kubernetes レイヤーでの脅威を継続的に検知、阻止できます。
一度構成すれば、どこでも使える
また、Kubernetes ネイティブセキュリティは、高い可搬性と再利用性を生み出します。Kubernetes が稼働するすべての環境で共通の標準化されたアプローチを採用することで、環境が違っても一貫してポリシーを適用できます。
ユーザーはクラスタ内のホストごとにシステムレベルの制御を構成するのではなく、単一の設定 (ネットワークポリシーなど) を指定してデプロイメント内のすべての Pod に適用できます。
CI/CD システムや Kubernetes のアドミッション・コントローラー・フレームワークにポリシーを組み込むことで、組織はソフトウェア開発ライフサイクルにおいて早期に制御ポリシーを適用しやすくなり、実行時にリスクにさらされることを防ぎます。
さらに、Kubernetes のアドミッション・コントローラーなどの要素を活用することで、セキュリティを Kubernetes ツールチェーンの中核に組み込めます。
Red Hat 公式ブログ
Red Hat のお客様、パートナー、およびコミュニティのエコシステムに関する最新の情報を入手しましょう。
