National Security Agency（NSA）とCybersecurity and Infrastructure Security Agency（CISA）がKubernetes Hardening Guidanceなるものを公開していた模様。
目新しい情報はなさそうですが、抽象対策と実装対策がコンパクトに整理されていて読みやすいと思いました。
www.nsa.gov
今回のKubernetes Hardening Guidanceや国防総省のDevSecOpsから、米国がコンテナ技術を有望視していることがうかがえます。
クラウド、コンテナ、オーケストレータ、DevOps、マイクロサービス...
最近はインフラ、開発手法、アーキテクチャが絡み合ってわけわかめ状態ですが、本格的に普及するのであればセキュリティ側も本腰を入れなければなりません。
米国防省、KubernetesをF-16ジェット戦闘機に載せてみた － Publickey
Kubernetes Hardening Guidanceは下記で公開されています。
技術寄りだと5GやZero Trustなど、上流周りだとRussianやChineseといった地政学関連レポートも並んでいます。
情報技術分野の頂点に君臨する米国のサイバーセキュリティ戦略が反映されているので、レポートのタイトルを眺めるだけでも面白いと思います。
以降はKubernetes Hardening Guidanceの機械翻訳版です。
さらっと内容を流し読みしたい方はどうぞ。
- Executive summary
- Introduction
- Threat model
- Kubernetes Pod security
- Network separation and hardening
- Namespaces
- Authentication and authorization
- Log auditing
- Upgrading and application security practices
Executive summary
Kubernetes®は、コンテナで実行されるアプリケーションのデプロイ、スケーリング、管理を自動化するオープンソースシステムであり、多くの場合、クラウド環境でホストされます。このタイプの仮想化インフラストラクチャを使用すると、従来のモノリシックソフトウェアプラットフォームと比較して、いくつかの柔軟性とセキュリティ上の利点が得られます。ただし、マイクロサービスから基盤となるインフラストラクチャまですべてを安全に管理すると、他の複雑さが生じます。このレポートで詳しく説明されている強化ガイダンスは、組織が関連するリスクを処理し、このテクノロジーを使用するメリットを享受できるように設計されています。 Kubernetesでの3つの一般的な侵害の原因は、サプライチェーンのリスク、悪意のある脅威アクター、および内部脅威です。サプライチェーンのリスクは、軽減するのが難しいことが多く、コンテナの構築サイクルやインフラストラクチャの取得で発生する可能性があります。悪意のある脅威アクターは、コントロールプレーン、ワーカーノード、コンテナ化されたアプリケーションなど、Kubernetesアーキテクチャのコンポーネントの脆弱性と設定ミスを悪用する可能性があります。インサイダーの脅威は、管理者、ユーザー、またはクラウドサービスプロバイダーである可能性があります。組織のKubernetesインフラストラクチャに特別にアクセスできる内部関係者は、これらの特権を悪用できる可能性があります。このガイダンスでは、Kubernetesクラスターのセットアップとセキュリティ保護に関連するセキュリティの課題について説明します。これには、一般的な構成ミスを回避するための強化戦略が含まれており、システム管理者とNational Security Systemsの開発者に、推奨される強化策と緩和策の構成例を使用してKubernetesをデプロイする方法をガイドします。このガイダンスでは、次の緩和策について詳しく説明します。
コンテナとポッドをスキャンして、脆弱性や設定ミスがないか確認します。
•可能な限り最小限の特権でコンテナーとポッドを実行します。
•ネットワーク分離を使用して、侵害によって引き起こされる可能性のある損害の量を制御します。
•ファイアウォールを使用して不要なネットワーク接続と暗号化を制限し、機密性を保護します。
•強力な認証と承認を使用して、ユーザーと管理者のアクセスを制限し、攻撃対象領域を制限します。
•ログ監査を使用して、管理者がアクティビティを監視し、潜在的な悪意のあるアクティビティについて警告できるようにします。
•すべてのKubernetes設定を定期的に確認し、脆弱性スキャンを使用して、リスクが適切に考慮され、セキュリティパッチが適用されていることを確認します。
追加のセキュリティ強化ガイダンスについては、Center for Internet Security Kubernetesベンチマーク、DockerおよびKubernetesセキュリティ技術実装ガイド、Cybersecurity and Infrastructure Security Agency（CISA）分析レポート、およびKubernetesドキュメントを参照してください。
Introduction
Kubernetesは、しばしば「K8s」と略され、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するために使用されるオープンソースのコンテナオーケストレーションシステムです。アプリケーション内の各マイクロサービスからクラスター全体まで、クラスターを構成するすべての要素を管理します。コンテナ化されたアプリケーションをマイクロサービスとして使用すると、モノリシックソフトウェアプラットフォームと比較して柔軟性とセキュリティ上のメリットが得られますが、他の複雑さも生じる可能性があります。
このガイダンスは、セキュリティの課題に焦点を当て、国家安全保障システムと重要なインフラストラクチャの管理者に適用できる可能な場合の強化戦略を提案します。このガイダンスは、国家安全保障システムおよび重要なインフラストラクチャ組織に合わせて調整されていますが、連邦および州、地方、部族、および領土（SLTT）の政府ネットワークの管理者も、提供された推奨事項を実装することをお勧めします。 Kubernetesクラスターは保護が複雑になる可能性があり、構成の誤りを悪用する侵害で悪用されることがよくあります。次のガイダンスは、より安全なKubernetesクラスターの構築に役立つ特定のセキュリティ構成を提供します
Threat model
Kubernetesは、データや計算能力の盗難の貴重な標的になる可能性があります。従来、データの盗難が主な動機ですが、計算能力（多くの場合暗号通貨マイニング）を求めるサイバーアクターも、基盤となるインフラストラクチャを利用するためにKubernetesに引き付けられます。リソースの盗難に加えて、サイバー攻撃者はKubernetesを標的にしてサービス拒否を引き起こす可能性もあります。次の脅威は、Kubernetesクラスターの最も可能性の高い侵害の原因のいくつかを表しています。
Supply Chain Risk
サプライチェーンへの攻撃ベクトルは多様であり、軽減するのが困難です。サプライチェーンリスクとは、製品コンポーネント、サービス、または最終製品の供給を支援する人員など、システムを構成する要素を攻撃者が破壊する可能性があるリスクです。これには、Kubernetesクラスターの作成と管理に使用されるサードパーティソフトウェアとベンダーが含まれる場合があります。サプライチェーンの侵害は、次のような複数のレベルでKubernetesに影響を与える可能性があります。
Container/Application level
Kubernetesで実行されているアプリケーションのセキュリティとそのサードパーティの依存関係は、開発者の信頼性と開発インフラストラクチャの防御に依存しています。サードパーティからの悪意のあるコンテナまたはアプリケーションは、サイバーアクターにクラスター内の足がかりを提供する可能性があります。
Infrastructure
Kubernetesをホストする基盤となるシステムには、独自のソフトウェアとハードウェアの依存関係があります。ワーカーノードまたはコントロールプレーンの一部として使用されるシステムの侵害は、サイバーアクターにクラスター内の足がかりを提供する可能性があります。
Malicious Threat Actor
悪意のある攻撃者は、脆弱性を悪用して遠隔地からアクセスすることがよくあります。 Kubernetesアーキテクチャは、サイバーアクターがリモートエクスプロイトに利用できる可能性のあるいくつかのAPIを公開しています。
Control plane
Kubernetesコントロールプレーンには、クラスターを追跡および管理するために通信するさまざまなコンポーネントがあります。サイバー攻撃者は、適切なアクセス制御がない公開されたコントロールプレーンコンポーネントを頻繁に利用します。
Insider Threat
脅威アクターは、組織内での作業中に脆弱性を悪用したり、個人に与えられた特権を使用したりする可能性があります。組織内の個人には、Kubernetesクラスターに対して使用できる特別な知識と特権が与えられます。
Administrator
Kubernetes管理者は、コンテナ化された環境内で任意のコマンドを実行する機能など、実行中のコンテナを制御できます。 Kubernetesが適用するRBAC認証は、機密性の高い機能へのアクセスを制限することでリスクを軽減するのに役立ちます。ただし、Kubernetesには2人の整合性制御がないため、クラスターの制御を取得できる管理アカウントが少なくとも1つ必要です。管理者は多くの場合、システムまたはハイパーバイザーに物理的にアクセスできます。これらは、Kubernetes環境を危険にさらすためにも使用される可能性があります。
User
コンテナ化されたアプリケーションのユーザーは、Kubernetesクラスター内のコンテナ化されたサービスにアクセスするための知識と資格を持っている場合があります。このレベルのアクセスは、アプリケーション自体または他のクラスターコンポーネントのいずれかを悪用するための十分な手段を提供する可能性があります。
Cloud Service or Infrastructure Provider
Kubernetesノードを管理する物理システムまたはハイパーバイザーへのアクセスを使用して、Kubernetes環境を危険にさらす可能性があります。クラウドサービスプロバイダーは、多くの場合、特権管理者からシステムを保護するための技術的および管理的制御のレイヤーを持っています。
Kubernetes Pod security
“Non-root” containers and “rootless” container engines
デフォルトでは、多くのコンテナサービスは特権rootユーザーとして実行され、アプリケーションは特権実行を必要としないにもかかわらず、コンテナ内でrootとして実行されます。非ルートコンテナまたはルートレスコンテナエンジンを使用してルート実行を防止すると、コンテナの侵害による影響が制限されます。これらの方法はどちらもランタイム環境に大きな影響を与えるため、互換性を確認するためにアプリケーションを徹底的にテストする必要があります。
Non-root containers
コンテナーエンジンを使用すると、コンテナーは、非rootグループメンバーシップを持つ非rootユーザーとしてアプリケーションを実行できます。通常、このデフォルト以外の設定は、コンテナイメージの構築時に構成されます。付録A：ルート以外のアプリケーションのDockerfileの例は、アプリケーションをとして実行するDockerfileの例を示しています。
非rootユーザー。または、Kubernetesは、ゼロ以外のユーザーを指定するSecurityContext：runAsUserを使用してコンテナをポッドにロードできます。 runAsUserディレクティブは、展開時に非root実行を効果的に強制しますが、NSAおよびCISAは、開発者が非rootユーザーとして実行するコンテナーアプリケーションを構築することを推奨します。ビルド時にroot以外の実行を統合すると、root権限がなくてもアプリケーションが正しく機能することが保証されます。
Rootless container engines
一部のコンテナエンジンは、ルートとして実行されているデーモンを使用するのではなく、非特権コンテキストで実行できます。このシナリオでは、実行はコンテナ化されたアプリケーションの観点からはrootユーザーを使用しているように見えますが、実行はホスト上のエンジンのユーザーコンテキストに再マッピングされます。ルートレスコンテナエンジンは効果的なセキュリティレイヤーを追加しますが、多くは現在実験的なものとしてリリースされており、実稼働環境では使用しないでください。管理者は、ベンダーがKubernetesと互換性のある安定バージョンをリリースするときに、この新しいテクノロジーを認識し、ルートレスコンテナエンジンの採用を模索する必要があります。
Immutable container file systems
デフォルトでは、コンテナは独自のコンテキスト内でほとんど無制限に実行できます。コンテナ内で実行されたサイバーアクターは、ファイルの作成、スクリプトのダウンロード、およびコンテナ内のアプリケーションの変更を行うことができます。 Kubernetesはコンテナのファイルシステムをロックダウンできるため、悪用後の多くのアクティビティを防ぐことができます。ただし、これらの制限は正当なコンテナアプリケーションにも影響を及ぼし、クラッシュや異常な動作を引き起こす可能性があります。正当なアプリケーションの損傷を防ぐために、Kubernetes管理者は、アプリケーションが書き込みアクセスを必要とする特定のディレクトリにセカンダリ読み取り/書き込みファイルシステムをマウントできます。付録B：読み取り専用ファイルシステムのデプロイメントテンプレートの例は、書き込み可能なディレクトリを持つ不変のコンテナの例を示しています。
Building secure container images
コンテナイメージは通常、コンテナを最初から構築するか、リポジトリから取得した既存のイメージの上に構築することによって作成されます。信頼できるリポジトリを使用してコンテナを構築することに加えて、イメージスキャンは、デプロイされたコンテナの安全性を確保するための鍵となります。コンテナー構築ワークフロー全体で、イメージをスキャンして、古いライブラリ、既知の脆弱性、または安全でないポートやアクセス許可などの構成の誤りを特定する必要があります。
画像スキャンを実装するための1つのアプローチは、アドミッションコントローラを使用することです。アドミッションコントローラーはKubernetesネイティブの機能であり、オブジェクトを永続化する前に、リクエストが認証および承認された後に、KubernetesAPIへのリクエストをインターセプトして処理できます。カスタムまたは独自のWebhookを実装して、クラスターにデプロイする前に任意のイメージをスキャンできます。イメージがWebhook構成で定義された組織のセキュリティポリシーに準拠していない場合、このアドミッションコントローラーはデプロイメントをブロックする可能性があります[4]。
Pod Security Policies
ポッドセキュリティポリシー（PSP）は、クラスター内で実行するポッドのセキュリティ要件/デフォルトを指定するクラスター全体のポリシーです。多くの場合、セキュリティメカニズムはポッド/展開構成内で指定されますが、PSPは、すべてのポッドが準拠する必要のある最小セキュリティしきい値を確立します。一部のPSPフィールドは、ポッドの構成でフィールドが省略されている場合に使用されるデフォルト値を提供します。他のPSPフィールドは、不適合ポッドの作成を拒否するために使用されます。 PSPはKubernetesアドミッションコントローラーを介して適用されるため、PSPはポッドの作成中にのみ要件を適用できます。 PSPは、クラスターで既に実行されているポッドには影響しません。
PSPは、クラスター内のセキュリティ対策を実施するための便利な技術的制御です。 PSPは、階層化された役割を持つ管理者によって管理されるクラスターに特に効果的です。このような場合、トップレベルの管理者はデフォルトを課して、下位レベルの管理者に要件を適用できます。 NSAとCISAは、組織が付録C：ポッドセキュリティポリシーの例にあるKubernetesで強化されたPSPテンプレートをニーズに適合させることを推奨しています。次の表は、広く適用可能ないくつかのPSPコンポーネントについて説明しています。
Protecting Pod service account tokens
デフォルトでは、Kubernetesはポッドの作成時にサービスアカウントを自動的にプロビジョニングし、実行時にアカウントのシークレットトークンをポッド内にマウントします。 Kubernetesオーケストレーションはバックグラウンドで透過的に行われるため、多くのコンテナ化されたアプリケーションはサービスアカウントへの直接アクセスを必要としません。アプリケーションが侵害された場合、ポッド内のアカウントトークンはサイバーアクターによって収集され、クラスターをさらに侵害するために使用される可能性があります。アプリケーションがサービスアカウントに直接アクセスする必要がない場合、Kubernetes管理者は、ポッドの仕様でマウントされているシークレットトークンが無効になっていることを確認する必要があります。これは、ポッドのYAML仕様の「automountServiceAccountToken：false」ディレクティブを使用して実現できます。
Hardening container engines
一部のプラットフォームとコンテナエンジンは、コンテナ化された環境を強化するための追加オプションを提供します。強力な例は、ハイパーバイザーを使用してコンテナーを分離することです。ハイパーバイザーは、オペレーティングシステムではなく、ハードウェアに依存して仮想化の境界を適用します。ハイパーバイザーの分離は、従来のコンテナーの分離よりも安全です。 Windows®オペレーティングシステムで実行されているコンテナエンジンは、組み込みのWindowsハイパーバイザーであるHyper-V®を使用してセキュリティを強化するように構成できます。さらに、一部のセキュリティ重視のコンテナエンジンは、縦深防御のために軽量ハイパーバイザー内に各コンテナをネイティブにデプロイします。ハイパーバイザーに裏打ちされたコンテナーは、コンテナーのブレークアウトを軽減します。
Network separation and hardening
Kubernetesの中心的な概念です。コンテナ、ポッド、サービス、および外部サービス間の通信を考慮する必要があります。デフォルトでは、リソースを分離し、クラスターが危険にさらされた場合に横方向の移動やエスカレーションを防ぐためのネットワークポリシーはほとんどありません。リソースの分離と暗号化は、クラスター内でのサイバー攻撃者の移動とエスカレーションを制限する効果的な方法です。
・ネットワークポリシーとファイアウォールを使用して、リソースを分離および分離します。
・コントロールプレーンを固定します。
・保存中のトラフィックと機密データ（シークレットなど）を暗号化します。
Namespaces
Kubernetes名前空間は、同じクラスター内の複数の個人、チーム、またはアプリケーション間でクラスターリソースを分割する1つの方法です。デフォルトでは、ネームスペースは自動的に分離されません。ただし、名前空間はスコープにラベルを割り当てます。これを使用して、RBACおよびネットワークポリシーを介して承認ルールを指定できます。ネットワークの分離に加えて、ポリシーはストレージとコンピューティングリソースを制限して、名前空間レベルでポッドをより適切に制御できるようにします。
デフォルトでは3つの名前空間があり、それらを削除することはできません。
• kube-system (for Kubernetes components)
• kube-public (for public resources)
• default (for user resources)
ユーザーポッドは、クラスターサービス用に予約されているため、kube-systemまたはkube-publicに配置しないでください。付録D：名前空間の例に示されているYAMLファイルを使用して、新しい名前空間を作成できます。異なる名前空間のポッドとサービスは、ネットワークポリシーなどの追加の分離が強制されない限り、引き続き相互に通信できます。
Network policies
ネットワークポリシーは、ポッド、名前空間、および外部IPアドレス間のトラフィックフローを制御します。デフォルトでは、ポッドまたは名前空間にネットワークポリシーは適用されないため、ポッドネットワーク内で無制限の入力および出力トラフィックが発生します。ポッドは、ポッドまたはポッドの名前空間に適用されるネットワークポリシーによって分離されます。ネットワークポリシーでポッドが選択されると、該当するポリシーオブジェクトで特に許可されていない接続はすべて拒否されます。
ネットワークポリシーを作成するには、NetworkPolicyAPIをサポートするネットワークプラグインが必要です。ポッドは、podSelectorおよび/またはnamespaceSelectorオプションを使用して選択されます。ネットワークポリシーの例を付録E：ネットワークポリシーの例に示します。ネットワークポリシーのフォーマットは、クラスターに使用されるコンテナーネットワークインターフェイス（CNI）プラグインによって異なる場合があります。管理者は、すべてのポッドを選択するデフォルトのポリシーを使用して、すべての入力および出力トラフィックを拒否し、選択されていないポッドが分離されていることを確認する必要があります。その後、追加のポリシーにより、許可される接続に対するこれらの制限を緩和できます。
NetworkPolicyAPIをサポートするCNIプラグインを使用します
podSelectorおよび/またはnamespaceSelectorを使用してポッドを選択するポリシーを作成します
デフォルトのポリシーを使用して、すべての入力および出力トラフィックを拒否します。選択されていないポッドがkube-systemを除くすべての名前空間に分離されていることを確認します
LimitRangeおよびResourceQuotaポリシーを使用して、名前空間またはポッドレベルでリソースを制限します
Resource policies
ネットワークポリシーに加えて、LimitRangeとResourceQuotaは、名前空間またはノードのリソース使用を制限できる2つのポリシーです。 LimitRangeポリシーは、特定の名前空間内のポッドまたはコンテナーごとに個々のリソースを制限します。たとえば、最大のコンピューティングリソースとストレージリソースを適用します。付録F：LimitRangeの例のYAMLファイルの例に示されているように、名前空間ごとに作成できるLimitRange制約は1つだけです。 Kubernetes 1.10以降では、デフォルトでLimitRangeがサポートされています。各ポッドまたはコンテナに個別に適用されるLimitRangeポリシーとは異なり、
ResourceQuotasは、CPUとメモリの合計使用量に課せられる制限など、名前空間全体の総リソース使用量に課せられる制限です。ユーザーがLimitRangeまたはResourceQuotaポリシーに違反するポッドを作成しようとすると、ポッドの作成は失敗します。 ResourceQuotaポリシーの例は、付録G：ResourceQuotaの例に示されています。
Control plane hardening
コントロールプレーンはKubernetesのコアであり、ユーザーはコンテナーを表示したり、新しいポッドをスケジュールしたり、シークレットを読み取ったり、クラスター内でコマンドを実行したりできます。これらの機密性の高い機能のため、コントロールプレーンは高度に保護する必要があります。ネットワークの分離は、TLS暗号化、RBAC、強力な認証方法などの安全な構成に加えて、権限のないユーザーがコントロールプレーンにアクセスするのを防ぐのに役立ちます。 Kubernetes APIサーバーはポート6443と8080で実行されます。これらは、予想されるトラフィックのみを受け入れるようにファイアウォールで保護する必要があります。デフォルトでは、ポート8080は、ローカルマシンからTLS暗号化なしでアクセス可能であり、要求は認証および承認モジュールをバイパスします。安全でないポートは、APIサーバーフラグ--insecure-port = 0を使用して無効にできます。 Kubernetes APIサーバーは、インターネットや信頼できないネットワークに公開しないでください。ネットワークポリシーをkube-system名前空間に適用して、kube-systemへのインターネットアクセスを制限できます。デフォルトの拒否ポリシーがすべての名前空間に実装されている場合でも、kube-system名前空間は他のコントロールプレーンセグメントおよびワーカーノードと通信できる必要があります。
コントロールプレーンを保護する手順
1.TLS暗号化を設定します
2.強力な認証方法を設定します
3.インターネットおよび不要なネットワークまたは信頼できないネットワークへのアクセスを無効にします
4.RBACポリシーを使用してアクセスを制限します
5.認証およびRBACポリシーでetcdデータストアを保護します
6.kubeconfigファイルを不正な変更から保護します
Etcd
etcdバックエンドデータベースには、状態情報とクラスターシークレットが格納されます。これは重要なコントロールプレーンコンポーネントであり、etcdへの書き込みアクセスを取得すると、サイバーアクターにクラスター全体へのルートアクセスを与える可能性があります。 Etcdには、クラスターの認証方法とRBACポリシーがユーザーを制限できるAPIサーバーを介してのみアクセスする必要があります。 etcdデータストアは別のコントロールプレーンノードで実行できるため、ファイアウォールはAPIサーバーのみへのアクセスを制限できます。管理者は、etcdサーバーとAPIサーバー間のHTTPS通信を実施するためにTLS証明書を設定する必要があります。 etcdサーバーは、APIサーバーに割り当てられた証明書のみを信頼するように構成する必要があります。
Kubeconfig Files
kubeconfigファイルには、クラスター、ユーザー、名前空間、および認証メカニズムに関する機密情報が含まれています。 Kubectlは、ワーカーノードとコントロールプレーンのローカルマシンの$ HOME /.kubeディレクトリに保存されている構成ファイルを使用します。サイバーアクターは、この構成ディレクトリへのアクセスを悪用して、構成またはクレデンシャルにアクセスして変更し、クラスターをさらに侵害する可能性があります。構成ファイルは意図しない変更から保護する必要があり、認証されていない非rootユーザーはファイルへのアクセスをブロックする必要があります。
Worker node segmentation
ワーカーノードは、クラスターの実装に応じて、仮想マシンまたは物理マシンにすることができます。ノードはマイクロサービスを実行し、クラスターのWebアプリケーションをホストするため、多くの場合、ノードはエクスプロイトのターゲットになります。ノードが危険にさらされた場合、管理者は、ワーカーノードまたはKubernetesサービスと通信する必要のない他のネットワークセグメントからワーカーノードを分離することにより、攻撃対象領域を事前に制限する必要があります。ファイアウォールを使用して、ネットワークに応じて、内部ネットワークセグメントを外部に面したワーカーノードまたはKubernetesサービス全体から分離できます。ワーカーノードの攻撃対象領域から分離する必要がある可能性のあるサービスの例は、インターネットにアクセス可能である必要のない機密データベースまたは内部サービスです。
Encryption
管理者は、TLS 1.2または1.3暗号化を使用するように、コンポーネント、ノード、コントロールプレーン間を含むKubernetesクラスター内のすべてのトラフィックを構成する必要があります。暗号化は、インストール中またはインストール後に、Kubernetesドキュメントで詳しく説明されているTLSブートストラップを使用して設定し、証明書を作成してノードに配布できます。すべての方法で、安全に通信するために証明書をノード間で配布する必要があります。
Secrets
Kubernetesシークレットは、パスワード、OAuthトークン、SSHキーなどの機密情報を保持します。シークレットに機密情報を保存すると、YAMLファイル、コンテナーイメージ、または環境変数にパスワードやトークンを保存するよりも優れたアクセス制御が提供されます。デフォルトでは、Kubernetesはシークレットを暗号化されていないbase64でエンコードされた文字列として保存します。この文字列は、APIアクセス権を持つすべてのユーザーが取得できます。シークレットリソースにRBACポリシーを適用することにより、アクセスを制限できます。シークレットは、APIサーバーで保存データの暗号化を構成するか、クラウドプロバイダーを通じて利用できる外部のキー管理サービス（KMS）を使用して暗号化できます。 APIサーバーを使用してシークレットの保存データの暗号化を有効にするには、管理者はkube-apiserverマニフェストファイルを変更して、-encryption-provider-config引数を使用して実行する必要があります。暗号化プロバイダー構成ファイルの例を付録H：暗号化の例に示します。 KMSプロバイダーを使用すると、生の暗号化キーがローカルディスクに保存されなくなります。シークレットをKMSプロバイダーで暗号化するには、encryption-provider-configファイルで、付録I：KMS構成の例に示すようにKMSプロバイダーを指定する必要があります。
Protecting sensitive cloud infrastructure
Kubernetesは、多くの場合、クラウド環境の仮想マシンにデプロイされます。そのため、管理者は、Kubernetesワーカーノードが実行されている仮想マシンの攻撃対象領域を慎重に検討する必要があります。多くの場合、これらの仮想マシンで実行されているポッドは、ルーティング不可能なアドレスで機密性の高いクラウドメタデータサービスにアクセスできます。これらのメタデータサービスは、サイバーアクターにクラウドインフラストラクチャに関する情報を提供し、場合によってはクラウドリソースの短期間のクレデンシャルさえも提供します。サイバー攻撃者は、特権昇格のためにこれらのメタデータサービスを悪用します[5]。 Kubernetes管理者は、ネットワークポリシーを使用するか、クラウド構成ポリシーを使用して、ポッドがクラウドメタデータサービスにアクセスできないようにする必要があります。これらのサービスはクラウドプロバイダーによって異なるため、管理者はベンダーのガイダンスに従ってこれらのアクセスベクトルを強化する必要があります。
Authentication and authorization
認証と承認は、クラスターリソースへのアクセスを制限するための主要なメカニズムです。サイバーアクターは、よく知られているKubernetesポートをスキャンしてクラスターのデータベースにアクセスしたり、クラスターが正しく構成されていない場合に認証されずにAPI呼び出しを行ったりすることができます。ユーザー認証はKubernetesの組み込み機能ではありません。ただし、管理者がクラスターに認証を追加するには、いくつかの方法があります。
Authentication
Kubernetesクラスタには、サービスアカウントと通常のユーザーアカウントの2種類のユーザーがあります。サービスアカウントは、ポッドに代わってAPIリクエストを処理します。認証は通常、ベアラートークンを使用してServiceAccount AdmissionControllerを介してKubernetesによって自動的に管理されます。ベアラートークンは、よく知られた場所のポッドにマウントされ、トークンが保護されていない場合は、クラスターの外部から使用できます。このため、ポッドシークレットへのアクセスは、KubernetesRBACを使用して表示する必要があるユーザーに制限する必要があります。通常のユーザーと管理者アカウントの場合、ユーザーの自動認証方法はありません。管理者は、認証および承認メカニズムを実装するために、クラスターに認証方法を追加する必要があります。 Kubernetesは、クラスターに依存しないサービスがユーザー認証を管理することを前提としています。 Kubernetesのドキュメントには、クライアント証明書、ベアラートークン、認証プラグイン、その他の認証プロトコルなど、ユーザー認証を実装するいくつかの方法が記載されています。少なくとも1つのユーザー認証方法を実装する必要があります。複数の認証方法が実装されている場合、要求を正常に認証する最初のモジュールが評価を短絡させます。管理者は、静的パスワードファイルなどの弱い方法を使用しないでください。弱い認証方法では、サイバー攻撃者が正当なユーザーとして認証できる可能性があります。
匿名リクエストは、他の設定された認証方法によって拒否され、個々のユーザーまたはポッドに関連付けられていないリクエストです。匿名リクエストが有効になっているトークン認証用に設定されたサーバーでは、トークンが存在しないリクエストは匿名リクエストとして実行されます。 Kubernetes 1.6以降では、匿名リクエストはデフォルトで有効になっています。 RBACが有効になっている場合、匿名要求には、system：anonymousユーザーまたはsystem：unauthenticatedグループの明示的な承認が必要です。 --anonymous-auth = falseオプションをAPIサーバーに渡して、匿名リクエストを無効にする必要があります。匿名リクエストを有効のままにしておくと、サイバーアクターが認証なしでクラスターリソースにアクセスできるようになる可能性があります。
Role-based access control
RBACは、組織内の個人の役割に基づいてクラスターリソースへのアクセスを制御する1つの方法です。 Kubernetesバージョン1.6以降では、RBACはデフォルトで有効になっています。 kubectlを使用してクラスターでRBACが有効になっているかどうかを確認するには、kubectlapi-versionを実行します。有効になっている場合は、.rbac.authorization.k8s.io / v1のAPIバージョンを一覧表示する必要があります。 Cloud Kubernetesサービスでは、クラスターでRBACが有効になっているかどうかを確認する方法が異なる場合があります。 RBACが有効になっていない場合は、次のコマンドで--authorization-modeフラグを使用してAPIサーバーを起動します。kube-apiserver--authorization-mode= RBAC AlwaysAllowなどの承認モードフラグをそのままにしておくと、すべての承認要求が許可されます。すべての承認を効果的に無効にし、アクセスに最小限の特権を適用する機能を制限します。ロールとClusterRolesの2種類の権限を設定できます。ロールは特定の名前空間のアクセス許可を設定しますが、ClusterRolesは名前空間に関係なくすべてのクラスターリソースにアクセス許可を設定します。ロールとClusterRolesは、権限を追加するためにのみ使用できます。拒否ルールはありません。クラスターがRBACを使用するように構成されていて、匿名アクセスが無効になっている場合、KubernetesAPIサーバーは明示的に許可されていないアクセス許可を拒否します。 RBACの役割の例を付録J：ポッドリーダーのRBACの役割の例に示します。
RoleまたはClusterRoleは権限を定義しますが、権限をユーザーに結び付けません。 RoleBindingsおよびClusterRoleBindingsは、RoleまたはClusterRoleをユーザー、グループ、またはサービスアカウントに関連付けるために使用されます。 RoleBindingsは、定義された名前空間内のユーザー、グループ、またはサービスアカウントにRolesまたはClusterRolesのアクセス許可を付与します。 ClusterRolesは名前空間から独立して作成され、RoleBindingを使用して個人に付与して名前空間のスコープを制限できます。 ClusterRoleBindingsは、すべてのクラスターリソースにわたってユーザー、グループ、またはサービスアカウントにClusterRolesを付与します。 RBAC RoleBindingとClusterRoleBindingの例を付録K：RBACRoleBindingとClusterRoleBindingの例に示します。
RolesとClusterRolesを作成または更新するには、ユーザーは同じスコープで新しいロールに含まれる権限を持っているか、rbac.authorization.k8s.ioAPIグループのRolesまたはClusterRolesリソースでエスカレーション動詞を実行する明示的な権限を持っている必要があります。バインディングが作成された後、RoleまたはClusterRoleは不変です。ロールを変更するには、バインディングを削除する必要があります。ユーザー、グループ、およびサービスアカウントに割り当てられる特権は、最小特権の原則に従い、リソースに必要なアクセス許可のみを付与する必要があります。ユーザーまたはユーザーグループは、必要なリソースが存在する特定の名前空間に制限できます。デフォルトでは、ポッドがKubernetesAPIにアクセスするための名前空間ごとにサービスアカウントが作成されます。 RBACポリシーを使用して、各名前空間のサービスアカウントから許可されるアクションを指定できます。 Kubernetes APIへのアクセスは、適切なAPIリクエスト動詞とアクションを適用できる目的のリソースを使用してRBACロールまたはClusterRoleを作成することで制限されます。ユーザー、グループ、およびサービスアカウントを、関連付けられた割り当てられたロールとClusterRolesとともに印刷することにより、RBACポリシーの監査に役立つツールが存在します。
Log auditing
ログはクラスター内のアクティビティをキャプチャします。ログの監査は、サービスが意図したとおりに動作および構成されていることを確認するためだけでなく、システムのセキュリティを確保するためにも必要です。体系的な監査要件では、セキュリティ設定を一貫して徹底的にチェックして、侵害を特定することが義務付けられています。 Kubernetesは、クラスターアクションの監査ログをキャプチャし、基本的なCPUとメモリの使用状況情報を監視できます。ただし、詳細な監視またはアラートサービスをネイティブに提供するわけではありません。
キーポイント
異常なアクティビティの識別を可能にするために、作成時にポッドベースラインを確立します。
ホストレベル、アプリケーションレベル、および該当する場合はクラウドでロギングを実行します。
既存のネットワークセキュリティツールを統合して、スキャン、監視、アラート、および分析を集約します。
通信障害が発生した場合の損失を防ぐために、ローカルログストレージを設定します
Kubernetes内でアプリケーションを実行しているシステム管理者は、環境に合わせて効果的なロギング、モニタリング、アラートシステムを確立する必要があります。 Kubernetesイベントをログに記録するだけでは、システムで発生するアクションの全体像を把握するのに十分ではありません。ロギングは、ホストレベル、アプリケーションレベル、および該当する場合はクラウドでも実行する必要があります。これらのログは、必要に応じて外部認証およびシステムログと関連付けて、セキュリティ監査人およびインシデント対応者が使用するために環境全体で実行されたアクションの全体像を提供できます。 Kubernetes環境内で、管理者は以下を監視/ログに記録する必要があります。
API request history
• Performance metrics
• Deployments
• Resource consumption
• Operating system calls
• Protocols, permission changes
• Network traffic Pod scaling
ポッドが作成または更新されると、管理者はネットワーク通信、応答時間、要求、リソース消費、およびその他の関連するメトリックの詳細なログをキャプチャして、ベースラインを確立する必要があります。前のセクションで詳しく説明したように、匿名アカウントは無効にする必要がありますが、ログポリシーでは、異常なアクティビティを特定するために匿名アカウントが実行したアクションを記録する必要があります。 RBACポリシー構成は、定期的に、および組織のシステム管理者に変更が発生するたびに監査する必要があります。そうすることで、アクセス制御が、役割ベースのアクセス制御セクションで概説されているRBACポリシー強化ガイダンスに準拠して調整されることが保証されます。監査には、現在のログと通常のアクティビティのベースライン測定値との比較を含めて、ログに記録されたメトリックとイベントのいずれかの重要な変更を特定する必要があります。システム管理者は、アプリケーションの使用状況の変更やクリプトマイナーなどの悪意のあるプロセスのインストールなどの重要な変更を調査して、根本的な原因を特定する必要があります。内部および外部のトラフィックログの監査を実施して、接続で意図されているすべてのセキュリティ制約が適切に構成され、意図したとおりに機能していることを確認する必要があります。管理者は、システムの進化に合わせてこれらの監査を使用して、外部アクセスが不要になり、制限できる時期を特定することもできます。ログを外部のログサービスにストリーミングして、クラスター外のセキュリティプロフェッショナルが利用できるようにし、異常を可能な限りリアルタイムで特定し、侵害が発生した場合にログが削除されないように保護できます。この方法を使用する場合、サイバー攻撃者が転送中のログにアクセスして環境に関する貴重な情報を取得できないように、転送中にログをTLS1.2または1.3で暗号化する必要があります。外部ログサーバーを利用する際のもう1つの予防策は、外部ストレージへの追加専用アクセスを使用してKubernetes内のログフォワーダーを構成することです。これにより、外部に保存されたログがクラスター内から削除または上書きされるのを防ぐことができます。
Kubernetes native audit logging configuration
kube-apiserverはKubernetesコントロールプレーン上にあり、フロントエンドとして機能し、クラスターの内部および外部のリクエストを処理します。各要求は、ユーザー、アプリケーション、またはコントロールプレーンによって生成されたかどうかに関係なく、実行の各段階で監査イベントを生成します。監査イベントが登録されると、kube-apiserverは監査ポリシーファイルと該当するルールをチェックします。そのようなルールが存在する場合、サーバーは最初に一致したルールによって定義されたレベルでイベントをログに記録します。 Kubernetesの組み込みの監査機能はデフォルトで有効になっていないため、監査ポリシーが記述されていない場合、何もログに記録されません。クラスター管理者は、監査ポリシーYAMLファイルを作成してルールを確立し、各タイプの監査イベントをログに記録する目的の監査レベルを指定する必要があります。次に、この監査ポリシーファイルは、適切なフラグとともにkube-apiserverに渡されます。ルールが有効であると見なされるには、4つの監査レベル（None、Metadata、Request、またはRequestResponse）のいずれかを指定する必要があります。付録L：監査ポリシーは、RequestResponseレベルですべてのイベントをログに記録する監査ポリシーファイルの内容を示しています。付録M：監査ポリシーファイルをkube-apiserverに送信するためのフラグの例は、kube-apiserver構成ファイルの場所を示し、監査ポリシーファイルをkube-apiserverに渡すためのフラグの例を示します。付録Mには、ボリュームをマウントし、必要に応じてホストパスを構成する方法についての説明もあります。 kube-apiserverには、監査ログ用の構成可能なログとWebhookバックエンドが含まれています。ロギングバックエンドは、指定された監査イベントをログファイルに書き込み、Webhookバックエンドはファイルを外部HTTPAPIに送信するように構成できます。付録Mの例で設定されている--audit-log-pathフラグと--audit-log-maxageフラグは、監査イベントをファイルに書き込むログバックエンドを構成するために使用できるフラグの2つの例です。 log-pathフラグは、ロギングを有効にするために必要な最小構成であり、ロギングバックエンドに必要な唯一の構成です。これらのログファイルのデフォルトの形式はJSONですが、必要に応じて変更することもできます。ロギングバックエンドの追加の設定オプションは、Kubernetesのドキュメントに記載されています。
監査ログを組織のSIEMプラットフォームにプッシュするために、kube-apiserverに送信されたYAMLファイルを介してWebhookバックエンドを手動で構成できます。 Webhook構成ファイルの例と、ファイルをkubeapiserverに渡してWebhookバックエンドを接続するために必要なフラグは、付録N：Webhook構成にあります。 Webhookバックエンドのkube-apiserverで設定できる構成オプションの完全なリストは、Kubernetesのドキュメントにあります。
Worker node and container logging
Kubernetesアーキテクチャ内でロギング機能を設定する方法はたくさんあります。組み込みのログ管理方法では、各ノードのkubeletがログの管理を担当します。個々のファイルの長さ、保存期間、およびストレージ容量のポリシーに基づいて、ログファイルをローカルに保存およびローテーションします。これらのログはkubeletによって制御され、コマンドラインからアクセスできます。
NSAとCISAは、ノードに障害が発生した場合にログを保持するようにリモートログソリューションを構成することを推奨しています。
・すべてのノードでロギングエージェントを実行して、ログをバックエンドにプッシュします
・各ポッドでサイドカーコンテナを使用してログを出力ストリームにプッシュする
・各ポッドでログエージェントサイドカーを使用してログをバックエンドにプッシュする
・アプリケーション内からバックエンドにログを直接プッシュする
サイドカーコンテナは、他のコンテナと一緒にポッドで実行され、ログをログファイルまたはログバックエンドにストリーミングするように構成できます。サイドカーコンテナは、パッケージ化および展開される別の標準機能コンテナのトラフィックプロキシとして機能するように構成することもできます。
ワーカーノード間でこれらのロギングエージェントの継続性を確保するために、DaemonSetとして実行するのが一般的です。このメソッド用にDaemonSetを構成すると、すべてのノードに常にロギングエージェントのコピーが存在し、ロギングエージェントに加えられた変更がクラスター全体で一貫していることが保証されます。
Seccomp: audit mode
上記のノードとコンテナのログに加えて、システムコールをログに記録することは非常に有益です。 Kubernetesでコンテナシステムコールを監査する1つの方法は、セキュアコンピューティングモード（seccomp）ツールを使用することです。このツールはデフォルトで無効になっていますが、コンテナのシステムコール能力を制限するために使用できるため、カーネルの攻撃対象領域が低くなります。 Seccompは、監査プロファイルを使用して、行われている呼び出しをログに記録することもできます。カスタムseccompプロファイルを使用して、許可されるシステムコールと、指定されていないコールのデフォルトアクションを定義します。ポッド内でカスタムseccompプロファイルを有効にするには、Kubernetes管理者はseccompプロファイルのJSONファイルを/ var / lib / kubelet / seccomp /ディレクトリに書き込み、seccompProfileをポッドのsecurityContextに追加できます。カスタムseccompProfileには、次の2つのフィールドも含める必要があります。タイプ：LocalhostおよびlocalhostProfile：myseccomppolicy.json。すべてのシステムコールをログに記録すると、管理者は標準操作に必要なシステムコールを知ることができ、システム機能を失うことなくseccompプロファイルをさらに制限できます。
SYSLOG
Kubernetesは、デフォルトで、サービスが利用可能な場合、kubeletログとコンテナランタイムログをジャーナルに書き込みます。組織がデフォルトでsyslogユーティリティを使用しないシステムにsyslogユーティリティを利用する場合、またはクラスタ全体からログを収集してsyslogサーバーまたは他のログストレージおよび集約プラットフォームに転送する場合は、その機能を手動で構成できます。 Syslogプロトコルは、ログメッセージフォーマット標準を定義します。 Syslogメッセージには、タイムスタンプ、ホスト名、アプリケーション名、プロセスID（PID）で構成されるヘッダーと、プレーンテキストで記述されたメッセージが含まれます。 syslog-ng®やrsyslogなどのSyslogサービスは、システム全体から統一された形式でログを収集および集約することができます。多くのLinuxオペレーティングシステムは、デフォルトでrsyslogまたはjournaldを使用します。これはイベントログデーモンであり、ログストレージを最適化し、journalctlを介してsyslog形式でログを出力します。特定のLinuxディストリビューションを実行しているノード上のsyslogユーティリティは、デフォルトでオペレーティングシステムレベルでイベントをログに記録します。これらのLinuxディストリビューションを実行しているコンテナーは、デフォルトで、syslogを使用してログも収集します。 Syslogユーティリティによって収集されたログは、ログ集約プラットフォームがそれらを収集するように構成されていない限り、該当する各ノードまたはコンテナのローカルファイルシステムに保存されます。
Alerting
Kubernetesはアラートをネイティブにサポートしていません。ただし、アラート機能を備えたいくつかのモニタリングツールはKubernetesと互換性があります。 Kubernetes管理者がKubernetes環境内で機能するようにアラートツールを設定することを選択した場合、管理者がアラートを監視および設定する必要があるいくつかの指標があります。
アラートをトリガーする可能性のあるケースの例には、次のものが含まれますが、これらに限定されません。
•環境内のいずれかのマシンのディスク容量が少ない、
•ロギングボリュームの使用可能なストレージ容量が不足している、
•外部ロギングサービスがオフラインになる、
•ポッドまたはアプリケーションがroot権限で実行されている、
•リソースのアカウントによって要求が行われている
•使用されている、または特権を取得している匿名アカウント、
•ポッド作成要求のソースIDとしてリストされているポッドまたはワーカーノードのIPアドレス、
•異常なシステムコールまたは失敗したAPI呼び出し、
•ユーザー/管理者の動作これは異常です（つまり、異常な時間または異常な場所から）、および
•標準の運用メトリックベースラインからの大幅な逸脱。
ストレージが不足しているときにアラートを出すと、限られたリソースによるパフォーマンスの問題やログの損失を回避し、悪意のある暗号ジャックの試みを特定するのに役立ちます。特権ポッドの実行のケースを調査して、管理者がミスを犯したのか、本物のユースケースで特権の昇格が必要なのか、悪意のある攻撃者が特権ポッドを展開したのかを判断できます。疑わしいポッド作成元のIPアドレスは、悪意のあるサイバー攻撃者がコンテナから抜け出し、悪意のあるポッドを作成しようとしていることを示している可能性があります。
Kubernetesを組織の既存のSIEMプラットフォーム、特に機械学習/ビッグデータ機能を備えたプラットフォームと統合すると、監査ログの不規則性を特定し、誤ったアラートを削減するのに役立ちます。このようなツールをKubernetesで動作するように構成する場合は、これらのケースとユースケースに適用可能なその他のケースがアラートをトリガーするように構成されるように構成する必要があります。侵入の疑いが発生したときに自動的に動作できるシステムは、管理者がアラートに応答している間、侵害を軽減するための措置を講じるように構成できる可能性があります。ポッド作成リクエストのソースIDとしてポッドIPがリストされている場合、アプリケーションを利用可能に保ちながらクラスターの侵害を一時的に停止するために実装できる1つの緩和策は、ポッドを自動的に削除することです。そうすることで、ポッドのクリーンバージョンをノードの1つに再スケジュールできるようになります。次に、調査担当者はログを調べて、違反が発生したかどうかを判断し、発生した場合は、悪意のある攻撃者がどのように侵害を実行してパッチを展開できるかを判断できます。
Service meshes
サービスメッシュは、これらの通信のロジックを各マイクロサービス内ではなくサービスメッシュにコード化できるようにすることで、アプリケーション内のマイクロサービス通信を合理化するプラットフォームです。この通信ロジックを個々のマイクロサービスにコーディングすることは、拡張が難しく、障害が発生したときにデバッグするのが難しく、保護するのが困難です。サービスメッシュを使用すると、開発者にとってこれを簡素化できます。
•サービスがダウンしたときにトラフィックをリダイレクトします。
•通信を最適化するためのパフォーマンスメトリックを収集します。
•サービス間通信の暗号化の管理を許可します。
•サービス間通信のログを収集します。
•各サービスからログを収集します。
•ヘルプ開発者は、マイクロサービスまたは通信メカニズムの問題と障害を診断します。
サービスメッシュは、ハイブリッド環境またはマルチクラウド環境へのサービスの移行にも役立ちます。サービスメッシュは必須ではありませんが、Kubernetes環境に非常に適したオプションです。マネージドKubernetesサービスには、多くの場合、独自のサービスメッシュが含まれています。ただし、他のいくつかのプラットフォームも利用可能であり、必要に応じて高度にカスタマイズできます。これらの一部には、証明書を生成およびローテーションする認証局が含まれており、サービス間の安全なTLS認証を可能にします。管理者は、サービスメッシュを使用してKubernetesクラスタのセキュリティを強化することを検討する必要があります。
Fault tolerance
ロギングサービスの可用性を確保するために、フォールトトレランスポリシーを導入する必要があります。これらのポリシーは、特定のKubernetesのユースケースによって異なる場合があります。設定できるポリシーの1つは、ストレージ容量を超えた場合にどうしても必要な場合に、新しいログが最も古いログファイルを上書きできるようにすることです。
ログが外部サービスに送信されている場合、通信の損失または外部サービスの障害が発生した場合にログをローカルに保存するためのメカニズムを導入する必要があります。外部サービスへの通信が復元されたら、ローカルに保存されたログを外部サーバーにプッシュするためのポリシーを設定する必要があります。
Upgrading and application security practices
このドキュメントで概説されている強化ガイダンスに従うことは、Kubernetesオーケストレーションコンテナで実行されているアプリケーションのセキュリティを確保するためのステップです。ただし、セキュリティは継続的なプロセスであり、パッチ、更新、およびアップグレードについていくことが重要です。特定のソフトウェアコンポーネントは個々の構成によって異なりますが、システム全体の各部分は可能な限り安全に保つ必要があります。これには、Kubernetes、ハイパーバイザー、仮想化ソフトウェア、プラグイン、環境が実行されているオペレーティングシステム、サーバーで実行されているアプリケーション、およびKubernetes環境でホストされているその他のソフトウェアの更新が含まれます。 Center for Internet Security（CIS）は、ソフトウェアを保護するためのベンチマークを公開しています。管理者は、Kubernetesおよびその他の関連するシステムコンポーネントのCISベンチマークを順守する必要があります。管理者は定期的にチェックして、システムのセキュリティがベストプラクティスに関する現在のセキュリティ専門家のコンセンサスに準拠していることを確認する必要があります。さまざまなシステムコンポーネントに対して定期的な脆弱性スキャンと侵入テストを実行して、安全でない構成とゼロデイ脆弱性を事前に探す必要があります。潜在的なサイバー攻撃者が発見して悪用する前に、発見はすぐに修正する必要があります。更新が展開されると、管理者は、環境から不要になった古いコンポーネントを削除することにも対応する必要があります。マネージドKubernetesサービスを使用すると、Kubernetes、オペレーティングシステム、ネットワークプロトコルのアップグレードとパッチを自動化できます。ただし、管理者はコンテナ化されたアプリケーションにパッチを適用してアップグレードする必要があります。
