Kubernetesセキュリティ上の主要な10の問題

Kubernetesクラスターは複数のノードにまたがり多様なワークロードをホストするため、セキュリティ維持は困難な課題となります。本記事では一般的なKubernetesセキュリティ問題を探ります。

事実上のコンテナオーケストレーションプラットフォームであるKubernetesは、組織がコンテナ化されたアプリケーションを展開、スケーリング、管理する方法を一変させました。膨大なパワーと柔軟性を提供する一方で、その本質的な複雑さと動的な性質は、いくつかのセキュリティ上の課題をもたらします。Kubernetesクラスターが複数のノードにまたがり、多様なワークロードをホストするにつれ、セキュリティの維持は困難な課題となります。

本稿では、一般的なKubernetes セキュリティ に関する問題点を検証し、それらに対処するための実践的な戦略を提供します。

Kubernetesセキュリティの必要性

企業がワークロードをKubernetesに移行するにつれ、

2023年のクラウドネイティブコンピューティング財団（CNCF）の調査によると、回答者の93%が過去1年間に少なくとも1件のKubernetesセキュリティインシデントを経験しており、78%が自社のセキュリティ態勢に自信を持てないと回答しました。一方、別のAqua Securityのレポートでは、本番環境でKubernetesを運用している組織の驚異的な90%が、同じ期間中にセキュリティインシデントに遭遇したことが明らかになっています。

近年の注目すべきインシデントは、堅牢なKubernetesセキュリティ対策の重要性を浮き彫りにしている。2018年にはテスラのKubernetesコンソールが侵害され、機密データの漏洩や暗号通貨マイニング目的での不正なコンピューティングリソース利用が発生した。さらに2021年には、コンテナランタイムの脆弱性（CVE-2021-32760）により攻撃者がコンテナの隔離を突破し、ホストシステムへのルートアクセス権を取得する可能性が生じた。

これらの事象は、Kubernetesのセキュリティ対策が任意の選択ではなく、大規模なコンテナ化ワークロードを運用するあらゆる組織にとって不可欠な要件であることを痛烈に示しています。

近年発見された主なKubernetes脆弱性には以下が含まれます：

• CVE-2018-1002105: Kubernetes APIサーバーの重大な欠陥により、権限のないユーザーが権限を昇格させ、クラスター内の任意のポッド上で任意のコマンドを実行できる可能性がありました。
• CVE-2019-11246:`kubectl cp`コマンドの脆弱性により、攻撃者がユーザーのワークステーション上の任意のパスに悪意のあるファイルを書き込む可能性がありました。
• CVE-2020-8554: LoadBalancer および ExternalIPs サービスにおける外部 IP アドレスに影響を与える中間者攻撃の脆弱性。
• CVE-2021-25741:ボリュームのサニタイズ処理におけるバグにより、攻撃者が以前に終了したポッドから機密情報にアクセスできる可能性があります。

Kubernetesが安全でない理由とは？

Kubernetes の多面的なアーキテクチャは、本質的に以下のような様々な脆弱性をもたらします：

• APIサーバーの露出: クラスターの制御プレーンの中枢であるAPIサーバーは、主要な標的となります。
• 誤設定されたRBAC:不適切に定義されたロールと権限は不正アクセスを招く可能性があります。
• 制限のないネットワークポリシー: ネットワークセグメンテーションの欠如は、クラスター内での横方向の移動を容易にします。
• デフォルトのコンテナ設定: ルート権限またはデフォルト設定で実行されているコンテナは容易に悪用される可能性があります。

Kubernetesのセキュリティ問題

Kubernetesのセキュリティ環境は絶えず変化しており、新たな脅威が定期的に出現しています。しかし、以下の課題はKubernetes管理者やセキュリティチームが直面する最も重大かつ持続的な課題の一部です：

#1. 不正アクセスと権限昇格

Kubernetesリソースへの不正アクセスは、現在のクラスターが直面する最も重大なセキュリティリスクの一つです。クラスターへのアクセス権を取得した攻撃者は、悪意のあるコードの実行、機密データの窃取、または運用の中断を引き起こす可能性があります。

対処方法:

1. 強力なロールベースアクセス制御（RBAC）ポリシーを実装する：
   • 最小権限の原則に準拠した、きめ細かなロールとクラスターロールを定義する。
   • ワークロードを分離し、権限の範囲を制限するためにネームスペースを使用する。
   • RBAC ポリシーを定期的に監査および見直し、適切性を確保する。
2. Kubernetes Pod Security Policies (PSPs) または Pod Security Standards (PSS) を有効化し設定する：
   • 特権コンテナの防止やホストネームスペースへのアクセス制限など、ポッドの作成と実行に対する制限を適用する。
   • PSPs/PSSを使用してクラスター全体でセキュリティのベストプラクティスを適用する。
   • 強力な認証メカニズムを実装する： ユーザー認証にはOpenID Connect (OIDC) またはその他のフェデレーションIDプロバイダーを使用する。
   • すべてのクラスターアクセスに対して多要素認証（MFA）を強制する。
   • サービスアカウントトークンを定期的にローテーションし、その権限を制限する。
3. Kubernetes APIサーバーのセキュリティ対策:
   • PodSecurityPolicy や NodeRestriction などの API サーバーアドミッションコントローラーを有効化し設定する。
   • すべての API サーバー通信に TLS を使用し、クライアント証明書を検証する。

#2.安全でない API サーバーの設定

Kubernetes API サーバーは、クラスタリソースを管理するための主要なエントリポイントです。API サーバーの設定ミスや脆弱性は、クラスタのセキュリティに深刻な影響を及ぼす可能性があります。

対処方法：

1. APIサーバーエンドポイントの保護:
   • すべてのAPIサーバー通信に強力なTLS暗号化を使用する。
   • 信頼できるネットワークへのアクセスを制限するため、IPホワイトリストを実装する。
   • APIサーバーへのリモートアクセスには、バスティオンホストまたはVPNの使用を検討する。
2. アドミッションコントローラーを有効化し設定する:
   • AlwaysPullImages アドミッションコントローラーを使用して、最新のイメージバージョンが使用されるようにします。
   • NodeRestriction アドミッションコントローラーを有効化し、kubelet の権限を制限します。
   • 組織固有のセキュリティポリシー向けにカスタムアドミッションコントローラーを実装します。
3. 監査ログと監視:
   • すべての API サーバーリクエストを追跡するために Kubernetes 監査ログを有効化および設定する。
   • Falco や Sysdig などのツールを使用して、不審な API サーバーのアクティビティを検知し、警告を発する。
4. 定期的な脆弱性スキャン：&
   • APIサーバーおよび関連コンポーネントの定期的な脆弱性スキャンを実施する。
   • Kubernetesセキュリティアドバイザリを常に最新状態に保ち、パッチを速やかに適用する。

#3. 脆弱なコンテナイメージ

コンテナイメージはKubernetesワークロードの基盤を形成します。古いまたは脆弱なイメージを使用すると、クラスターに重大なセキュリティリスクをもたらす可能性があります。

対処方法:

1. イメージスキャンを実施する:
   • Trivy、Clair、Anchoreなどのツールを使用して、既知の脆弱性に対するイメージスキャンを実行する。
   • 脆弱な画像がデプロイされないよう、画像スキャンをCI/CDパイプラインに統合する。
2. イメージの署名と検証を強制する:
   • 信頼できるイメージレジストリを実装し、Notaryなどのツールを使用してイメージに署名する。
   • 承認コントローラーを設定し、信頼できるソースからの署名済みイメージのみを許可する。
3. イメージの攻撃対象領域を最小化する:
   • Alpineやdistressイメージのような最小限のベースイメージを使用し、潜在的な攻撃対象領域を削減する。&
   • 本番環境イメージから不要なパッケージやユーティリティを削除する。
4. イメージを最新の状態に保つ:
   • ベースイメージとアプリケーションの依存関係を定期的に更新する。
   • 更新が利用可能になったときに、イメージを再構築および再デプロイする自動化されたプロセスを実装する。

#4.ネットワークポリシーの設定ミス

Kubernetes のデフォルトのネットワーク設定では、すべてのポッドが相互に通信できるため、侵害が発生した場合に横方向の移動につながる可能性があります。

対処方法：

1. ネットワークポリシーの実装:
   • Kubernetes ネットワークポリシーを使用して、ポッド間通信のルールを定義し強制します。
   • デフォルトスタンスとして「すべて拒否」のデフォルトスタンスを採用し、必要なトラフィックを明示的に許可します。
2. ネットワークトラフィックをセグメント化：
   • ネームスペースを使用してワークロードを論理的に分離し、ネームスペースレベルでネットワークポリシーを適用する。
   • ネットワークのマイクロセグメンテーションを実装し、潜在的な侵害の影響範囲を制限する。
3. ポッド間トラフィックの暗号化:
   • IstioやLinkerdなどのサービスメッシュを使用してポッド間のトラフィックを暗号化する。
   • 内部クラスター通信のすべてに相互TLS（mTLS）を導入する。
4. ネットワークトラフィックの監視：
   • 高度なネットワーク可視化とポリシー適用にはCiliumやCalicoなどのツールを使用する。
   • 異常なトラフィックパターンを検出するため、ネットワークフローのロギングと分析を実施する。

#5. シークレット管理

APIキー、パスワード、証明書などの機密情報を適切に管理することは、Kubernetesワークロードのセキュリティ維持に不可欠です。

対処方法:

1. Kubernetes Secrets の使用:
   • 機密情報はポッド仕様やコンフィグマップにハードコーディングせず、Kubernetes Secrets に保存する。
   • AWS KMSやHashiCorp Vaultなどの暗号化プロバイダーを使用して、保存中のシークレットを暗号化します。
2. 外部シークレット管理の実装：
   • External Secrets OperatorやSealed Secretsなどのツールを使用して、外部シークレット管理システムと統合します。
   • 機密情報の露出を最小限に抑えるため、ジャストインタイムのシークレットプロビジョニングを実装します。&
3. シークレットを定期的にローテーションする:
   • すべての機密認証情報に対して自動化されたシークレットローテーションを実装する。
   • 可能な限り有効期間の短いトークンや証明書を使用し、侵害時の影響を最小限に抑える。
4. シークレットへのアクセス制限:
   • RBACを使用して、知る必要のある者だけにシークレットへのアクセスを制限する。
   • すべてのシークレットへのアクセスおよび変更に対して監査ログを記録する。

#6. etcd データストアのセキュリティ

etcdキーバリューストアは、Kubernetesの全クラスター状態の主要なデータストアです。etcdが侵害されると、攻撃者はクラスターを完全に制御できるようになります。

対処方法:

1. 保存状態のetcdデータを暗号化する:
   • EncryptionConfigurationリソースを使用してetcdの暗号化を有効化する。
   • 強固な暗号化キーを使用し、定期的にローテーションする。
   &
2. etcd通信の保護:
   • すべてのetcdピアおよびクライアント通信にTLSを使用する。
   • etcdアクセスにクライアント証明書認証を実装する。
4. バックアップと災害復旧:
   • etcdデータの定期的な暗号化バックアップを実施する。
   • etcd復元手順をテストおよび検証し、データの整合性を確保する。
5. etcdへのアクセスを制限する：
   • アクセスを制限した専用ノード上でetcdを実行する。
   • ネットワークポリシーを使用して、etcd と通信できるコンポーネントを制限する。

#7. ランタイムセキュリティリスク

コンテナランタイムセキュリティ は、稼働中のコンテナの脆弱性を悪用する攻撃から保護するために極めて重要です。

対処方法:

1. ランタイムセキュリティ監視の実装:
   • Falco や Sysdig などのツールを使用して、コンテナの疑わしい動作を検知し警告する。
   • 行動ベースラインを実装し、異常なコンテナ活動を特定する。
2. SELinuxまたはAppArmorを有効化する:
   • SELinuxまたはAppArmorプロファイルを使用して、コンテナの機能とファイルシステムへのアクセスを制限する。
   • 特定のアプリケーション要件に合わせてカスタムセキュリティプロファイルを実装します。
3. seccompプロファイルを使用する:
   • コンテナが利用可能なシステムコールを制限するseccompプロファイルを実装します。
   • デフォルト拒否プロファイルから開始し、必要なシステムコールを段階的に許可します。
4. コンテナのサンドボックス化：
   • gVisorやKata Containersの使用を検討し、コンテナとホストシステム間の分離を強化する。

#8. ログ記録と監視の不足点

包括的なロギングと監視は、Kubernetes環境におけるセキュリティインシデントの検知と対応に不可欠です。

対処方法:

1. 集中型ロギング:
   • ELKスタックやSplunkなどの集中型ロギングソリューションを導入し、クラスター全コンポーネントのログを集約する。
   • FluentdやLogstashなどのログ転送エージェントを使用して、コンテナやノードからログを収集します。
2. 堅牢な監視を実装する：
   • PrometheusとGrafanaを使用してクラスターの健全性とパフォーマンス指標を監視する。
   • 潜在的なセキュリティ問題を検出するためのカスタムアラートルールを実装する。
3. セキュリティ情報イベント管理（SIEM）:
   • 高度な脅威検出と相関分析のために、KubernetesログとメトリクスをSIEMソリューションと統合します。
   • 一般的なセキュリティイベント向けに自動化されたインシデント対応プレイブックを実装する。
4. 継続的なコンプライアンス監視:
   • Kube-benchやKube-hunterなどのツールを使用して、クラスターのセキュリティベストプラクティスへの準拠状況を継続的に評価する。
   • 一般的な設定ミスに対する自動修復を実装します。

#9. サプライチェーン攻撃

コンテナイメージや依存関係を含むソフトウェアのサプライチェーンは、Kubernetes環境に脆弱性を導入する経路となり得る。

対処方法:

1. ソフトウェア部品表（SBOM）の導入:
   • 全てのコンテナイメージとアプリケーション依存関係に対してSBOMを生成・維持する。
   • SyftやTernなどのツールを活用し、ビルドプロセス中にSBOMを自動生成する。
2. CI/CDパイプラインのセキュリティ確保:
   • 全てのCI/CDシステムに強力なアクセス制御と認証を実装する。
   • 署名付きコミットと検証済みビルドを使用して、デプロイされたアーティファクトの完全性を確保する。
3. 脆弱性管理:
   • ソフトウェアサプライチェーンの全コンポーネントに対し、継続的な脆弱性スキャンを実施する。
   • DependabotやSnykなどのツールを使用し、既知の脆弱性を持つ依存関係を自動的に更新する。
4. アーティファクトの安全な保管:
   • コンテナイメージやその他のビルドアーティファクトの保管には、信頼性が高くアクセス制御されたアーティファクトリポジトリを使用する。
   • デプロイされたアーティファクトの完全性を確保するため、イメージ署名と検証を実装する。

#10. 旧式コンポーネントとCVE

Kubernetes コンポーネントと関連ツールを最新の状態に保つことは、クラスターのセキュリティ態勢を維持するために極めて重要です。

対処方法:

1. 定期的なパッチ適用と更新:
   • コントロールプレーン、ワーカーノード、アドオンを含む全てのKubernetesコンポーネントに対し、定期的なパッチ適用スケジュールを実施する。
   • kube-benchなどのツールを使用して、古いコンポーネントや設定ミスを特定する。
2. CVEの監視と管理：
   • Kubernetesセキュリティアドバイザリおよび関連するCVEフィードを購読する。
   • クラスタコンポーネントに影響するCVEを評価し優先順位付けするプロセスを実装する。
3. 自動更新テスト:
   • 本番環境に適用する前に、ステージング環境でKubernetes更新の自動テストを実施する。
   • カナリアデプロイメントまたはブルーグリーン更新を使用して、潜在的な問題の影響を最小限に抑える。
4. バージョンスキュー管理:
   • 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

注意: ポッド自体の設定ミスにより上書きされる可能性があります。

ポッド仕様の securityContext フィールドを使用して、runAsUser と runAsGroup を 0 以外の値に設定してください。さらに、コンテナ内での特権昇格を防ぐため、allowPrivilegeEscalation: false を設定してください。

3. RBACによるユーザーと権限

ユーザーとサービスアカウントがタスク実行に必要な権限のみを持つよう、ロールベースアクセス制御（RBAC） ポリシーを実装し、ユーザーとサービスアカウントがタスク実行に必要な権限のみを保持するようにします。RBACポリシーを定期的に監査し、不要な権限を削除してください。rbac-lookup や `rakkess` などのツールを使用して、RBAC 構成を可視化および分析します。

4. ネットワークポリシーの使用

デフォルトでは、クラスター内の各ポッドは相互に通信できます。これは、攻撃者が 1 つのポッドにアクセスできれば、他のアプリケーションポッドにもアクセスできることを意味します。しかし実際には、すべてのポッドが相互に通信する必要はありません。したがって、Kubernetes ネットワークポリシーを実装してポッド間およびポッドと外部間の通信を制御することで、ポッド間の通信を制限できます。

「すべて拒否」をデフォルトのスタンスとして採用し、必要なトラフィックのみを明示的に許可します。高度なネットワークポリシーの適用と可視化には、CiliumやCalicoなどのツールを活用してください。

最大限の

5. 通信の暗号化

Kubernetes内のポッド間通信は暗号化されていないため、攻撃者はすべての通信を平文で読み取ることが可能です。APIサーバー通信、etcdピアおよびクライアントトラフィック、kubelet接続にはTLSを使用してください。IstioやLinkerdのようなサービスメッシュを導入し、ポッド間通信に相互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クラスター向けの包括的な災害復旧計画を策定し、定期的にテストします。これには、ノード障害、コントロールプレーンの停止、データ破損など、様々な障害シナリオからの復旧手順を含める必要があります。重要なワークロードに対しては、高可用性と回復力を確保するため、マルチリージョンまたはマルチクラスター戦略を実装します。

FAQs

Kubernetesのセキュリティ上の懸念事項は何ですか？

Kubernetesのセキュリティ上の懸念事項には、APIサーバーの露出、誤設定されたRBAC、スキャンされていないコンテナイメージ、不適切なネットワークポリシー、不適切なシークレット管理などが含まれます。

Kubernetesのセキュリティを維持するにはどうすればよいですか？

セキュリティは、RBACの適用、ネットワークポリシーの活用、イメージの脆弱性スキャン、通信の暗号化、シークレットやetcdデータの安全な管理などによって維持できます。

Kubernetesセキュリティの4つのCとは何ですか？

Kubernetesセキュリティの4つのCとは、クラウド（Cloud）、クラスター（Cluster）、コンテナ（Container）、コード（Code）です。Kubernetes環境全体のセキュリティを確保するには、各レイヤーを保護する必要があります。