Kubernetes のセキュリティとは
Kubernetes のセキュリティは、クラウドネイティブ セキュリティの 4C(クラウド、クラスタ、コンテナ、コード)をベースにしています。
- クラウド(または企業のデータセンター/コロケーション施設):Kubernetes のセキュリティの土台は、基盤となる物理インフラストラクチャです。クラスタを自社のデータセンター上で構築する場合でも、クラウド プロバイダー上で構築する場合でも、クラウド プロバイダー(または物理セキュリティ)の基本的なベスト プラクティスを順守する必要があります。
- クラスタ:Kubernetes クラスタを保護するには、Kubernetes API などの構成可能なコンポーネントと、クラスタに含まれるすべてのアプリケーションのセキュリティが必要になります。クラウドネイティブ アプリケーションの多くは、マイクロサービスや API を中心に設計されているため、アプリケーションのセキュリティの強度は、そのアプリケーション全体を構成するサービスのチェーンにおけるもっとも弱いリンクと同程度にしかなりません。
- コンテナ:コンテナを設計するにあたっては、できるだけ小さなコードベースから始める(不要なライブラリや関数を除く)、コンテナ内のユーザーに不要な権限を与えない、コンテナの構築時に脆弱性のスキャンを確実に行う、などのベスト プラクティスがあります。
- コード:コードは、あらゆる Kubernetes 環境にとって主要な攻撃対象領域となります。TLS ハンドシェイクによる TCP の暗号化、未使用ポートの非公開、スキャン、定期的なテストなどの簡単なポリシーで、本番環境でのセキュリティ問題の発生を防止できます。

5 分でわかる Kubernetes

2022 年 Kubernetes の現状
Kubernetes のセキュリティがコンテナのライフサイクルを通じて重要な理由
Kubernetes のセキュリティは、Kubernetes クラスタが分散型で動的な性質を持つことから、コンテナのライフサイクル全体を通じて重要になります。アプリケーションのライフサイクルを構成する 3 つのフェーズ(ビルド、展開、実行)のそれぞれに、異なるセキュリティ アプローチが必要です。Kubernetes には、元々備わっているセキュリティ上のメリットがあります。たとえば、アプリケーション コンテナでは通常、パッチやアップデートを行わず、コンテナ イメージが新しいバージョンにそっくり置き換わります。これにより厳密なバージョン管理が可能となり、新しいコードに脆弱性が発見された場合も迅速にロールバックできます。
ただし、個々のポッドは一過性の短期的な存在であり、アプリケーション、およびほかのアプリケーションやサービスとの API リンクが流動的であることから、常に変化するランタイム環境が IT セキュリティ担当にとって課題となる可能性があります。
アプリケーションのライフサイクル全体における Kubernetes のセキュリティの主な脆弱性とその対処法
Kubernetes のセキュリティ ツールには以下が求められます。
- コードに侵害がないことを確認する時間を短縮する。
- コードの信頼性を高めるためにデジタル署名を提供する。
- コードだけでなく、構成上の問題についても可視性と透明性を確保する。
- 安全でないサービスへの情報の Ingress(受信接続)または Egress(送信接続)を防止する。
ビルド時における Kubernetes のセキュリティの主な脆弱性
- 信頼できないレジストリのコード。信頼できないコードにはマルウェアやバックドアが含まれていることがあり、悪意ある人物に意図せずアクセスを許可してしまう可能性があります。
- 基本イメージの肥大化。コンテナ化されたアプリケーションでは、よりコンパクトであることが重要であるため、危険にさらされる可能性のある不要なパッケージ、ライブラリ、およびシェルは排除する必要があります。
展開時における Kubernetes のセキュリティの主な脆弱性
- 不要な権限の付与。可能な限り権限を最小限に抑え、タスクが必要とするシークレットのみをマウントすることで、攻撃対象領域を縮小できます。
- クラスタ内のアプリケーションを分離できない。ネームスペースを使用して、リソースとチームを相互に分離する必要があります。
- クラスタ内でのラテラルムーブメント。ネットワークをセグメント化するポリシーを使用して、クラスタ内での攻撃のラテラルムーブメント防ぎます。
- 不正アクセス。アクセスを制限するためのロールベースのアクセス コントロール(RBAC)を確実に設定します。
実行時における Kubernetes のセキュリティの主な脆弱性
- インフラストラクチャ攻撃。API サーバ、etcd、コントローラなど、Kubernetes のすべてのインフラストラクチャ要素は、実行時にそれぞれが攻撃対象領域となります。
- 複雑性。Kubernetes クラスタの継続的な健全性には、さまざまな動的要素があります。侵害されたコンテナは迅速に隔離、停止して、健全なコンテナと交換する一方で、攻撃源を突き止め、修正する必要があります。
Kubernetes のセキュリティ チェックリストの概要
ベスト プラクティスの推奨事項は以下のとおりです。最小限の Distroless イメージから始め、絶対に必要なものだけを追加します。コンパクトであるほど安全です。
- 最小限のホスト OS を使用し、読み取り専用マウントを終了して、SELinux オプションによって制御をさらに強化します。
- OS イメージや外部イメージなど、あらゆる種類のイメージに脆弱性がないか、徹底的にスキャンします。外部に信頼できるソースなど存在しません。
- ネームスペースと RBAC を使用して、クラスタとユーザーを論理的にセグメント化します。不要なものは視認できないようにします。
- Kubernetes ネットワークのデフォルトでは Any-to-Any の通信が許可されるため、ネットワーク セグメンテーションは本番稼働の前に実装する必要があります。接続が適切にルーティングされるように、Ingress と Egress のポリシーを慎重に定義します。
- 権限は最小限にとどめ、決してアプリケーション プロセスを root で実行してはなりません。読み取り専用のルート ファイルシステムを使用することで、ソフトウェアのインストールやファイルシステムの変更による攻撃を防ぐことができます。
- CI/CD パイプラインにイメージ スキャンなどのセキュリティを統合します。さらに、CIS Benchmark のセキュリティ テストを実施するのもおすすめです。
- クラスタ自体の安全性を確保します。API サーバへのアクセスを制限する RBAC を設定し、すべての etcd 通信が TLS 暗号化によって保護されていることを確認します。同様に、kubelet の RBAC を設定して、kubelet の認証をロックダウンします。
- ポッドへのアクセスを制限するためのセキュリティ コンテキストを設定するなど、Kubernetes に組み込まれたコントロールを活用します。
- プロアクティブなセキュリティでは、プロセスのアクティビティ、サービス間の通信、クラスタの外部との通信を監視することが必要になります。
関連するソリューションおよび製品
エンタープライズ対応の Kubernetes ランタイム
マルチクラウド インフラストラクチャ全体の運用を効率化
Kubernetes と Docker
コンテナを正常に運用するために選ぶべきツール
Kubernetes 上の Docker コンテナ
概要を理解した後の次のステップ:コンテナと Kubernetes の連携