Kubernetes セキュリティの概要

コンテナと Kubernetes の導入が拡大しているにもかかわらず、そのセキュリティは依然として最大の懸念事項です。幸いなことに、コンテナの実装の安全性を向上するためにできることはたくさんあります。Kubernetes のセキュリティ保護に関するこの概要では、コンテナのセキュリティ保護を開始するにあたって実行できる多くの手順について要点を説明します。

クラウドネイティブ環境に脆弱性がもたらされる場合、その主要な原因になっていることが多いのがコンテナイメージです。効果的なセキュリティ戦略の中核は、組織全体で安全なイメージ構築を確実に実践することです。イメージスキャンは組織のセキュリティ体制の重要な要素ではありますが、イメージを保護すれば、アプリケーションのライフサイクルの早い段階で、コンテナ化されたアプリケーションのセキュリティをプロアクティブに確保できます。

コンテナイメージを安全に作成するために、次のベストプラクティスを取り入れましょう。

1. 最小限のベースイメージを使用する

   攻撃対象領域を減らすために、イメージに含まれるライブラリとツールは、コンテナにとって必要なもののみである必要があります。

2. 信頼できるソースからのベースイメージを使用する

   イメージをゼロから作成するのでなければ、信頼できるソースが作成するベースイメージを選択しましょう。すべてのイメージコンポーネントの Dockerfile とソースコードは、確認可能で、かつ信頼できるレジストリでホストされている必要があります。ベースイメージが頻繁に更新されていることも重要です。

3. ユーザーを指定する

   Dockerfile でユーザーが指定されていない場合、コンテナのデフォルトでは root ユーザーの権限で実行されます。これによって潜在的な攻撃対象領域が拡大し、アプリケーションが侵害された場合は特権昇格への簡単なパスが提供されます。

4. Docker イメージを検証する

   イメージの信頼性を確保することは困難ですが、安全なイメージを構築するための重要な要素です。ベースイメージはすべて署名および検証されている必要があります。信頼できるレジストリのみからイメージをプルすれば、常に認証済みのイメージを使用できます。

5. 脆弱性をスキャンする

   オープンソースライブラリによって導入されたものを含め、コンテナイメージ内に存在する脆弱性を見つけて修正することが重要です。

6. シークレットを入れない

   資格情報や鍵などの機密データを含むシークレットは、コンテナイメージ内に埋め込まないようにします。

7. リソース制限を設定する

   コンテナがアクセスできる CPU またはメモリーリソースの量を制限すると、不適切に使用された場合に発生する可能性のある損害を制限するのに役立ちます。

8. 特権を制限する

   コンテナの特権を可能な限り制限するように設定し、特権が昇格できないようにコンテナを構成します。

9. マルチステージビルドを使用する

   アプリケーションの生成とコンパイルに使用されるビルドツールは、プロダクションシステムで実行するときに悪用される可能性があります。ビルドフェーズと実行フェーズで同じイメージを使用するのではなく、マルチステージ Dockerfile を使用して、ランタイムイメージから不要なコンパイルツールを取り除きます。デバッガーも本番環境のイメージから削除する必要があります。

10. セキュリティに重点を置いたコーディング手法を使用する

    これらは、リンターを使用して開発プロセス中に安全でないコードをキャッチすることで実行できます。

この手順はイメージ構築プロセスに固有のものですが、安全なイメージの構築を支える原則は、アプリケーションの他の部分のセキュリティプラクティスにも適用する必要があります。これらのプラクティスには、Kubernetes やクラウドネイティブスタックの他の側面のデフォルト設定を使用するのではなく、攻撃対象領域を可能な限り小さく保つこと、特権を制限すること、構成を厳密に行うことが含まれます。

Center for Internet Security (CIS) は、サイバー防御のベストプラクティスを作成しており、クラウドソーシングを使用してセキュリティの推奨事項を定義しています。CIS ベンチマークは、CIS のツールの中で最もよく知られたものの 1 つです。

Kubernetes 向けの CIS ベンチマークを使用することで、組織の Kubernetes 環境を強化することができます。安全でない構成を特定するために、CIS ベンチマークで示されている設定と制御を自動的にチェックするツールとして、多くのオープンソースツールや商用ツールがあります。

CIS ベンチマークは多くの有用な構成チェック機能を提供します。しかし、組織はそれらを出発点と捉え、CIS のチェック機能以上に、ネットワークポリシーの実装、ロールベースのアクセス制御 (RBAC) 設定、管理特権、そして Kubernetes API サーバーに対するその他の保護機能といったベストプラクティスが Kubernetes に適用されるようにする必要があります。

Kubernetes ロールベースのアクセス制御 (RBAC) により、Kubernetes API エンドポイントの承認を標準的な方法で管理できます。クラスタの RBAC 構成は、どの名前空間内のどのリソースタイプで、どのサブジェクトがどのアクションを実行できるかを制御します。たとえば、構成によって、ユーザー名「alice」に、名前空間 external-api で「pod」タイプのリソースを表示するためのアクセス権を付与できます。RBAC API には、Role、ClusterRole、RoleBinding、ClusterRoleBinding の 4 つの宣言型オブジェクトが含まれています。

Role は個々の名前空間の権限を設定するルールで構成される名前空間リソースですが、 ClusterRole は、クラスタ全体の権限、または複数の名前空間にまたがる権限を付与する非名前空間リソースです。各ルールは、動詞、リソースタイプ、および名前空間セレクターの組み合わせです。

ロールバインディングは、ユーザー、ユーザーのグループ、またはサービスアカウント (サブジェクトとも言う) をロールに結び付け、それらのユーザーにそのロールで定義された権限を付与するブリッジです。クラスタ・ロールバインディングは、ClusterRole をクラスタ内のすべての名前空間に関連付けます。このように、RoleBinding は名前空間内で権限を割り当てますが、ClusterRoleBinding はそれらの権限をクラスタ全体に付与します。

Red Hat がお客様との実体験から発見した、RBAC 構成の設定で最もよくある 5 つのミスは次のとおりです。

構成ミス 1：クラスタ管理者のロールを不必要に付与

組み込みの cluster-admin ロールは、クラスタに無制限のアクセス権を付与します。従来の ABAC コントローラーから RBAC への移行中に、一部の管理者とユーザーが、関連するドキュメントの警告を無視して cluster-admin を広く付与することにより、ABAC の許容構成を複製することも考えられます。ユーザーまたはグループに cluster-admin が定期的に付与される場合、アカウントの侵害や誤りによる影響は危険なほど広範囲に及ぶ可能性があります。サービスアカウントも通常、この種のアクセスを必要としません。どちらの場合も、より適合した Role または ClusterRole を作成し、それを必要とする特定のユーザーにのみ付与する必要があります。

構成ミス 2：ロール集約の不適切な使用

Kubernetes 1.9 以降では、ロール集約を使用して新しい特権を既存のロールに結合できるようにすることで、特権の付与を単純化できます。しかし、これらの集約を注意深く確認しないと、ロールの使用目的が変わってしまうことがあります。たとえば、system:view ロールは、view 以外の動詞を使用してルールを不適切に集約し、system:view を付与されたサブジェクトはクラスタを変更できないという意図に違反する可能性があります。

構成ミス 3：ロールの付与の重複

ロールの定義は互いに重複している場合があり、サブジェクトに複数の方法で同じアクセス権を与えます。管理者が意図的にこのような重複を発生させている場合もありますが、このような構成では、どのサブジェクトにどのアクセス権が付与されているのかを理解することが難しくなる可能性があります。この状況では、複数のロールバインディングが同じ特権を付与していることに管理者が気付いていない場合、アクセス権の取り消しがより困難になる可能性があります。

構成ミス 4：使われていないロール

作成されたがどのサブジェクトにも付与されていないロールがあると、RBAC 管理の複雑さが増す場合があります。同様に、存在しないサブジェクト (削除された名前空間のサービスアカウントや組織を離れたユーザーなど) にのみ付与されるロールは、重要な構成の確認を困難にする可能性があります。使用されていないロールやアクティブでないロールの削除は通常安全であり、そうすることで、アクティブなロールに注意を向けられるようになります。

構成ミス 5：なくなったロールの付与

ロールバインディングによって、存在しないロールを参照できます。同じロール名が将来別の目的で再利用される場合、これらの非アクティブなロールバインディングは、新しいロール作成者が意図するもの以外のサブジェクトに、突然予期せず特権を付与する可能性があります。

クラスタの RBAC ロールとバインディングを適切に構成することで、アプリケーションの侵害、ユーザーアカウントの乗っ取り、アプリケーションのバグ、単純な人為的ミスなどの影響を最小限に抑えることができます。

仮想マシン (VM) とコンテナは 根本的に異なるアーキテクチャですが、混同されるほどの類似点があります。コンテナと VM の違いは、セキュリティに非常に重要な影響を及ぼします。VM もコンテナもさまざまな程度の分離が可能で、可搬性があります。仮想マシンは完全に自立していて、独自のオペレーティングシステムを備えており、他の仮想マシンとはリソースを共有しません。 コンテナは他のコンテナとホストを共有するため、安全な境界の概念が複雑になります。

コンテナと Kubernetes は異なるアーキテクチャの枠組みを提示するものであり、セキュリティへの異なるアプローチが必要になります。ホストをベースとするセキュリティ向けに確立された技術は、コンテナには適用できません。定義された境界の周囲にネットワーク・ファイアウォールを構築するなど、ホストまたは VM 領域の他のセキュリティ技術もコンテナには適用されません。さらに、仮想マシンのセキュリティのベストプラクティスで重要なのはセキュリティパッチの適用ですが、実行中のコンテナにパッチを適用することはできません。代わりに、コンテナイメージを更新してコンテナを再構築する必要があります。

コンテナの保護に必要なことは、次のとおりです。

• コンテナ間の接続を制御する
• コンテナに既知の脆弱性がないことを確認する
• コンテナが root アクセス権を持たないようにする
• 権限とアクセス権をアプリケーションが機能するために必要なものだけに制限する

Kubernetes によってさらに複雑さが増し、潜在的なセキュリティリスクが生じます。コンテナ化されたアプリケーションの強力なセキュリティ体制には、Kubernetes の構成とネットワークポリシーの管理が不可欠です。

さらに、コンテナ化されたアプリケーションへの移行に伴うワークフローの変更により、ライフサイクル全体を通じてセキュリティを統合することが重要になります。まずイメージとコンテナをどのように構成するかを決定し、セキュリティを最初からアプリケーションに組み込む必要があります。開発プロセスの最後やデプロイの直前に、コンテナ化されたアプリケーションにセキュリティ機能を追加することはできません。

コンテナ化されたアプリケーションのセキュリティには、オープンソースの要素を含むすべてのコンポーネントのソースの制御、構成の管理、イメージのスキャン、そして、きめ細かいロールベースのアクセス制御が必要です。コンテナと Kubernetes はセキュリティに対する異なるアプローチを強いるものではありますが、宣言的かつ不変の性質を備えているため、適切に構成されていれば、これまでに作成された中で最も安全なアプリケーションを構築することができます。

Kubernetes では、コンテナはいくつかの Kubernetes Object のうちの 1 つである Pod 内で実行され、各 Pod のランタイムの構成は、Pod 仕様のセキュリティコンテキスト、Pod セキュリティポリシー (PSP)、または Open Policy Agent (OPA) Gatekeeper などの管理コントローラーの組み合わせを使用して設定および適用できます。

セキュリティコンテキストはデプロイメント・マニフェストで定義されており、各ワークロードの正確な要件の定義を可能にします。これは Pod またはコンテナ用に構成することができます。Pod セキュリティポリシーはクラスタレベルの Kubernetes リソースで、Pod を実行できるセキュリティコンテキストを制御します。PSP がクラスタに対して有効になっている場合、関連付けられた PSP に準拠しない Pod を作成しようとすると、PSP 管理コントローラーによって拒否されます。

コンテナランタイムの特権を制限する方法：

• アプリケーションプロセスを root として実行しない。runAsUser を MustRunAsNonRoot に設定する
• 特権の昇格を許可しない。allowPrivilegeEscalation を false に設定する
• 読み取り専用の root ファイルシステムを使用する。readOnlyRootFilesystem を true に設定する
• デフォルトの (マスクされた) /proc ファイルシステムマウントを使用する
• ホストネットワークやプロセススペースを使用しない。hostPID、hostNetwork、および hostIPC を false に設定する
• 未使用の Linux 機能を削除し、アプリケーションにまったく必要のないオプション機能を追加しない
• SELinux オプションを使用して、よりきめ細かいプロセス制御を行う
• 各アプリケーションに独自の Kubernetes サービスアカウントを付与する
• Kubernetes API へのアクセスが不要な場合は、コンテナにサービスアカウントの資格情報をマウントしない

Kubernetes 名前空間の使用

Kubernetes 名前空間は、クラスタオブジェクトのスコーピングを提供し、きめ細かいクラスタオブジェクト管理を可能にします。名前空間内のコンテナまたは Pod、サービス、およびデプロイメントは、Kubernetes ネットワークポリシーなどの制御機能を使用して分離するか、Kubernetes ロールベースのアクセス制御 (RBAC) を使用してアクセスを制限することができます。

クラスタへのワークロードのデプロイを開始する前に、名前空間をどのように割り当てるかを計画しましょう。アプリケーションごとに 1 つの名前空間を持つようにするのは制御の方法としては最良ですが、RBAC のロール特権とデフォルトのネットワークポリシーを割り当てるときに追加の管理オーバーヘッドが発生します。複数のアプリケーションを 1 つの名前空間にグループ化する場合、主な判断基準は、それらのアプリケーションに共通の RBAC 要件があるかどうか、そして、その名前空間で Kubernetes API へのアクセスを必要とするサービスアカウントとユーザーにその権限を付与しても安全かどうかです。

大まかに言えば、構成管理は、構成に関するポリシーを確立し、それらのポリシーがアプリケーションのライフサイクルを通じて組織全体に一貫して適用されるようにするエンジニアリング手法です。構成は、クラウドネイティブ・アプリケーションのセキュリティリスクを管理する上で極めて重要です。その大きな理由は、コンテナと Kubernetes のデフォルト構成の多くは安全ではないことです。Kubernetes で稼働しているコンテナ化されたアプリケーションのセキュリティリスクの原因で、最も一般的なのが構成ミスです。

個々の開発者やオペレーターがワークロードを手動で構成する必要がないように、ガードレールを一元管理して構成管理を自動化する必要があります。これらのガードレールは組織のセキュリティポリシーに基づいている必要があります。

IBM によると、クラウドセキュリティの失敗の 95% はヒューマンエラーが原因です。アプリケーションがますます複雑になり、コンテナや Kubernetes の分散システムで実行されると、構成ミスのリスクが拡大します。一元化された構成管理ツールを持たない組織では、構成ポリシーが一貫して適用されるようにすることはほぼ不可能です。マルチクラウドまたはハイブリッドクラウドをセットアップしている企業の場合、環境ごとに異なる構成が必要になるため、構成を一貫して正しく行うことはさらに困難です。また、開発者やオペレーターが安全な構成のベストプラクティスを常に認識しているとは限らず、スキルギャップが存在し続けます。

多くの場合、開発者がアプリケーションを実行するための構成を設定する最も簡単な方法は、root アクセスの許可、管理者権限の付与、非常に高いリソース制限の設定など、安全性を最も低下させる方法でもあります。適切なツールを使用すれば、構成管理を DevOps ワークフローに統合できるため、開発速度が低下することはありません。これはベストプラクティスになります。なぜなら、迅速なリリースを実現しながらワークロードの構成のセキュリティ保護も可能になるからです。

構成管理には、構成を可視化する方法と、許可される構成にガードレールを設定する方法の両方を含める必要があります。これにより、安全でないビルドやリスクの高いデプロイは自動的に失敗します。組織は、コンテナおよび Kubernetes での関連するすべての構成の確認と、潜在的に危険な構成に関するアラートの受信を一括管理する必要があります。

コンテナと Kubernetes の構成管理の要は次のとおりです。

• ロールベースのアクセス制御 (RBAC)： 組織は、過度に寛容な構成や不要なロールを見つける必要があります。
• シークレット： 優れた構成管理ツールを使用すると、シークレットへのアクセスを事前に制限できます。
• ポリシーに基づく評価： 組織のセキュリティポリシーを設定することは、セキュリティ体制の整備に不可欠であり、事前に決定したポリシーに対してデプロイメントをチェックする方法が必要です。
• 特権：特権は、最小特権の原則に基づいて割り当てる必要があります。
• リソース制限：コンテナと Kubernetes クラスタの両方で、使用可能な CPU とメモリーに制限を設ける必要があります。
• ネットワークポリシー：ネットワークポリシーでは、コンテナが不正アクセスを受けた場合に生じ得る損害を制限するために、アプリケーションの各部分間の通信を可能な限り制限する必要があります。

構成管理を開始する最も簡単な方法は、業界で認められている CIS ベンチマークなどのベストプラクティスに従うことです。コンテナの導入が進むにつれて構成管理に関する組織のガバナンスポリシーを作成することが、ベストプラクティスになります。強力なセキュリティ体制を整備するには、コンテナと Kubernetes で構成を適切に管理する必要があるため、構成管理はそれら両方の構成に対応する必要があります。

Kubernetes のデフォルトでは、クラスタ内のすべての Pod が自由に通信することができます。これにより、アプリケーションの操作は容易になりますが、セキュリティ上のリスクも発生します。デフォルトは過度に寛容ですが、Kubernetes にはアセット間の通信を制限するように構成できる組み込みの強制機能もあります。ネットワーク・セグメンテーションによって、デプロイメントの各部分間の通信が制限されます。ネットワーク・セグメンテーションは、PCI-DSS などの一部のコンプライアンス・フレームワークでも求められています。

ネットワーク・セグメンテーションは、ネットワークをより小さなサブネットワークに分割することによって機能します。セキュリティの観点から見ると、主な利点は、悪意のある攻撃者が他のアプリケーションと同じ Kubernetes クラスタで実行されている 1 つのアプリケーションにアクセスした場合、ネットワーク・セグメンテーションによって、その悪意のある攻撃者は、クラスタ上のすべてのアプリケーションにはアクセスできないことです。また、機密性の高いワークロードや特定のコンプライアンス・フレームワークの対象となるワークロードをアプリケーションの他の部分から分離する方法でもあります。

ネットワークポリシーは可能な限り制限し、個々のコンテナが、アプリケーションが設計どおりに機能するために必要なコンテナのみと通信できるようにする必要があります。

Kubernetes では、ネットワーク・セグメンテーションは、Kubernetes ネイティブのネットワーク強制機能と、サービスメッシュなどの追加のインフラストラクチャの両方を使用して、ネットワークポリシーを適用することによって行われます。

デフォルトでは、同じ名前空間内または複数の名前空間の間で行われる Pod、コンテナ、ノード間の通信に制限はありません。通常、すべての通信を拒否するポリシーを設定してから、通信を制限するためのネットワークポリシーを設定するのが、優れたベストプラクティスの出発点です。Pod は相互に通信する必要があるため、特定の Pod が通信する必要がある他の Pod を体系的にリストアップすることをお勧めします。パブリックインターネットへの出入りも、それを必要とする Pod に対してのみ、許可リストに基づいて許可することが必要です。

ネットワークポリシーの変更とネットワーク・セグメンテーションの増加に関連する運用上のリスクもあります。ツールを使用して、システム全体のネットワークポリシーへの変更がアプリケーションにどのように影響するかを視覚化すると、ネットワークポリシーの調整によって予期しない結果が生じるリスクを最小限に抑えることができます。

完全に安全なアプリケーションや IT インフラストラクチャを持つ組織は、現在も今後もありません。セキュリティには、さまざまなアクションに関連するリスクおよびトレードオフの優先順位付けと理解が必要です。リスクプロファイリングは、組織の既知のセキュリティリスクと、そのリスクの管理に関連するポリシーとプラクティスの概要を示すプロセスです。どんな組織もある程度のリスクを受け入れる必要がありますが、どの程度のリスクを受け入れることができるかを明確にする必要があります。リスクプロファイリングは、組織全体だけでなく、個々のアプリケーションに対しても実行する必要があります。機密性の高いワークロードやコンプライアンス要件の対象となるワークロードのリスクプロファイルは、機密性の低いワークロードとは異なります。

リスクプロファイリングは、環境内に存在する脆弱性の重大性を評価するのにも役立ちます。すべての脆弱性に対応することは不可能なので、強力なセキュリティ体制では、修復の優先順位を正しく設定するために、すべての脆弱性のリスクを評価することが求められます。

分散型のコンテナ化されたアプリケーションでは、アプリケーションのリスクプロファイルを理解して優先順位を付けることが難しい場合があります。潜在的なアプリケーションには何百もの脆弱性が存在する可能性がありますが、すべての脆弱性に同じリスクがあるわけではありません。脆弱性によるセキュリティリスクは、次のような要因によって異なります。

• 脆弱性の重大度
• アプリケーションが公開されているかどうか
• アプリケーションが実稼働中かどうか
• アプリケーションがコンプライアンス規制の対象かどうか
• アプリケーションが機密データにアクセスするかどうか
• コンテナの特権レベル
• コンテナのネットワーク露出

組織は許容できるリスクのレベルを事前に定義する必要があり、多くの場合、各重大度レベルの脆弱性をどれだけ迅速に修正する必要があるかについて内部ポリシーを確立しますが、リスクプロファイリングは静的な作業ではありません。特にコンテナ化されたアプリケーションの場合、セキュリティリスクを評価するプロセスは、ランタイム中に継続的に実行する必要があります。

潜在的なセキュリティインシデント、脆弱性、ポリシーの優先順位付けを手動で行うのは、ミスや極度の疲労を招く原因になります。特に大規模環境では、セキュリティリスクの発見と優先順位付けに自動化されたツールを活用しないと、リスクプロファイリングを実行できないことがよくあります。Kubernetes でリスクプロファイリングを成功させるには、Kubernetes の宣言型のコンテキストデータを利用して、優先順位付けのプロセスを自動化する必要があります。これにより、セキュリティチームは、リスクプロファイリングのプロセスに時間を費やすのではなく、最もリスクの高いデプロイメントをまず最初に修正することに専念できます。

理想的には、リスクプロファイリングは事後対応型と事前対応型の両方のツールとして使用できます。1 つのデプロイメントでリスクの検出と修正が行われると、その情報を使用して、同様のリスク要因を持つ他のデプロイメントを検索し、潜在的なセキュリティリスクに事前に対処できます。

ランタイムセキュリティは、悪意のある攻撃者に対する重要な防衛線です。理想的には、パッチが適用されていない脆弱性、安全でない構成、または安全でない資格情報は、ビルドまたはデプロイの段階で検出されます。しかし実際には、脆弱性がこれらの初期段階をすり抜けることがあり、また、新たな脆弱性も継続的に発見されているため、ランタイムの検出と対応が不可欠です。また、コンプライアンス上の理由から、そして、内部の脅威に対する防衛線としても重要です。

宣言型の不変のワークロードには、実行時に潜在的なセキュリティインシデントを検出して対応するためのまったく新しいモデルが必要です。通常、コンテナは最小限の数のプロセスを実行するため、Kubernetes の宣言的な性質と相まって、ランタイムセキュリティのいくつかの側面が仮想マシン (VM) ベースのアプリケーションよりも容易になります。一方、実行中のコンテナには、VM ベースのアプリケーションにセキュリティパッチを適用するのと同じ方法で「パッチを適用」するべきではありません。そうではなく、不変として扱い、強制終了、更新、および再起動する必要があります。

検出は、ランタイムセキュリティの要です。これには、アプリケーションの動作に関するベースラインを見つけ、ベースラインから大きく外れたアクティビティを調査することが含まれます。追跡される可能性のあるアクティビティには、ネットワーク要求やプロセスの実行などがあります。これらのアクティビティが予想から逸脱している場合、それは潜在的に疑わしいまたは悪意のあるアクティビティの兆候である可能性があります。たとえば、許可されていないときにインターネットに接続しようとするような場合です。その種の異常な動作は、何らかの対処が必要であることを示している場合があります。

コンテナにはアプリケーションが 1 つしかないため、コンテナの異常検出の精度は VM ベースのワークロードよりも高まり、コンテナのベースラインの動作とそうでない動作の分離が容易になります。ただし、異常検出は常にインシデント対応プロセスと連動させる必要があります。

異常な動作の種類によっては、影響を受けた Pod またはコンテナをプラットフォームに強制終了させることで自動的に対応するのが最善の策となる場合があります。また、アラートを送信して手動で動作を評価する方が適切な場合もあります。しかし、潜在的なインシデントへの対応は、応答時間を最小限に抑え、コンテナ化されたアプリケーションの総合的なセキュリティを向上させるために、可能な限り自動化する必要があります。

kubelet は、各ノードで実行されている主要な「ノードエージェント」です。構成を誤ると多くのセキュリティリスクにさらされる可能性があります。実行中の kubelet 実行可能ファイルまたは kubelet 設定ファイルで引数を使用して、kubelet の設定を設定できます。

kubelet 構成ファイルを検索するには、次のコマンドを実行します。

ps -ef | grep kubelet | grep config

--config 引数を探します。これにより、kubelet 構成ファイルの場所がわかります。

次に、各ノードで次のコマンドを実行します。

ps -ef | grep kubelet

出力で、次のことを確認します。

--anonymous-auth 引数が false である：以前に参照した kubelet の記事では、悪用された構成ミスのうちの 1 つで、匿名の (そして認証されていない) 要求を kubelet サーバーが処理することが許可されていました。

--authorization-mode 引数が存在する場合は AlwaysAllow と表示される：存在しない場合は、--config で指定された kubelet 構成ファイルがあり、そのファイルで authorization: mode が AlwaysAllow 以外に設定されていることを確認してください。

--client-ca-file 引数が存在し、クライアント認証局ファイルの場所に設定されている：存在しない場合は、--config で指定された kubelet 構成ファイルがあり、そのファイルで authentication: x509: clientCAFile がクライアント認証局ファイルの場所に設定されていることを確認してください。

--read-only-port 引数が存在し、0 に設定されている：存在しない場合は、--config で指定された kubelet 構成ファイルがあること、readOnlyPort が存在する場合は 0 に設定されていることを確認してください。

--protect-kernel-defaults が true と表示される：存在しない場合は、--config で指定された kubelet 構成ファイルがあり、そのファイルで protectKernelDefaults が true に設定されていることを確認してください。

--hostname-override 引数が存在しない：これは、kubelet と API サーバー間の TLS 設定が壊れないようにするためです。

--event-qps 引数が存在し、0 に設定されている：存在しない場合は、--config で指定された kubelet 構成ファイルがあり、eventRecordQPS が 0 と表示されることを確認してください。

--tls-cert-file および --tls-private-key-file 引数が適切に設定されているか、--config で指定された kubelet 構成に tlsCertFile および tlsPrivateKeyFile の適切な設定が含まれている：この構成により、すべての接続が kubelet の TLS を介して行われるようになります。

kubelet が API サーバーから証明書を取得する場合、RotateKubeletServerCertificate および --rotate-certificates が true に設定されている：kubelet が強力な暗号のみを使用していることを確認してください。

Kubernetes API サーバーは、クラスタ内で実行されているユーザーまたはアプリケーションからの REST API 呼び出しを処理して、クラスタ管理を可能にします。Kubernetes コントロールプレーンへのゲートウェイと見なされているため、kubectl、クライアントライブラリを使用するか、API 要求を直接行うことで API サーバーにアクセスできます。Kubernetes API サーバーの承認を管理する 1 つの方法は、Kubernetes ロールベースのアクセス制御 (RBAC) を使用することです。管理コントローラーを使用して、API サーバーへの要求を検証することもできます。

API サーバーの保護は、そのアクセスを制御することから始まります。Center for Internet Security (CIS) は、API サーバーを強化および保護するための構成のベストプラクティスを提供します。

マスターノードで次のコマンドを実行します。

ps -ef | grep kube-apiserver

出力で、次のことを確認します。

--anonymous-auth 引数が false と表示される：この設定により、他の認証方法で拒否されない要求は匿名として扱われず、したがってポリシーに従って許可されます。

--basic-auth-file 引数が存在しない：基本認証では、優先されるトークンや証明書の代わりにプレーンテキストの資格情報を使用して認証を行います。

--insecure-allow-any-token 引数が存在しない：この設定により、認証された安全なトークンのみが許可されるようになります。

–kubelet-https 引数が存在しないか true と表示される：この構成により、API サーバーと kubelet 間の接続がトランスポート層セキュリティ (TLS) を介して転送中に保護されます。

--insecure-bind-address 引数が存在しない：この構成により、API サーバーが安全でないアドレスにバインドされるのを防ぎ、マスターノードへの認証および暗号化されていないアクセスを防止します。これにより、攻撃者が転送中に機密データを読み取るリスクを最小限に抑えます。

--insecure-port 引数が 0 と表示される：この設定により、API サーバーが安全でないポートで機能するのを防ぎ、マスターノードへの認証および暗号化されていないアクセスを防止します。これにより、攻撃者がクラスタを制御するリスクを最小限に抑えます。

--secure-port 引数が存在しないか、1 から 65535 までの整数で表示される：ここでの目的は、すべてのトラフィックが認証と承認を得て https 経由で確実に提供されるようにすることです。

--profiling 引数が false と表示される：ボトルネックが生じている場合や何らかのトラブルシューティングが必要な場合を除いて、プロファイラーは必要ありません。プロファイラーを使用すると、システムやプログラムの詳細が不必要に公開される可能性があります。

--repair-malformed-updates 引数が false と表示される：この設定により、クライアントからの意図的に不正な形式の要求が API サーバーによって拒否されるようになります。

--enable-admission-plugins 引数が AlwaysAdmit を含まない値で設定されている：この設定を常に許可するように構成すると、管理コントロールプラグインによって明示的に許可されていない要求でも許可されるようになり、プラグインの有効性が低下します。

--enable-admission-plugins 引数が AlwaysPullImages を含む値で設定されている：この構成により、ユーザーは、イメージの名前を知っているだけでノードから Pod にイメージをプルすることはできなくなります。この制御を有効にすると、コンテナを起動する前に常にイメージがプルされるようになります。これには有効な資格情報が必要です。

--enable-admission-plugins 引数が SecurityContextDeny を含む値で設定されている：この制御により、Pod セキュリティポリシーに示されていない方法で Pod レベルのセキュリティコンテキストをカスタマイズすることはできなくなります。

--disable-admission-plugins 引数が NamespaceLifecycle を含まない値で設定されている：この制御は無効にしないでください。これにより、存在しない名前空間または終了するように設定された名前空間にはオブジェクトが作成されなくなります。

--audit-log-path 引数が監査ログを格納する適切なパスに設定されている：Kubernetes API サーバーを含めて Kubernetes コンポーネントが利用可能な場合、そのコンポーネントの監査を有効にするのは常に優れたセキュリティプラクティスです。

--audit-log-maxage 引数が 30 または内部および外部のデータ保持ポリシーに準拠するために監査ログファイルを保存する必要がある任意の日数に設定されている。

--audit-log-maxbackup 引数が 10 または一定数の古いログファイルの保持を規定するコンプライアンス要件を満たすための任意の数に設定されている。

--audit-log-maxsize 引数が 100 またはコンプライアンス要件を満たす任意の数に設定されている：100 という数字は 100MB を表します。

--authorization-mode 引数が存在し、AlwaysAllow に設定されていない：この設定により、特に本番クラスタでは、承認された要求のみが API サーバーによって許可されるようになります。

--token-auth-file 引数が存在しない：この引数が存在する場合、静的トークンベースの認証を使用しますが、これにはセキュリティ上の欠陥があります。代わりに、証明書などの別の認証方法を使用してください。

--kubelet-certificate-authority 引数が存在する：この設定は、API サーバーと kubelet が接続している場合に、中間者攻撃を防ぐのに役立ちます。

--kubelet-client-certificate および --kubelet-client-key 引数が存在する：この構成により、API サーバーは kubelet の HTTPS エンドポイントに対して自身を認証するようになります。(デフォルトでは、API サーバーはこの手順を実行しません。)

--service-account-lookup 引数が存在し、true に設定されている：この設定は、API サーバーが、要求に含まれるサービスアカウントトークンが etcd に存在することを確認せずに認証トークンの有効性のみを検証するインスタンスを防ぐのに役立ちます。

--enable-admission-plugins 引数が PodSecurityPolicy を含む値に設定されている。

--service-account-key-file 引数が存在し、サービスアカウントトークンに署名するための個別の公開鍵と秘密鍵のペアに設定されている：公開鍵と秘密鍵のペアを指定しない場合、TLS サービング証明書の秘密鍵が使用されるため、サービスアカウントトークンの鍵をローテーションすることができなくなります。

--etcd-certfile および --etcd-keyfile 引数が存在し、API サーバーがクライアントの証明書と鍵を使用して etcd サーバーに対して自身を識別する：etcd は本質的に機密性の高いオブジェクトを格納するため、クライアント接続では TLS 暗号化を使用する必要があります。

--disable-admission-plugins 引数が設定され、ServiceAccount が含まれていない：この構成により、新しい Pod が作成されたときに、同じ名前空間内のデフォルトのサービスアカウントが使用されないようになります。

--tls-cert-file および --tls-private-key-file 引数が存在し、API サーバーが TLS 経由で HTTPS トラフィックのみを処理するように設定されている。

--client-ca-file 引数が存在し、TLS およびクライアント証明書認証が Kube クラスタのデプロイメントに構成されている。

--etcd-cafile 引数が存在し、API サーバーが SSL 認証局ファイルを介して etcd サーバーに対して自身を検証する必要があるように設定されている。

--tls-cipher-suites 引数が強力な暗号を使用するように設定されている。

--authorization-mode argument 引数が存在し、Node を含む値で設定されている：この構成は、kubelet がノードに関連付けて読み取ることができるオブジェクトを制限します。

--enable-admission-plugins 引数が設定され、NodeRestriction の値が含まれている：このプラグインは、kubelet が自身の Node API オブジェクトとそのノードに関連付けられた Pod API オブジェクトのみを変更できるようにします。

--encryption-provider-config 引数が EncryptionConfig ファイルに設定されており、このファイルに必要なすべてのリソースが含まれている：この設定により、etcd Key-Value ストアに格納されているすべての REST API オブジェクトが保存時に暗号化されるようになります。

aescbc 暗号化プロバイダーが必要なすべてのリソースに使用されている：この暗号化プロバイダーは最も強力であると見なされています。

--enable-admission-plugins 引数に EventRateLimit の値が含まれている：クラスタのパフォーマンスを最適化するために API サーバーが受け入れるイベントの数に制限を設定します。

--feature-gates 引数が AdvancedAuditing=false を含む値で設定されていない：つまり、監査目的や調査目的で高度な監査が無効にされないようにします。

--request-timeout 引数が設定されていないか、適切な (長すぎず、短すぎない) 値に設定されている：デフォルト値は 60 秒です。

--authorization-mode 引数が存在し、Kubernetes RBAC を含む値に設定されている：

この設定により、RBAC が有効になります。単に有効にするだけでなく、RBAC を最適に使用するためには、次のような推奨事項にも従う必要があります。

• ユーザーに cluster-admin ロールを付与することは避けてください。これは、環境全体で非常に幅広い権限を与えることになるため、使用する場合は非常に慎重に使用する必要があります。
• ロール集約ルールを監査して、適切に使用するようにしてください。
• アクセスの取り消しが難しくなる可能性があるため、サブジェクトに重複した権限を付与しないでください。
• 使用されていないロールは定期的に削除してください。

コンテナと Kubernetes の最大のリスクの 1 つは、どちらのテクノロジーのデフォルト構成も安全ではないということです。セキュリティインシデントのリスクを軽減するには、組織全体で一貫してこれらのデフォルト構成をプロアクティブに変更する必要があります。見落とし、知識の欠如、またはワークフローに構成管理の手順を組み込まないことによってこのステップを怠ると、ワークロードが不必要に脆弱になります。

コンテナのデフォルト設定

多くのデフォルトのコンテナ設定、およびコンテナを構築する際によく使われる手法は、コンテナを脆弱な状態にする可能性があります。コンテナを構成する際に注意すべき点がいくつかあります。

• ユーザーを指定する： ユーザーが指定されていない場合、デフォルトで root ユーザーが使用されるため、コンテナにホストへの root アクセスが許可される可能性があります。
• イメージを検証する： デフォルト設定ではイメージ検証が実行されないため、危殆化したイメージが知らないうちにプルされる可能性があります。
• リソース制限を設定する： リソース制限を設定することは可能ですが、デフォルトでは制限されていません。コンテナが消費できる CPU とメモリーを制限すると、コンテナが危険にさらされた場合に大量のリソースが消費されるのを防ぐのに役立ちます。
• ツールとライブラリを選択的にインストールする： コンテナ内のツールとライブラリが少なければ少ないほど、悪意のある攻撃者がコンテナにアクセスした場合に悪用できるツールも少なくなります。標準のツールセットをすべてのコンテナにインストールするのではなく、実際に必要なものだけをインストールするようにしてください。
• リスティングを許可してレジストリへのアクセスを制御する： 使用するイメージが信頼できるソースからのものであることを確認するのに加えて、レジストリへのアクセスを厳密に制御する必要があります。理想的には、信頼できるユーザーのみのリスティングを許可する必要があります。

Kubernetes のデフォルト設定

Kubernetes は、組織のセキュリティ体制を向上するための多くのツールも提供しますが、セキュリティ上のメリットを得るためには Kubernetes を積極的に構成する必要があります。Kubernetes で確認するべき重要事項は次のとおりです。

• ロールベースのアクセス制御 (RBAC) を構成する： RBAC は Kubernetes 1.6 以降ではデフォルトで有効になっていますが、メリットを得るためには正しく構成する必要があります。理想的には、アクセスはクラスタではなく名前空間によって提供される必要があります。
• 名前空間を使用する： 「デフォルト」では、あらゆることが同じ名前空間で実行されます。名前空間による分離を積極的に使用して、ワークロードを相互に分離しましょう。
• Kubernetes ネットワークポリシーを使用する： すぐに使用できるように構成されたネットワークポリシーはないため、ネットワークプラグインをインストールしてアプリケーションからの入力および出力トラフィックを制御し、それに応じてポリシーを構成する必要があります。
• 監査ログを有効にする： 監査ログは通常、デフォルトでは有効になっていませんが、異常な API 呼び出しと承認の失敗を可視化するために有効にする必要があります。

通常、コンテナと Kubernetes を最初に使用するのはセキュリティに関する深い専門知識を持たない開発チームです。しかし、セキュリティを無視すると、使用するインフラストラクチャの種類に関係なく、組織はリスクにさらされます。

すでに述べたことを繰り返しますが、コンテナも Kubernetes も、デフォルトの構成は安全なものではありません。Kubernetes ネイティブのセキュリティ機能からセキュリティ上のメリットを得るためには、積極的に構成する必要があります。最も迅速かつ簡単にアプリケーションを稼働させる方法は、多くの場合、アプリケーションに多すぎるくらいの特権を付与するか、必要以上にはるかに高いリソース制限を設定するか、あるいはデフォルトのままにしておくことです。組織は、とりわけコンテナと Kubernetes に習熟しようとしているときには、最初はセキュリティに十分な注意を払わない場合がありますが、そうすると大きなリスクにさらされます。悪意のある攻撃者は、レガシーアプリケーションを悪用するのと同じくらい簡単に、Kubernetes 上のコンテナ化されたアプリケーションを悪用することができます。

何もしないことで生じる主なリスクは、悪意のある攻撃者によってアプリケーションが危険にさらされることです。それがどれほど壊滅的なものになるかは、組織の業界、使用中のアプリケーションの種類、侵害の範囲と種類によって異なります。また、セキュリティの軽視によってインシデントが生じる可能性は、アプリケーションがインターネットに接続されているかどうかなどの要因によっても異なります。

コンテナ化されたアプリケーションの安全性を確保するための対策を取らなければ、アプリケーションは不必要に脆弱になります。セキュリティを無視すると、次のような問題が生じます。

パッチ未適用のセキュリティ脆弱性： 新しいセキュリティの脆弱性は常に発見されており、中には深刻なものもあります。これらの脆弱性は、公開されるとすぐに、オープンソースコミュニティのみならず、悪意のある攻撃者の知るところとなります。これらの脆弱性に迅速に対処しないとリスクが生じます。

緩い権限： Kubernetes ではロールベースのアクセス制御 (RBAC) がデフォルトで有効になっていますが、アクセス制御を導入するのは開発者の仕事です。セキュリティガイダンスがないと、開発者はアクセス権が過度に多いワークロードを作成することがよくあります。

分離されていないワークロード： デフォルトでは、単一のデフォルト名前空間であらゆることを実行できます。名前空間を使用してワークロードの分離を開始するのは、基本的なセキュリティのベストプラクティスです。セキュリティのこのステップに意識的に注意を払わなければ、このレベルの分離はできません。

制御できないネットワークポリシー： Kubernetes ネットワークポリシーはトラフィックを制御するのに役立ちますが、ネットワークプラグインが必要で、ポリシーは構成する必要があります。

セキュリティ制御の適用を待つ間にセキュリティプラクティスにまとまりがなくなり、これがセキュリティレビューのボトルネックとなって、開発速度が低下し、セキュリティインシデントのリスクが高まります。代わりに、組織がソフトウェア開発ライフサイクルの早い段階で頻繁にセキュリティ制御を適用できるように支援しましょう。

事実上のコンテナ・オーケストレーション・システムとして、Kubernetes はコンテナ管理を可能にしますが、インフラストラクチャ環境に潜在的なセキュリティの脆弱性ももたらします。コンテナおよび Kubernetes と仮想マシンのセキュリティの違い、そして Kubernetes のセキュリティに関する継続的なスキルギャップは、不要なセキュリティリスクにつながる可能性があります。

Kubernetes のセキュリティのベストプラクティスには、他のあらゆるセキュリティのベストプラクティスと同様に、アプリケーションとインフラストラクチャの安全性を向上するためのベストプラクティスと、セキュリティを一元管理するための組織的および文化的なプラクティスの両方が含まれます。

組織のセキュリティポリシーを作成して適用するのは、利用する技術スタックを問わず、ベストプラクティスです。セキュリティはリスク管理のプロセスであり、たとえば、ツールを使用して、各アプリケーションでどの程度のリスクを許容できるかを決定することはできません。この種の決定は、組織全体、個々のビジネスユニット、各アプリケーションで許容可能なリスクの程度を考慮することができる人間が行う必要があります。

セキュリティの一元管理： 最初の点に関連して、組織には、設定したセキュリティおよびガバナンスポリシーが遵守されていることを確認する手段が必要です。中央のチームは分散アプリケーション全体の構成と脆弱性を可視化する必要があり、潜在的な問題を容易に視覚化して優先順位を付ける方法を必要とします。さらに、リスクのある構成、安全でないイメージ、または他の潜在的なセキュリティリスクがビルドに含まれている場合に、担当者が即座にフィードバックを受け取れるようにガードレールを作成できる必要があります。

早期にセキュリティを組み込む： 「シフトレフト」によって開発プロセスの早い段階でセキュリティを組み込むことで、セキュリティレビューのボトルネックを排除し、アプリケーションをより迅速に公開できるようになるだけでなく、脆弱性や構成ミスの悪用につながるエラーの可能性を減らすことができます。

自動化を活用する： 特に、Kubernetes のフットプリントが複数のクラスタと数百の名前空間に拡大すると、構成の管理やランタイムの動作の監視を手動で行うことはできなくなります。

Kubernetes の安全性を可能な限り高めることに特化した、非常に重要な技術的ベストプラクティスもいくつかあります。

• Kubernetes を最新の状態に保つ：古いバージョン向けのセキュリティパッチは常にリリースされるとは限らないため、サポートされている新しいリリースを実行するようにしましょう。
• ロールベースのアクセス制御を使用する：アクセス権は、常に最小特権の原則に基づいて構成する必要があります。
• Pod 間の通信を制限する：Pod が設計どおりに機能するためには、可能な限り相互の通信を制限する必要があります。
• ネットワーク・セグメンテーションを使用する： 各 Pod は、必要な内部または外部リソースとのみ通信することが可能で、他のすべてのリソースから分離されたままである必要があります。

脆弱性管理は、アプリケーションを安全に保つための重要な要素です。これは、ソフトウェア開発ライフサイクルのすべての段階でセキュリティの脆弱性を特定、評価、修正するプロセスです。コンテナ化されたクラウドネイティブ・アプリケーションの脆弱性管理は、自動化し、アプリケーションの構築と提供を行う DevOps プロセスに統合する必要があります。環境が複雑すぎると脆弱性を手動で管理するのは難しくなり、それによって開発速度が著しく低下する場合、組織はセキュリティ保護の手間を省きたくなるというのが現実でしょう。

脆弱性管理は、アプリケーションが通過しなければならないゲートではなく、ビルド段階でのイメージスキャンとイントロスペクションから始まり、テスト環境と本番環境でのアプリケーションのライフサイクルにわたって続く継続的なプロセスです。

ビルドフェーズでのイメージスキャンとイメージの脆弱性に関するポリシーの実装は、コンテナネイティブの脆弱性を効果的に管理するための最初のステップです。イメージの構築時、またはコンテナの実行後にオンデマンドでスキャンを実行できることが、ランタイムに露出した可能性のある脆弱性を見つけるために重要です。脆弱性管理は、コンテナも Kubernetes も脆弱性の原因となる可能性があるため、その両方で露出を特定できる必要があります。

完全に安全なアプリケーションというものは存在しません。優れた脆弱性管理により、脆弱性だけでなく、特定の脆弱性に関する組織固有の重要度に優先順位を付けるのに役立つ追加情報も確認できます。たとえば、優先度の高い CVE でも、ワークロードの機密性に応じてリスクプロファイルは異なります。優れた脆弱性管理とは、修正のバランスを取り、評価し、優先順位を付けて、可能な限り最良のセキュリティ体制を確立できるようにすることです。

脆弱性管理は、主にクラウドネイティブ・アプリケーションで自動化する必要があります。ポリシーを定義するには人間の知能が必要ですが、ポリシー違反の検出と、脆弱性、リスクレベル、ライフサイクルの重要な要素 (ビルドの失敗、デプロイのブロック、本番環境でのゼロへのスケーリングなどの自動実行) に基づいた適切なアクションの実行には、ツールを活用するべきです。

イメージと脆弱性のスキャンはビルドフェーズで開始する必要がありますが、ランタイムを含めたアプリケーションのライフサイクル全体を通して継続する必要があります。新たなセキュリティの脆弱性はいつでも発見される可能性があり、デプロイメントの実行中に脆弱性を検出する機能は、組織のセキュリティ体制にとって重要です。実行中のデプロイメントにおける脆弱性は、即座にセキュリティリスクにつながる可能性があり、組織にはそれらをできるだけ早く検出して修正する手段が必要です。

ビルドフェーズでは、重大で修正可能な脆弱性を持つイメージを含め、非準拠のイメージはビルドされないようにする必要があり、DevOps チームがそのフィードバックを CI システムで直接取得できることが必要です。セキュリティツールはデプロイ時に管理制御機能を適用して、イメージで検出された既知の脆弱性を持つコンテナがデプロイされるのを自動的に防ぐことができます。脆弱性の重大度、ワークロードの機密性、組織のセキュリティリスクに対する一般的な許容度に応じて、修復に優先順位を付ける方法を知ることが重要です。組織は、時間をかけてカスタマイズされたポリシーを作成し、それらのポリシーを自動化によって (ビルド時とデプロイ時に) 適用できるようにするツールを実装する必要があります。また、デプロイメントの実行後も、引き続き脆弱性をスキャンする必要があります。

イメージスキャナーのさまざまな機能

すべてのイメージスキャナーが同じレベルの包括的なチェックを行うわけではありません。基盤となるオペレーティングシステムのみをスキャンするもの、ライブラリもスキャンするもの、言語レベルのチェックを行うもの、ファイルの内容をスキャンするものがあります。少なくとも組織が必要とするだけの包括性を備え、アプリケーションで使用されるプログラミング言語との互換性があるイメージスキャナーを選択することが重要です。

一部のイメージスキャナーは、イメージをプルするたびにリアルタイムスキャンを実行しますが、この手法ではレイテンシーが増加する場合があるため、組織はリアルタイム情報がパフォーマンスへの影響に値するかどうかを判断する必要があります。

ランタイムでのスキャン

ビルドフェーズでのイメージスキャンと同様に、検出されたすべての脆弱性に同じ対応が必要なわけではありません。組織には、検出された脆弱性の重大度に加えて、ワークロードの機密性、データの機密性、インターネットへの露出に基づいて修復の取り組みに優先順位を付ける方法が必要です。発見された脆弱性への適切な対応を導くための手順やサービスレベル目標は、組織によって異なります。たとえば、重大度や機密性に関係なく、脆弱性が発見されたすべてのコンテナをブロックすることにはトレードオフがあります。実行中のデプロイメントで脆弱性スキャンを成功させるには、適切な可視性と情報を確保するための適切なツールと、脆弱性管理と運用上の影響の適切なバランスを取ることができる、よく考えられた組織のセキュリティポリシーの両方が必要です。

企業ネットワークとその中の分散アプリケーションの複雑性は進化し、浸透を深めるために活用される脅威モデルとその手法もそれに追随しています。安全な境界は、内部ネットワークを保護する最初の防衛線としての機能しか持たず、インフラストラクチャとデータを保護するための包括的な戦略としては機能しません。堅牢なセキュリティを確保するには、制御と戦略を組み合わせることが必要です。

ゼロトラストネットワークは、内部のアプリケーション・トラフィックの安全性の向上に焦点を当てることにより、セキュリティという名のパズルの重要なピースとして機能します。このモデルは、ファイアウォールで保護されたネットワーク内のすべてのトラフィックは信頼できるという長年の原則を覆し、ネットワーク接続はその安全性が証明されるまで安全と見なされるべきではないという、正反対の仮定に基づいています。

従来、ネットワーク管理者は、アプリケーションでも、サーバーでも、あるいはネットワークソフトウェアやハードウェアの一部分でも、内部ネットワークに存在するものはすべてそこに属するものであり、信頼できるものだという前提で作業していました。一部のアプリケーションは、クライアント接続の認証を必要としないか、データベースのパスワードのような静的な共有資格情報に依存していました。すべてのアプリケーションは、必要な認証または承認スキームを使用する場合は、それを処理する必要がありました。多くの場合、内部のネットワーク接続は、機密性の高いサービスの接続であっても、暗号化を使用していませんでした。

多くの企業ネットワークが依然としてこのパターンに従っています。しかし、直接のハッキング、権限保持者が誤って適用したトロイの木馬、ネットワーク・ファイアウォールの穴などから、この緩んだ環境内に侵入してくる可能性のある 1 人の悪意ある攻撃者が、この黙示的に信頼されるネットワークに便乗して大惨事をもたらす可能性があります。可能性は無限ではないかもしれませんが、それらは予測可能です。プレーンテキストのネットワークパケットのスニッフィングから、データベースやその他の重要なシステムへのアプリケーションパスワードの検出、ネットワーク機器の制御の取得に至るまで、この状況はデータの漏えいや損失など、許容できないリスクを被る可能性をもたらします。

ゼロトラストは、ますます増加するセキュリティファーストの本番インフラストラクチャの基盤になっています。ネットワーク上に存在するものはすべて検証せずとも信頼できると仮定するのではなく、ネットワーク・インフラストラクチャそのものさえも信頼できないと仮定します。ゼロトラストのフレームワークは、規範的な実装方法やそのための具体的なテクノロジーを提示していません。それどころか、一連の原則と目標を示すだけで、実装に関する技術的詳細は各組織の判断に委ねています。

ゼロトラスト・アーキテクチャ

ゼロトラスト・アーキテクチャは一般に、次の原則に従います。

• セキュリティ管理は、ネットワークの場所に関係なく、ソフトウェアであれハードウェアであれ、すべての存在物に等しく適用する必要があります。
• ネットワーク接続はその両端、つまりサーバー側とクライアント側の両方で認証される必要があります。現在は、サーバーによるクライアント認証が一般的に期待されていますが、クライアントも有効なサーバーに接続していることを確認する必要があります。接続が複数のトランザクションにまたがる場合は、必要に応じて接続を再認証し、要求を再承認する必要があります。
• 承認の付与は、最小特権の原則に従い、クライアントのワークロードに必要な最小限の権限のみを許可する必要があります。
• すべてのネットワーク接続とトランザクションは、分析のために継続的に監視する必要があります。

Kubernetes でのゼロトラストモデルの実装

Kubernetes クラスタでのゼロトラストモデルはどのようなものでしょうか。Kubernetes クラスタ内にゼロトラストの原則を実装するための手法は存在しませんが、アーキテクチャの目標の多くに適した一般的なソリューションとして、サービスメッシュが浮上しています。

サービスメッシュは、仮想化されたネットワークレイヤーを作成して、分散アプリケーションサービスを接続および制御します。ほとんどのサービスメッシュ・ソリューションは当初、ネットワークセキュリティではなく、インテリジェントなサービス検出と要求ルーティングの促進および管理に重点を置いていましたが、現在、最も人気のあるオープンソース・プロジェクトは、ゼロトラスト・アーキテクチャに適合する機能を提供しています。多くのサービスメッシュは、個々のアプリケーションの変更を必要としないオーバーレイを作成しようとするため、厳密な認証と承認の制御を可能にするために大幅な変更を行うことによる負担の多くを排除します。

Kubernetes をサポートするサービスメッシュは通常、個々のクラスタ Pod に独自のプロキシインスタンスを与えることにより、分散型のポイントツーポイント・ルーティングを使用します。これらのプロキシはクライアント TLS 証明書を管理できます。プロキシはこれを使用して、他のサービスに接続するときや他のクライアントからの接続を受信するときに、その ID を証明できます。この TLS 証明書を使用して、クライアント側とサーバー側の両方で ID を証明することを、相互トランスポート層セキュリティ (mTLS) と呼びます。mTLS は接続認証を実行するだけでなく、ネットワーク接続を暗号化する役割も果たします。回線を介した認証と暗号化に加えて、さまざまなサービスメッシュが、静的リストからサードパーティのシングルサインオンやその他のサービスとの統合に至るまで、さまざまな承認ソースをサポートします。

サービスメッシュは、Kubernetes クラスタに完全なゼロトラスト・ソリューションを提供するわけではありませんが、その中核になる多くのメリットを提供します。Kubernetes クラスタで完璧なゼロトラスト・アーキテクチャを実現できない場合でも、その実現に向けて段階的に変更を加えることは、クラスタとそのワークロードを保護するために役立ちます。

クラウドネイティブ・アプリケーションと基盤のインフラストラクチャをセキュリティ保護するには、組織のセキュリティアプローチを大きく変化させる必要があります。組織は、アプリケーション開発ライフサイクルの早期段階で制御を適用し、組み込みの制御を使用してポリシーを適用することで運用上の問題や拡張性の問題を防止し、短期化が進むリリーススケジュールに対応する必要があります。

Red Hat® Advanced Cluster Security for Kubernetes は Kubernetes ネイティブのセキュリティ・プラットフォームで、クラウドネイティブ・アプリケーションをより安全にどこでも構築、デプロイ、実行し、自信を持ってイノベーションを加速できるようにします。アプリケーションの構築プロセスのセキュリティを向上させ、アプリケーション・プラットフォームと構成を保護し、ランタイムの問題を検出して対応するために役立つソリューションです。