Kubernetesは、事実上のコンテナオーケストレーションプラットフォームとして、組織がコンテナ化されたアプリケーションを展開、スケール、管理する方法を変革しました。その強力な機能と柔軟性を提供する一方で、Kubernetesの本質的な複雑さと動的な性質は、いくつかのセキュリティ課題をもたらします。Kubernetesクラスターが複数のノードにまたがり、多様なワークロードをホストする中で、セキュリティの維持は困難な作業となります。
本記事では、一般的なKubernetesセキュリティの課題と、それらに対処するための実践的な戦略について解説します。
Kubernetesセキュリティの必要性
企業がワークロードをKubernetesへ移行する中で、
2023年のCloud Native Computing Foundationの調査によると、回答者の93%が過去1年間に少なくとも1件のKubernetesセキュリティインシデントを経験し、78%が自社のセキュリティ体制に自信がないと回答しています。また、Aqua Securityの別のレポートでは、本番環境でKubernetesを運用している組織の90%が同期間中にセキュリティインシデントを経験したことが明らかになりました。
近年の著名なインシデントは、堅牢なKubernetesセキュリティ対策の重要性を浮き彫りにしています。2018年にはTeslaのKubernetesコンソールが侵害され、機密データの漏洩や暗号通貨マイニングのための計算リソースの不正利用が発生しました。さらに2021年には、コンテナランタイムの脆弱性（CVE-2021-32760）により、攻撃者がコンテナの隔離を回避し、ホストシステムへのrootアクセスを得る可能性がありました。
これらのインシデントは、Kubernetesセキュリティが任意ではなく、大規模なコンテナ化ワークロードを運用するすべての組織にとって基本的要件であることを強く示しています。
近年発見された主なKubernetesの脆弱性には、以下のものがあります。
- CVE-2018-1002105: Kubernetes APIサーバーの重大な欠陥により、認証されていないユーザーが権限を昇格し、クラスター内の任意のPodでコマンドを実行できる可能性がありました。
- CVE-2019-11246: `kubectl cp`コマンドの脆弱性により、攻撃者がユーザーのワークステーション上の任意のパスに悪意のあるファイルを書き込む可能性がありました。
- CVE-2020-8554: LoadBalancerおよびExternalIPsサービスの外部IPアドレスに影響する中間者攻撃の脆弱性。
- CVE-2021-25741: ボリュームのサニタイズ処理のバグにより、攻撃者が以前に終了したPodから機密情報へアクセスできる可能性がありました。
なぜKubernetesは安全ではないのか？
Kubernetesの多層的なアーキテクチャは、以下のようなさまざまな脆弱性を本質的に内包しています。
- APIサーバーの露出: クラスターの制御プレーンの中枢であるAPIサーバーは、主要な攻撃対象となります。
- RBACの誤設定: 不適切に定義されたロールや権限により、不正アクセスが発生する可能性があります。
- ネットワークポリシーの未制限: ネットワーク分離がない場合、クラスター内でのラテラルムーブメントが容易になります。
- デフォルトのコンテナ設定: root権限やデフォルト設定で実行されるコンテナは、悪用されやすくなります。
CNAPPマーケットガイドKubernetesのセキュリティ課題
Kubernetesのセキュリティ状況は常に進化しており、新たな脅威が定期的に出現しています。しかし、以下の課題はKubernetes管理者やセキュリティチームが直面する最も重要かつ継続的な課題の一部です。
#1. 不正アクセスと権限昇格
Kubernetesリソースへの不正アクセスは、現在クラスターが直面する最も重大なセキュリティリスクの一つです。攻撃者がクラスターへのアクセスを得た場合、悪意のあるコードの実行、機密データの窃取、運用の妨害などが発生する可能性があります。
対策方法：
- 強力なロールベースアクセス制御（RBAC）ポリシーの実装：
- 最小権限の原則に従ったきめ細かなロールおよびクラスター・ロールを定義します。
- ネームスペースを使用してワークロードを分離し、権限の範囲を制限します。
- RBACポリシーを定期的に監査・見直しし、適切性を維持します。
- Kubernetes Pod Security Policies（PSP）またはPod Security Standards（PSS）の有効化と設定：
- 特権コンテナの防止やホストネームスペースアクセスの制限など、Podの作成・実行に制約を設けます。
- PSP/PSSを活用し、クラスター全体でセキュリティベストプラクティスを徹底します。
- 強力な認証メカニズムの実装：OpenID Connect（OIDC）や他のフェデレーションIDプロバイダーをユーザー認証に利用します。
- すべてのクラスターアクセスに多要素認証（MFA）を強制します。
- サービスアカウントトークンを定期的にローテーションし、権限を制限します。
- Kubernetes APIサーバーの保護：
- PodSecurityPolicyやNodeRestrictionなどのAPIサーバーアドミッションコントローラーを有効化・設定します。
- すべてのAPIサーバー通信にTLSを使用し、クライアント証明書を検証します。
#2. APIサーバー設定の不備
Kubernetes APIサーバーはクラスターリソース管理の主要なエントリーポイントです。APIサーバーの設定ミスや脆弱性は、クラスターセキュリティに深刻な影響を及ぼします。
対策方法：
- APIサーバーエンドポイントの保護：
- すべてのAPIサーバー通信に強力なTLS暗号化を使用します。
- IPホワイトリストを実装し、信頼できるネットワークからのアクセスのみに制限します。
- リモートアクセスにはバスチオンホストやVPNの利用を検討します。
- アドミッションコントローラーの有効化と設定：
- AlwaysPullImagesアドミッションコントローラーを使用し、常に最新のイメージバージョンを利用します。
- NodeRestrictionアドミッションコントローラーを有効化し、kubeletの権限を制限します。
- 組織固有のセキュリティポリシーに合わせてカスタムアドミッションコントローラーを実装します。
- 監査ログとモニタリング：
- Kubernetes監査ログを有効化・設定し、すべてのAPIサーバーリクエストを追跡します。
- FalcoやSysdigなどのツールを利用し、APIサーバーの不審なアクティビティを検知・アラートします。
- 定期的な脆弱性スキャン：
- APIサーバーおよび関連コンポーネントの定期的な脆弱性スキャンを実施します。
- Kubernetesのセキュリティアドバイザリを常に確認し、迅速にパッチを適用します。
#3. 脆弱なコンテナイメージ
コンテナイメージはKubernetesワークロードの基盤です。古いまたは脆弱なイメージの使用は、クラスターに重大なセキュリティリスクをもたらします。
対策方法：
- イメージスキャンの実施：
- Trivy、Clair、Anchoreなどのツールを使用し、既知の脆弱性についてイメージをスキャンします。
- CI/CDパイプラインにイメージスキャンを統合し、脆弱なイメージのデプロイを防止します。
- イメージ署名と検証の徹底：
- 信頼できるイメージレジストリを利用し、Notaryなどのツールでイメージ署名を実施します。
- アドミッションコントローラーを設定し、信頼できるソースからの署名済みイメージのみを許可します。
- イメージの攻撃対象領域の最小化：
- Alpineやdistrolessなどの最小ベースイメージを使用し、攻撃対象領域を削減します。
- 本番イメージから不要なパッケージやユーティリティを削除します。
- イメージの最新化：
- ベースイメージやアプリケーション依存関係を定期的に更新します。
- アップデートが利用可能な場合、自動的にイメージを再ビルド・再デプロイするプロセスを導入します。
#4. ネットワークポリシーの誤設定
Kubernetesのデフォルトネットワーク設定では、すべてのPodが相互に通信可能です。これにより、侵害時のラテラルムーブメントが発生しやすくなります。
対策方法：
- ネットワークポリシーの実装：
- Kubernetes Network Policiesを使用し、Pod間通信のルールを定義・適用します。
- 「全拒否」デフォルト方針を採用し、必要な通信のみ明示的に許可します。
- ネットワークトラフィックの分割：
- ネームスペースを活用してワークロードを論理的に分離し、ネームスペース単位でネットワークポリシーを適用します。
- ネットワークのマイクロセグメンテーションを実施し、侵害時の影響範囲を限定します。
- Pod間通信の暗号化：
- IstioやLinkerdなどのサービスメッシュを利用し、Pod間トラフィックを暗号化します。
- クラスター内部通信すべてに相互TLS（mTLS）を実装します。
- ネットワークトラフィックの監視：
- CiliumやCalicoなどのツールを利用し、高度なネットワーク可視化とポリシー適用を行います。
- ネットワークフローログや分析を実施し、異常なトラフィックパターンを検知します。
#5. シークレット管理
APIキー、パスワード、証明書などの機密情報の適切な管理は、Kubernetesワークロードのセキュリティ維持に不可欠です。
対策方法：
- Kubernetes Secretsの利用：
- 機密情報はPod仕様やConfigMapにハードコーディングせず、Kubernetes Secretsに保存します。
- AWS KMSやHashiCorp Vaultなどの暗号化プロバイダーを利用し、Secretsを保存時に暗号化します。
- 外部シークレット管理の導入：
- External Secrets OperatorやSealed Secretsなどのツールを利用し、外部シークレット管理システムと連携します。
- ジャストインタイムでのシークレット払い出しを実施し、機密情報の露出を最小化します。
- シークレットの定期的なローテーション：
- すべての機密認証情報について自動シークレットローテーションを実施します。
- 可能な限り短命なトークンや証明書を使用し、侵害時の影響を最小化します。
- シークレットアクセスの制限：
- RBACを利用し、必要最小限のアクセス権でSecretsへのアクセスを制限します。
- すべてのSecretアクセス・変更について監査ログを実装します。
#6. etcdデータストアのセキュリティ
etcdキーバリューストアは、Kubernetesのすべてのクラスター状態の主要なデータストアです。etcdが侵害されると、攻撃者はクラスター全体を制御できる可能性があります。
対策方法：
- etcdデータの保存時暗号化：
- EncryptionConfigurationリソースを利用し、etcdの暗号化を有効化します。
- 強力な暗号鍵を使用し、定期的にローテーションします。
- etcd通信の保護：
- すべてのetcdピアおよびクライアント通信にTLSを使用します。
- etcdアクセスにはクライアント証明書認証を実装します。
- バックアップと災害復旧：
- etcdデータの定期的かつ暗号化されたバックアップを実施します。
- データの整合性を確保するため、etcdリストア手順をテスト・検証します。
- etcdアクセスの制限：
- etcdを専用ノードで実行し、アクセスを制限します。
- ネットワークポリシーを利用し、etcdと通信できるコンポーネントを制限します。
#7. ランタイムセキュリティリスク
コンテナランタイムセキュリティは、稼働中のコンテナの脆弱性を悪用する攻撃から保護するために重要です。
対策方法：
- ランタイムセキュリティ監視の実装：
- FalcoやSysdigなどのツールを利用し、コンテナの不審な挙動を検知・アラートします。
- 挙動ベースラインを確立し、異常なコンテナアクティビティを特定します。
- SELinuxまたはAppArmorの有効化：
- SELinuxやAppArmorプロファイルを利用し、コンテナの権限やファイルシステムアクセスを制限します。
- アプリケーション要件に応じたカスタムセキュリティプロファイルを実装します。
- seccompプロファイルの利用：
- seccompプロファイルを実装し、コンテナで利用可能なシステムコールを制限します。
- デフォルト拒否プロファイルから開始し、必要なシステムコールのみを段階的に許可します。
- コンテナサンドボックス化：
- gVisorやKata Containersの利用を検討し、コンテナとホストシステム間の隔離を強化します。
#8. ログおよびモニタリングのギャップ
Kubernetes環境でのセキュリティインシデントの検知・対応には、包括的なログ収集とモニタリングが不可欠です。
対策方法：
- 集中型ログ管理：
- ELKスタックやSplunkなどの集中型ログソリューションを導入し、すべてのクラスターコンポーネントからログを集約します。
- FluentdやLogstashなどのログ転送エージェントを利用し、コンテナやノードからログを収集します。
- 堅牢なモニタリングの実装：
- PrometheusやGrafanaを利用し、クラスターのヘルスやパフォーマンス指標を監視します。
- カスタムアラートルールを実装し、潜在的なセキュリティ問題を検知します。
- セキュリティ情報・イベント管理（SIEM）：
- KubernetesのログやメトリクスをSIEMソリューションと連携し、高度な脅威検知・相関分析を実施します。
- 一般的なセキュリティイベントに対する自動インシデントレスポンスプレイブックを実装します。
- 継続的なコンプライアンス監視：
- Kube-benchやKube-hunterなどのツールを利用し、クラスターのセキュリティベストプラクティス準拠状況を継続的に評価します。
- 一般的な設定ミスに対する自動修復を実装します。
#9. サプライチェーン攻撃
コンテナイメージや依存関係を含むソフトウェアサプライチェーンは、Kubernetes環境に脆弱性を持ち込む経路となり得ます。
対策方法：
- ソフトウェア部品表（SBOM）の実装：
- すべてのコンテナイメージやアプリケーション依存関係についてSBOMを生成・管理します。
- SyftやTernなどのツールを利用し、ビルドプロセス中にSBOMを自動生成します。
- CI/CDパイプラインの保護：
- すべてのCI/CDシステムに対して強力なアクセス制御と認証を実装します。
- 署名付きコミットや検証済みビルドを利用し、デプロイアーティファクトの完全性を確保します。
- 脆弱性管理：
- ソフトウェアサプライチェーンのすべてのコンポーネントに対して継続的な脆弱性スキャンを実施します。
- DependabotやSnykなどのツールを利用し、既知の脆弱性を持つ依存関係を自動的に更新します。
- アーティファクトストレージの保護：
- 信頼できるアクセス制御付きアーティファクトリポジトリを利用し、コンテナイメージやその他のビルドアーティファクトを保存します。
- イメージ署名と検証を実施し、デプロイアーティファクトの完全性を確保します。
#10. コンポーネントの陳腐化とCVE
Kubernetesコンポーネントおよび関連ツールを最新の状態に保つことは、クラスターのセキュリティ体制維持に不可欠です。
対策方法：
- 定期的なパッチ適用とアップデート：
- 制御プレーン、ワーカーノード、アドオンを含むすべてのKubernetesコンポーネントに対して、定期的なパッチ適用スケジュールを実施します。
- kube-benchなどのツールを利用し、陳腐化したコンポーネントや設定ミスを特定します。
- CVEの監視と管理：
- Kubernetesのセキュリティアドバイザリや関連CVEフィードを購読します。
- クラスターコンポーネントに影響するCVEの評価・優先順位付けプロセスを実装します。
- 自動アップデートテスト：
- 本番適用前に、ステージング環境でKubernetesアップデートの自動テストを実施します。
- カナリアデプロイやブルーグリーンアップデートを利用し、潜在的な問題の影響を最小化します。
- バージョンスキュー管理：
- Kubernetesコンポーネント間のサポートされるバージョンスキューを把握し、すべてのコンポーネントがサポート範囲内であることを確認します。
- 最新のセキュリティ機能や修正を維持するため、定期的なメジャーバージョンアップグレードを計画します。
Kubernetesセキュリティのベストプラクティス
個別のセキュリティ課題への対応に加え、包括的なセキュリティベストプラクティスを実装することは、堅牢なKubernetesセキュリティ体制の維持に不可欠です。以下は考慮すべき主なプラクティスです。
1. イメージスキャン
アプリケーション用のイメージをビルドする際、信頼できないレジストリからのコード利用など、複数のセキュリティ攻撃対象領域が生じる可能性があります。
攻撃者はイメージ内のこれらの脆弱性を利用してコンテナから脱出し、ホストやKubernetesワーカーノードへのアクセスを得る可能性があります。成功した場合、同一ホスト上で稼働する他のすべてのコンテナにアクセスできるようになります。このレベルの制御を得ることで、ホストボリュームやファイルシステム、さらにはKubeletの設定（Kubeletの認証トークンやKubernetes APIサーバーとの通信に使用する証明書など）を読み取ることが可能となります。これにより、攻撃者はさらなるクラスターへの損害や権限昇格を引き起こす可能性があります。
したがって、Sysdig、Synk、Trivyなどのツールを用いて、コンテナイメージの脆弱性を定期的にスキャンすることが重要です。これらのツールは脆弱性データベースを持ち、イメージを既知の脆弱性と照合してスキャンします。これはCI/CDパイプラインのビルド時に、レジストリへプッシュする前に実施できます。
2. 非rootユーザーでの実行
可能な限り、コンテナを非rootユーザーで実行するように設定してください。イメージビルド時に専用のサービスユーザーを作成し、rootユーザーではなくそのユーザーでアプリケーションを実行します。これにより、コンテナ侵害時の影響範囲を限定できます。
# グループとユーザーの作成
RUN groupadd -r myapp && useradd -g myapp myapp
# 所有権と権限の設定
RUN chown -R myapp:myapp / app
# ユーザーの切り替え
USER myapp
MD node index.js
注意： Pod自体の設定ミスにより、この設定が上書きされる可能性があります。
Pod仕様のsecurityContextフィールドを利用し、runAsUserおよびrunAsGroupに0以外の値を設定してください。さらに、allowPrivilegeEscalation: falseを設定し、コンテナ内での権限昇格を防止します。
3. RBACによるユーザーと権限管理
きめ細かなロールベースアクセス制御（RBAC）ポリシーを実装し、ユーザーやサービスアカウントに必要最小限の権限のみを付与します。RBACポリシーを定期的に監査し、不要な権限を削除します。rbac-lookupや`rakkess`などのツールを利用し、RBAC設定の可視化・分析を行います。
4. ネットワークポリシーの利用
デフォルトでは、クラスター内の各Podは相互に通信可能です。つまり、攻撃者が1つのPodにアクセスした場合、他のアプリケーションPodにもアクセスできてしまいます。しかし、実際にはすべてのPodが相互通信する必要はないため、Kubernetes Network Policiesを実装し、Pod間およびPod-外部間の通信を制御することで、通信を制限できます。
「全拒否」デフォルト方針を採用し、必要な通信のみ明示的に許可します。CiliumやCalicoなどのツールを利用し、高度なネットワークポリシーの適用と可視化を実現します。
最大限の
5. 通信の暗号化
KubernetesのPod間通信は暗号化されていないため、攻撃者は通信内容を平文で読み取ることができます。APIサーバー通信、etcdピアおよびクライアントトラフィック、kubelet接続にはTLSを使用してください。IstioやLinkerdなどのサービスメッシュを導入し、Pod間通信に相互TLS（mTLS）を実装します。
6. シークレットデータの保護
認証情報やシークレットトークン、秘密鍵などの機密データは、Kubernetesのsecretsリソースに保存されますが、デフォルトではbase64エンコードのみで暗号化されていません。そのため、Secretsの閲覧権限を持つ者は内容を簡単に復号できます。
ネイティブなKubernetes Secretsを利用し、機密情報を保存し、暗号化プロバイダーを用いて保存時に暗号化してください。
HashiCorp VaultやAWS Secrets Managerなどの外部シークレット管理ソリューションを利用し、複数クラスターにまたがるシークレットのセキュリティと集中管理を強化することも検討してください。
7. etcdストアの保護
etcdデータを保存時に暗号化し、TLSを用いてetcd通信を保護します。etcdアクセスにはクライアント証明書認証を実装し、ネットワークポリシーでetcdノードへのアクセスを制限します。etcdデータの定期的なバックアップとリストア手順のテストも実施してください。
8. 自動バックアップとリストア
クラスター状態（etcdデータや永続ボリュームを含む）の自動かつ暗号化されたバックアップを実施します。災害時のダウンタイムを最小化し、データ整合性を確保するため、リストア手順を定期的にテストしてください。Kubernetesネイティブなバックアップ・リストア機能を持つVeleroなどのツール利用も検討してください。
9. セキュリティポリシーの設定
Open Policy Agent（OPA）GatekeeperやKyvernoなどのツールを利用し、セキュリティポリシーを実装・強制します。これらのツールにより、特定ラベルの必須化、リソース制限の強制、特権コンテナの利用制限など、クラスター全体でカスタムポリシーを定義・適用できます。
10. 災害復旧
Kubernetesクラスターの包括的な災害復旧計画を策定し、定期的にテストしてください。ノード障害、制御プレーン障害、データ破損など、さまざまな障害シナリオからの復旧手順を含めます。重要なワークロードについては、マルチリージョンやマルチクラスター戦略を導入し、高可用性とレジリエンスを確保します。
SentinelOneによるKubernetesセキュリティ
SentinelOneは、エンドポイントセキュリティ、検知、対応に特化したサイバーセキュリティプラットフォームです。Kubernetesセキュリティにおいては、SentinelOneはKubernetes環境をポリシーベースで保護する方法を提供します。以下はSentinelOneのKubernetesセキュリティポリシーの概要です。
主な機能：
- Kubernetesセキュリティ体制管理: クラスター、ノード、Podのセキュリティ体制を包括的に可視化します。設定ミス、脆弱なイメージ、コンプライアンス問題の特定も可能です。
- Policy-as-Code: SentinelOneでは、セキュリティポリシーをYAML/JSONファイルとしてコード化し、バージョン管理や自動化、一貫性の確保が可能です。
- リアルタイム脅威検知: 行動AIエンジンにより、コンテナエスケープ、権限昇格、ラテラルムーブメントなどの脅威をリアルタイムで検知・対応します。
- 自動対応: 脅威の封じ込めや修復を自動対応で実施し、MTTDおよびMTTRを短縮します。
- コンプライアンスとガバナンス: SentinelOneは、PCI-DSS、HIPAA、GDPRなどのコンプライアンス維持のためのカスタマイズ可能なポリシーとレポート機能を提供します。
SentinelOneがKubernetesのセキュリティを確保するためにサポートするポリシーの種類は以下の通りです。
- ネットワークポリシー： Podやサービス間のトラフィックフロー（インバウンド・アウトバウンド）を制御します。
- Podセキュリティポリシー: Podレベルのセキュリティ設定、権限昇格、ボリュームマウント、ネットワークポリシーを定義します。
- クラスターセキュリティポリシー: 認証、認可、アドミッションコントロールなど、クラスター全体のセキュリティ設定を強制します。
- イメージセキュリティポリシー: イメージの脆弱性スキャンやセキュリティベンチマーク準拠の強制を行います。
SentinelOneがポリシーを強制する方法は以下の通りです。
- Kubernetesアドミッションコントロール： Kubernetesアドミッションコントロールと連携し、受信リクエストに対してポリシーを強制します。
- コンテナランタイムセキュリティ: ランタイム中の不正なアクティビティからコンテナを保護します。
- ネットワークトラフィック制御: 定義されたネットワークポリシーに基づき、トラフィックの許可・拒否を実施します。
サーバー、VM、コンテナ向けのAI搭載クラウドワークロード保護（CWPP）。実行時の脅威をリアルタイムで検知・阻止します。
まとめ
Kubernetes環境のセキュリティ確保は複雑かつ継続的なプロセスであり、多層的なアプローチが求められます。本記事で解説した主要なセキュリティ課題への対応とベストプラクティスの実践により、組織はリスクエクスポージャーを大幅に低減し、より堅牢なコンテナ化インフラを構築できます。
Kubernetesセキュリティは一度限りの取り組みではなく、継続的な改善・監視・適応のプロセスであることを忘れないでください。Kubernetesエコシステムにおける最新のセキュリティ動向を常に把握し、クラスターのセキュリティ体制を定期的に評価し、新たな脅威や脆弱性が出現した際には迅速に対応できるよう備えておきましょう。
よくある質問
Kubernetes のセキュリティ上の懸念点には、API サーバーの公開、RBAC の誤設定、未スキャンのコンテナイメージ、不適切なネットワークポリシー、不適切なシークレット管理などがあります。
RBAC の適用、ネットワークポリシーの活用、イメージの脆弱性スキャン、通信の暗号化、シークレットや etcd データの安全な管理によってセキュリティを維持できます。
Kubernetes セキュリティの 4C とは、Cloud、Cluster、Container、Code です。各レイヤーを保護することで、Kubernetes 環境全体のセキュリティを確保します。
