Kubernetesセキュリティとは?

Kubernetesセキュリティの重要性

Kubernetes は、パブリック クラウド環境とプライベート クラウド環境の両方でコンテナ化されたアプリケーションをオーケストレーションするための主要なプラットフォームとして、サイバー犯罪者の主要な標的となっています。Kubernetes は現代の DevOps ワークフローの中心であり、基盤となるインフラストラクチャやリソース管理の複雑さを気にすることなく、チームがアプリケーションのデプロイメントを自動化および拡張できるようにします。 

ただし、Kubernetes の複雑さにより、ビジネスクリティカルなアプリケーションを危険にさらす可能性のある脆弱性や誤った構成が導入されたり、見落とされたりすることも容易になります。Kubernetes が適切に保護されていない場合、攻撃者は重要なワークロードを侵害したり、機密データを盗み出したり、さらには重要なサービスを停止させたりする可能性があります。

したがって、組織には、プラットフォームとその基本コンポーネントを保護する Kubernetes セキュリティ プラクティスが必要です。

• クラスタ： すべての Kubernetes コンポーネントを含む包括的な環境。クラスターを管理するコントロール プレーンと、アプリケーションが実際に実行されるワーカー ノードのセットで構成されます。
• Nodes: コンテナ化されたワークロードを実行する仮想または物理のマシン。各ノードには、コントロール プレーンと通信する kubelet、ネットワーク ルールを処理する kube-proxy、およびコンテナ ランタイムが含まれます。
• ポッド: ノードは、ストレージ、ネットワーク名前空間、および構成を共有する 1 つ以上のコンテナーをカプセル化する、Kubernetes で展開可能な最小単位であるポッドにパッケージ化されたワークロードを実行します。
• コントロール プレーン コンポーネント: クラスターの状態と操作を管理します。主なコンポーネントには、API サーバーと、ポッドをノードに割り当てるスケジューラが含まれます。

k8s セキュリティとも呼ばれる Kubernetes セキュリティには、これらのコンポーネントを保護するために設計された幅広いセキュリティ対策が含まれます。これを実現するには、組織はプロアクティブな多層セキュリティ戦略を採用し、 Kubernetes脅威を継続的に監視し、攻撃を軽減し、規制基準への準拠を確保する必要があります。 Kubernetes はほとんどのクラウド インフラストラクチャの基盤になりつつあるため、ビジネスの継続性と成功にはそのセキュリティを確保することが不可欠です。

アプリケーションライフサイクルの各フェーズにおけるKubernetesセキュリティ

堅牢な k8s セキュリティを確保するには、アプリケーション ライフサイクルの各フェーズでセキュリティ上の懸念に対処することが重要です。セキュリティは単にデプロイメント後の考慮事項ではありません。開発プロセスの各段階に統合する必要があります。 

以下では、各フェーズで必須となるセキュリティ対策について詳しく説明します。

#1. 開発フェーズ

開発と設計フェーズは、Kubernetes セキュリティにおける最初の防御線です。この段階では、開発者は潜在的な攻撃に耐えられる安全なアプリケーションとアーキテクチャの作成に重点を置く必要があります。これには、開発環境の整合性を保護し、最初からセキュリティを考慮してアプリケーションを設計し、安全なコーディング手法を実装することが含まれます。 

検討すべき主なセキュリティ対策は次のとおりです。

• ゼロ トラスト アーキテクチャを採用して、すべてのアクセス要求を検証します。
• コード レビュー プロセスを開発し、アプリケーション コードに脆弱性がないことを確認します。
• 機密データ (パスワード、API キー、OAuth トークンなど) を適切に処理するために、安全な秘密管理プロセスを実施します。

#2. 配布フェーズ

配布フェーズでは、アプリケーションのサプライ チェーンを確認し、イメージやその他のコンポーネントが安全かつ最新であり、既知の脆弱性がないことを確認する必要があります。 

To achieve this, you should:

• すべてのコンテナ イメージの脆弱性をスキャンします。
• 不正なアクセスや操作を防ぐために、コンテナ イメージへのアクセスを制限します。
• すべての依存関係を更新し、パッチ管理プロセスを開発して、できるだけ早く新しい更新プログラムを入手します。

#3. デプロイメントフェーズ

デプロイメント フェーズでは、アプリケーションが Kubernetes クラスターに導入されます。このフェーズでセキュリティを確保するには、Kubernetes 環境を安全に構成し、デプロイメント プロセスを管理して脆弱性が露出するリスクを最小限に抑える必要があります。 

考慮すべき安全なデプロイメント プラクティスには次のものが含まれます。

• アプリケーションのデプロイメントを特定のユーザーおよび環境に制限します。
• コンテナ イメージをスキャンして暗号化 ID を検証し、署名が有効であること、信頼できる発行元からの署名であること、アーティファクトが変更されていないことを確認します。
• アプリケーションとクラスターを別々の名前空間にデプロイします。

#4. ランタイムフェーズ

Kubernetes ランタイムのセキュリティ アプリケーションがクラスター内で実行される運用フェーズに重点を置いています。ランタイムフェーズでは、セキュリティインシデントの影響を制限するための継続的な監視とインシデント対応機能、および環境を安全に保つための継続的な更新が必要です。 

大きく分けて3つの領域に分けられます。

• アクセス： 強力なアクセス制御、認証プロセス、およびすべての API トラフィックの暗号化により Kubernetes API を保護します。
• コンピューティング: 高いレベルのセキュリティを提供し、同じホスト上で実行しながらアプリケーションを分離するバランスを実現するコンテナ ランタイムを選択します。
• ストレージ： 保存中のクラスターと API オブジェクトを暗号化し、クラスターとストレージ間の接続を認証し、必要に応じて復元できるようにバックアップを活用します。

Kubernetes セキュリティの 4C

Kubernetes を脅威から効果的に保護するには、4C モデルの観点からセキュリティにアプローチします。4C モデルは、コード、コンテナ、クラスタ、クラウドセキュリティであり、Kubernetes アーキテクチャ内のセキュリティ上の懸念に対処するためのロードマップです。

コード セキュリティ

コードとは、コンテナによって実行されるアプリケーションを指します。Kubernetes 環境では、コードは重大な攻撃対象領域となります。これは、不注意によるバグの導入によって脆弱性が生じるだけでなく、潜在的に脆弱なサードパーティ ライブラリによっても発生します。

Kubernetes プラットフォームで実行されるコードを保護するには、まず、基本的なネットワーク セキュリティとアクセス制御を第一の防御線として、コードへの不正アクセスを防止することから始めます。安全なコーディング手法を実装し、専用のツールを使用して定期的にスキャンとテストを実行し、 OWASPコーディング ガイドラインに準拠します。

コンテナ セキュリティ

コンテナにはイメージが含まれており、イメージ自体は、アプリケーション コードの実行に必要なベース イメージ、オペレーティング システム、コンテナ構成、依存関係、およびランタイムで構成されます。

ポッドで実行されるコンテナは信頼できるベースイメージとランタイム環境を使用する必要がありますが、これらはいずれも悪意のある攻撃者の標的となる可能性があります。元のイメージ リポジトリが安全であることを確認し、コード ベースを最小限に抑えて使用中のサードパーティ ライブラリの数を制限し、コンテナー イメージの脆弱性をスキャンし、アクセス制御とネットワーク ポリシーを使用してポッドを保護し、ポッド間の通信を制限します。

クラスターセキュリティ

Kubernetes アーキテクチャはクラスターに編成されます。Kubernetes クラスターはポッドで構成され、各ポッドには同じローカル ネットワーク上で動作する 1 つ以上のコンテナーが含まれています。クラスター セキュリティの設計は、アクセス ポリシーとセキュリティ構成の慎重な設計に左右されます。

クラスター セキュリティには、クラスター内で実行されているコンテナーとアプリケーション、コントロール プレーン (API、スケジューラ、データストア、コントローラー)、およびクラスターが実行されるより広範なネットワークのセキュリティ保護が含まれます。

クラウドセキュリティ

クラウド レイヤーは、Kubernetes (通常はInfrastructure as Code (IaC) プラットフォームまたはマネージド Kubernetes サービス) を実行する物理データセンターまたはクラウド インフラストラクチャです。

クラウド プロバイダーは、適切なアクセス制御を実装するためのガイドラインとセキュリティのベスト プラクティスを提供します。リソースに対する最小権限手順を実装し、クラウドの脆弱性や構成ミスをスキャンし、Kubernetes と対話できるユーザーを制限するアクセス制御を実施することで、クラウド インフラストラクチャに対するリスクを軽減します。

一般に、管理者は、初期のコーディングとテスト、運用環境の構築、クラスター内の継続的な運用に至るまで、アプリケーションのライフサイクルのすべての段階にわたってセキュリティ対策を実装することを期待できます。

Kubernetes セキュリティの主要原則

次の原則とセキュリティ対策は、Kubernetes 上で実行されるコンテナ化されたアプリケーションの回復力を確保するのに役立ちます。

Role-Based Access Control (RBAC)

Kubernetes では、RBAC はクラスター内のリソースへのアクセスを制御し、ユーザーまたはグループが実行できるアクションと実行できないアクションを定義します。RBAC は、チーム アクセスの分離、操作の制限、管理者アクセスの制御、サービス アカウントの権限の管理に使用されます。

ロールは単一の名前空間内のリソースへのアクセスを許可するために使用されますが、クラスター ロールは範囲が広く、名前空間全体にわたるアクセスを定義します。明らかに、すべてのユーザーがすべてのリソースに完全かつ無制限にアクセスできる必要はありません。Kubernetes のロールと権限を評価する際には、一般的なガイドラインとして最小権限の原則 (PoLP) を参照してください。

RBAC を使用する場合、管理者はクラスター全体の権限ではなく、名前空間固有の権限を優先し、すべての Kubernetes オブジェクトと名前空間にアクセス制御を指定する必要があります。特定のタスクに必要な場合にのみアクセスを許可し、それ以上は許可しません。

ネットワークポリシーの適用

コンテナはネットワークを介して外部サービスやコンテナ同士と通信します。コンテナ化されたアプリケーションは、多くの場合、クラスター ネットワークを広範囲に使用します。アプリケーションが他のシステムとどのように対話するかをより深く理解し、異常な通信を特定するには、アクティブなネットワーク トラフィックの監視を実装し、それを Kubernetes ネットワーク ポリシーで許可されているトラフィックと比較します。

ネットワーク接続を保護するために、組織は、ワークロードが正しく機能するために必要な最小限の通信を優先し、必要なサービスへの通信を制限するネットワーク ポリシーを適用する必要があります。この推奨事項は、クラスターへの受信トラフィックと送信トラフィックの両方、およびクラスター内のトラフィックに適用されます。

仮想プライベート ネットワーク (VPN) と TLS を使用してネットワーク トラフィックを暗号化します。 コンテナのセキュリティを強化するには、環境内にファイアウォールを導入して別の保護層を追加し、ネットワークのセグメント化とリソースの分離を実装して攻撃対象領域を減らし、侵害を封じ込めます。

ポッドセキュリティアドミッション（PSA）の強制

PSA は Pod Security Policy (PSP) の後継であり、Kubernetes 内で Pod Security Standards (PSS) と呼ばれるセキュリティ ポリシーを適用します。PSA は組み込み機能であるため、サードパーティ ツールが不要になり、一連の標準を定義してそれに準拠することでセキュリティが簡素化されます。安全でない構成に制限を設け、攻撃対象領域を減らします。

Pod Security Admission によって適用される PSS は、ワークロードの 3 つのセキュリティ プロファイルを定義します。特権プロファイルには制限がないため、絶対に必要な場合を除いて使用しないでください。ベースラインプロファイルはアプリケーションに最低限のセキュリティを提供し、制限付きプロファイルはセキュリティのベスト プラクティスを適用します。

PSA は、ポッドがこれらのプロファイルに従って構成されていることを確認し、コンプライアンスを強化します。一般に、管理者はクラスターのセキュリティを確保するために、ポッドに対してベースライン ポリシーまたは制限ポリシーのいずれかを設定する必要があります。

コントロールプレーンのセキュリティ保護

Kubernetes コントロール プレーンはクラスターの制御を担当します。クラスターの状態、健全性、構成データを管理し、必要なすべてのリソースを使用してコンテナーが実行されるようにします。コントロール プレーンは、その重要性と複雑さから、構成がやや難しいと考えられており、その結果、攻撃者の主な標的となっています。

コントロール プレーンは次のコンポーネントで構成されます。

• etcd: etcd キー値データベースには、構成情報とクラスターの状態データが保存されます。etcd で暗号化が有効になっていること、絶対に必要な場合を除き通信が API サーバーに制限されていること、およびクライアントが証明書ベースの認証を使用していることを確認します。
• kube-controller-manager:コントローラー マネージャー デーモンはクラスターを実行し、その機能を制御します。コントローラー マネージャーのセキュリティ保護には、ネットワーク アクセスの制限、すべての API トラフィックに対する TLS の実装、クラスター上のリソース使用量の制限、コンテナーが使用する権限の最小化が含まれます。
• kube-scheduler:スケジューラは新しいコンテナを管理およびプロビジョニングします。セキュリティ手順には、攻撃対象領域を減らすためにプロファイリング機能を無効にし、スケジューラの IP アドレスが安全でない IP にバインドされていないことを確認することが含まれます。
• kube-apiserver: API サーバーはフロントエンドとして機能し、内部および外部のリクエストを処理します。簡単に言うと、外部 IPS によるアクセスを制限し、強力な認証メカニズムを実施し、TLS 暗号化を適用することで、 APIサーバーを保護します。 詳細については、以下の「Kubernetes API のセキュリティ保護」セクションを参照してください。

Kubernetes APIサーバーを保護する

外部ユーザーは API を介して Kubernetes コントロール プレーンにアクセスするため、セキュリティを確保し、権限のないユーザーからのアクセスを制限することが非常に重要です。

Kubernetes API を保護するには、まずサーバーを対象とするリクエストを規制して、許可されていない API リクエストがクラスターに正常にアクセスできないようにします。多要素認証(MFA) を有効にするサードパーティの認証プロバイダーの使用を検討してください。クラスター アクセスを保護するには、OAuth 2.0 コネクタまたは OpenID Connect (OIDC) プロバイダーを使用します。

パブリック ネットワークへのアクセスを制限し、API サーバーを介して転送されるデータに対してトランスポート層セキュリティ (TLS) 暗号化を実装します。また、API サーバーと直接通信する Kubernetes データストア (etcd) 自体が適切に保護されていることを確認します。

イメージのセキュリティスキャン

イメージは、作成されるクラスターとポッドの基礎となります。これらのイメージは、セキュリティ上の脆弱性がないか定期的にスキャンし、イメージから作成されたコンテナがイメージのセキュリティ上の欠陥を継承しないようにする必要があります。

イメージ スキャン ツールは、コンテナが構築されるベース イメージや、コンテナ イメージ内に含まれるライブラリのアプリケーションの脆弱性を識別するために使用できます。これは、ベースイメージとすべてのパッケージを脆弱性データベースに対してスキャンすることによって行われます。

改ざんを防ぐためにイメージ レジストリへのアクセスが制限されていることを確認し、継続的インテグレーション/継続的デプロイメント(CI/CD)パイプライン ステージ全体ですべてのイメージをスキャンします。CI/CD パイプラインにスキャンを追加すると、コンテナが適切に構成され、更新され、マルウェアがないことが保証されます。

秘密と通信を暗号化する

秘密は機密情報の一種です。Kubernetes では、最も一般的なシークレットは通常、パスワード、OAuth トークン、SSH キー、またはその他の資格情報です。YAML 構成ファイル、コンテナ イメージ、またはコンテナ上のドキュメント内にクリアテキストで保存されたシークレットは重大なリスクを表し、クラスター全体のセキュリティを危険にさらします。

Kubernetes は、このデータを安全に保存するための組み込みオブジェクトである Kubernetes Secret を提供します。Secret オブジェクトを使用すると、管理者は機密情報をアプリケーション コードから分離できます。

Kubernetes Secrets は特権情報を扱うため、ハッカーの標的となることがよくあります。シークレットは保存時に暗号化する必要があり、シークレットへのアクセスはそれを必要とするコンポーネントとユーザーのみに制限する必要があります。偶発的な秘密の漏洩を特定し、修復するための秘密スキャンの実践またはシステムを実装します。

ノードの露出を制限する

Kubernetes ノードには、マスター ノードとワーカー ノードの 2 つの主な種類があります。マスターノードは、API サーバー、スケジューラ、コントローラ、etcd データストアなどの基本的なクラスター サービスを実行します。ワーカーノードはクラスター内でアプリケーションを実行します。

Kubernetes クラスターは、Linux または Windows オペレーティング システム (OS) を実行するノードで構成されます。これらの OS の強化に一般的に適用される多くの強化手法は、Kubernetes ノードのコンテキストでも有効です。

• クラスターが正しく動作するために必要なアプリケーションとライブラリのみをインストールし、それ以上はインストールしないでください。
• 管理者/ルート アカウントへのアクセスを制限し、必要な場合にのみ使用します。
• 進行中のセキュリティ侵害を検出するためにリアルタイム監視ツールを導入します。
• Linux ノードは、SELinux や AppArmor などのツールを使用して強化できます。

さらに、Center for Internet Security (CIS) は、マスターノードとワーカーノードの両方に対して一連のセキュリティ ベンチマークを提供しています。Kube-bench などのツールを使用すると、管理者はクラスターをスキャンし、CIS ベンチマークに対して評価できます。これらのスキャンでは通常、CIS のベスト プラクティスから外れた構成を修正するための推奨事項が提供されます。

監査ログを有効にする

監査ログは、運用とセキュリティの両方を維持するために重要です。これらのログは、クラスターのアクティビティに関する実用的な分析情報を提供し、異常なアクティビティを迅速に検出することを可能にします。Kubernetes には監査ログ機能が組み込み機能として含まれていますが、デフォルトでは有効になっていません。アクティブ化すると、すべてのアクションがクラスター内に記録されます。

クラスター管理者は、ログに記録するイベントを定義する監査ポリシーと、それらのログを保存、管理、分析するための外部ツールを構成する必要があります。これにより、セキュリティ上の問題が迅速に検出され、発生した違反を調査するためにインシデント対応 (IR) チームに必要な情報が提供されます。

最小限の権限でワークロードを実行する

Kubernetes ワークロードは複雑で、適切に保護することが難しい場合があります。ワークロードは動的であり、オンプレミス環境とクラウド環境の間を移行し、それぞれ独自のネットワーク セキュリティ制御を備えています。さらに、自動化された CI/CD プロセスでは、クラスター ノードに新しいサービスや新しいバージョンが頻繁にデプロイされるため、複雑さが増します。

一般に、管理者はワークロードを信頼すべきではありません。きめ細かなセキュリティ ポリシーを適用して、ワークロードとサードパーティ アプリケーション間の通信を制限します。これにより、脅威の横方向の移動の可能性が低減され、コンプライアンスの維持に役立ちます。

ネットワーク セキュリティ定義はワークロードに組み込まれ、 Kubernetesディストリビューションおよびデータセンター間で移植可能であることを保証する必要があります。 こうすることで、ワークロードが実行される場所に関係なく、セキュリティ定義が引き継がれます。

最後に、境界セキュリティ ツールを構成して、ワークロードで使用される IP アドレスとポートを継続的に監視し、疑わしい動作をリアルタイムで識別できるようにします。