ゼロトラスト原則を使用して Kubernetes 環境へのアクセスを保護する

現代の IT 環境はますます動的になっています。たとえば、Kubernetes は多くの組織の可能性の境界を広げます。オープンソース テクノロジーは、コンテナ化されたアプリケーションの自動展開、スケーラビリティ、管理の面で多くの利点を提供します。特に、IT チームはそのパワー、有効性、柔軟性を活用して、最新のアプリケーションを迅速に開発し、大規模に提供することができます。

しかし、Kubernetes 環境でセキュリティ強化対策を確実に実施するプロセスはますます困難になっています。オンプレミスのデータセンター、複数のパブリック クラウド プロバイダー、エッジ ロケーションに分散された Kubernetes 開発および本番環境クラスターの数が増えるにつれて、この比較的新しい動的な運用モデルにより、アクセス制御が大幅に複雑化します。

ほとんどのチームでは、複数の場所で複数のクラスターが実行されており、多くの場合、異なる管理インターフェースを持つ異なるディストリビューションを使用しているため、企業の IT 部門は、開発、運用、請負業者、およびパートナー チームには異なるレベルのアクセスが必要であることを考慮する必要があります。

Kubernetes の分散性とスケーラビリティを考慮すると、IT 部門はアクセス セキュリティを確保し、発生しているミスを回避するためにあらゆる手段を講じる必要があります。以下では、Kubernetes ゼロ トラストの原則を適用して環境全体を保護し、コンテナにゼロ トラスト セキュリティを提供する方法について説明します。

Kubernetes クラスターへのゼロトラスト アクセス

ゼロ トラストは、ネットワーク内またはネットワーク全体で動作するすべての人、システム、およびサービスは信頼できないと自動的に想定するセキュリティ モデルです。ゼロ トラストは、悪意のある攻撃を防ぐための最良のテクノロジーとして浮上しています。ゼロ トラストは、認証、承認、暗号化テクノロジに基づいて、セキュリティ構成と態勢を継続的に検証し、環境全体が信頼できることを確認することを目的としています。

Kubernetes が基本的にどのように動作するかを簡単に説明します。

• 各クラスターの Kubernetes コントロール プレーンの中核となるのは、Kubernetes API サーバーです。
• API を呼び出して、すべての Kubernetes オブジェクトの状態を照会および操作できます。
• Kubernetes オブジェクトには、名前空間、ポッド、構成情報などが含まれます。API アクセス制御は、Kubernetes アクセスを管理し、ゼロ トラストを実現するための重要な機能です。 Kubernetes クラスターへのアクセスを保護するための最初のステップは、トランスポート層セキュリティ (TLS) を使用して API サーバーとの間のトラフィックを保護することです。

API サーバーにゼロ トラストを実装するためのベスト プラクティス:

• どこでも TLS を有効にします。
• API サーバーのプライベート エンドポイントを使用します。
• API サーバーはサードパーティ認証を使用します。
• API サーバーのファイアウォール受信ルールを無効にして、API サーバーが見えなくなり、インターネットから直接アクセスできないようにします。トランスポート層のセキュリティを確保した後、Kubernetes には、ゼロ トラストを実装し、各 Kubernetes クラスターの API サーバーへのアクセスを制御するために必要なフックも含まれています。これらのフックは、Kubernetes の強固なセキュリティ体制の 4 つの主要領域を表しています。
• 認証
• 承認
• 入場管理
• ログ記録と監査

Kubernetes 認証

ゼロ トラストの原則では、Kubernetes クラスターに関連付けられているすべてのユーザー アカウントとサービス アカウントは、API 呼び出しを行う前に認証される必要があります。 Kubernetes プラットフォームがチームの優先認証システムで効果的に動作することを保証するために、さまざまなセキュリティ モジュールとプラグインが用意されています。

• HTTP 基本認証
• 認証プロキシ（LDAP、SAML、Kerberos などをサポートするため）
• クライアント証明書
• 無記名トークン
• OpenID Connect トークン
• Webhook トークン認証 一般的な認証のベスト プラクティスは、少なくとも 2 つの認証方法 (多要素認証または MFA) を有効にし、クライアント証明書を定期的にローテーションすることです。

Kubernetes 認証

認証されると、すべてのユーザー アカウントまたはサービス アカウントが Kubernetes クラスターにアクセスし、可能なすべての操作を実行できるようになるため、これを削減する必要があります。ゼロ トラストの考え方は、認証されたユーザーが要求されたアクションを完了するために必要な権限を持っている場合にのみ、リクエストが承認されるというものです。モデルでは、リクエストごとにユーザー名、アクション、影響を受ける Kubernetes クラスター オブジェクトを指定する必要があります。 Kubernetes は、次のような多くの認証方法をサポートしています。

• 属性ベースのアクセス制御 (ABAC) は、ユーザー、環境、リソースの属性の組み合わせに基づいてアクセスを動的に承認します。
• ロールベースのアクセス制御 (RBAC) は、組織内の役割 (開発者、管理者、セキュリティ担当者など) に基づいてユーザーにアクセス権を付与します。組織で最も一般的に使用されるアプローチは RBAC です。これは、実用的で、制御が簡単で、ほとんどの状況で必要な粒度を提供できるためです。業界では、最小権限 RBAC を有効にするのが一般的です。

ABAC はさらなる細分性を提供しますが、適切に定義および構成するには追加の時間とリソースも必要になります。ただし、ABAC アプローチのトラブルシューティングはより困難です。したがって、一般的な方法は、最小権限 RBAC を有効にすることです。

Kubernetes アドミッションコントロール

アドミッション コントローラーは、Kubernetes のゼロ トラスト アプローチを改善するビジネス ロジックを実装する方法を提供します。その目的は、Kubernetes オブジェクトの作成、変更、削除、または接続の要求にシステムが自動的に応答できるようにすることです。場合によっては、組織のニーズを満たすために複数のアドミッション コントローラを有効にする必要があり、特定のリクエストがいずれかのアドミッション コントローラによって拒否された場合、システムも自動的にそのリクエストを拒否します。

現在、Kubernetes に組み込まれているさまざまなアドミッション コントローラーは、ポリシーを適用し、さまざまな操作を実装するための幅広いオプションをチームに提供しています。動的コントローラーは、定義されたルール セットの要件を満たすようにリクエストをすばやく変更できます。たとえば、ResourceQuota アドミッション コントローラは、受信要求を監視して、ResourceQuota オブジェクトにリストされている名前空間の制約に違反していないことを確認できます。詳細については、「アドミッション コントローラーの使用」ドキュメントを参照してください。

Kubernetes のログ記録と監査

監査レベルには 4 つの種類があります。

• なし - このイベントを記録しない
• メタデータ - レコード要求メタデータ
• リクエスト - イベントのメタデータとリクエストを記録する
• RequestResponse – イベントのメタデータ、リクエスト、および応答をログに記録します。監査レベルを指定するだけでなく、チームは監査対象イベントが保存される場所も制御できます。ログ記録バックエンドはイベントをクラスターのローカル ファイル システムに書き込み、Webhook バックエンドは監査イベントを外部ログ記録システムに送信します。

ゼロトラストアーキテクチャの拡張

上記の方法と実践によりゼロ トラスト環境を作成できますが、管理する Kubernetes クラスターが多数ある場合、これらすべての要素を適切に構成および調整することはより困難になります。複数のワークロードと Kubernetes ディストリビューションが関係する場合、状況は特に複雑になります。これは新しい課題ではなく、今日多くの企業が直面している課題です。

例えば、このような状況を考えてみましょう。同社は、開発から QA、ステージング、そして本番環境まで、100 個の Kubernetes クラスターを管理しており、アプリケーションがリアルタイムのビデオおよびオーディオ データ ストリームを処理できるように、これらのクラスターは世界中の顧客ベースに地理的に近い場所に配置する必要がありました。

Kubernetes クラスターへの安全なユーザー アクセスを確保するには、企業は次の 3 つの問題に対処する必要があります。

1. 企業に何百人もの開発者と何十人もの IT 運用スタッフがいて、各クラスターへのユーザーの追加や削除を手動で行う必要がある場合、この大変な作業によって発生する問題よりも多くの問題が解決されます。
2. 予期しない事態が発生した場合、修復時間は非常に重要です。アクセス方法により、トラブルシューターが影響を受けるクラスターにログインするのに数分かかる場合、問題が悪化する可能性があります。
3. ログは数百のクラスターに分散されているため、監査およびコンプライアンス レポートのグローバル ビューを提供することはできません。

プラットフォームチーム向けの注意事項

エンタープライズ プラットフォーム チームの多くの目標の 1 つは、世界中に分散した IT チームがすべてのクラスターへのユーザー アクセスを一元的に管理できるようにすることです。目標は、Kubernetes インフラストラクチャへのアクセスを効果的に保護および管理すると同時に、監査ログとコンプライアンス レポートを大幅に簡素化することです。

プラットフォーム チームは、Kubernetes のゼロ トラスト アクセスの実装を検討し、Kubernetes 環境全体のセキュリティを確保するために、前述のベスト プラクティスを適用および実施する必要があります。すべてのクラスターにベスト プラクティスを手動で適用する必要がなくなるため、Kubernetes を大規模に運用する場合の IT 組織のリスクを大幅に軽減できます。

プラットフォーム チームは、Kubernetes のゼロ トラスト アクセスを設計する際に、次の 3 つの利点を考慮する必要があります。

1. RBAC を非常に柔軟にする: チーム メンバーの役割が変更された場合、アクセス権限は自動的に更新され、どのメンバーも自分の役割よりも多くの権限または少ない権限を持つことはありません。

2. アクセスを高速かつシンプルにする: 安全なシングル サインオンを通じて承認されたユーザーにシームレスなアクセスを提供し、クラスターへのアクセスの遅延を排除します。

3. インスタント シナリオ資格情報: 承認されたユーザーのサービス アカウントは、ユーザーがアクセスするとすぐにリモート クラスター上に作成され、証明書の有効期限が切れないように、ユーザーがログアウトすると自動的に削除されます。 Kubernetes クラスターとコンテナ化されたアプリケーションが拡大するにつれて、組織は 1 つまたは 2 つのクラスターを運用しているときには明らかではなかったセキュリティ リスクにますますさらされるようになります。したがって、プラットフォーム チームは、Kubernetes インフラストラクチャ全体のクラスターとアプリケーションに対して、集中型のエンタープライズ レベルのセキュリティと制御を実装する必要があります。