マルチクラスタKubernetes管理とアクセス

翻訳者 |李睿

校正：孫淑娟

攻撃から守るための巨大な壁、強固な門、監視塔、堀を備えた巨大な要塞を想像することができます。砦には攻撃者を阻止するための多層防御が施されており、攻撃者は堀を泳いで渡ることはできたとしても、砦内に入るには高い壁をよじ登る必要があった。したがって、攻撃者は単一の防御層しか突破できない可能性がありますが、複数の防御層があると要塞に侵入することが困難になります。

よく見ると、これらの防御層はすべて、攻撃者の侵入を阻止するという 1 つの目的を果たしていることがわかります。これは、アプリケーションを保護するために必要なことであり、不正アクセスに対する多層防御です。 Kubernetes のアクセス制御に関しては、管理すべきさまざまなコンポーネントが存在します。 Kubernetes クラスターは本質的に複雑かつ動的であるため、サイバー攻撃に対して脆弱です。

この記事では、複数の Kubernetes クラスターへのアクセスを管理するための基本的な考慮事項について説明し、企業が全体的な Kubernetes セキュリティをより適切に計画できるようにします。

Kubernetes APIサーバーの分離

Kubernetes クラスターでは、通常、制御プラットフォームはノードの制御に使用され、ノードはポッドの制御に使用され、ポッドはコンテナの制御に使用され、コンテナはアプリケーションの制御に使用されます。しかし、プラットフォームを制御するものは何でしょうか? Kubernetes は、企業が Kubernetes クラスター全体を構成できるようにする API を公開しているため、Kubernetes API へのアクセスを保護することは、Kubernetes を安全に保つ上で最も重要な考慮事項の 1 つです。 Kubernetes は完全に API 駆動型であるため、クラスターにアクセスできるユーザーと、そのユーザーが実行できるアクションを制御および制限することが第一の防御線となります。

Kubernetes アクセス制御の 3 つのステップを見てみましょう。認証プロセスを開始する前に、ネットワーク アクセス制御と TLS 接続が適切に構成されていることを確認することが最優先事項です。

（１）API認証

アクセス制御の最初のステップは、要求を認証することです。可能な場合は、外部認証サービスを使用することをお勧めします。たとえば、組織が既に Okta、GSuite、Azure AD などの ID プロバイダー (IdP) を使用してユーザーを認証し、ユーザー アカウントを管理している場合などです。 Kubernetes API サーバーは認証方法が実行される順序を保証しないため、ユーザーが 1 つの認証方法のみにバインドされるようにすることが重要です。以前使用した認証方法とトークンを定期的に確認し、使用されなくなった場合は非アクティブ化することも重要です。

（２）API認証

認証されると、Kubernetes はリクエストが承認されているかどうかを確認します。 API アクセスを承認するには、ロールベースのアクセス制御 (RBAC) が推奨される方法です。デフォルトでは、cluster-admin、admin、edit、view という 4 つの組み込み Kubernetes ロールに注意する必要があります。クラスター ロールは、クラスター リソース (ノードなど) に対する権限を設定するために使用できますが、そのロールは名前空間リソース (ポッドなど) に対して使用できます。 Kubernetes の RBAC には、ある程度の複雑さと手動操作が伴います。

（３）アクセス制御

特定のタスクを実行するための認証と承認が成功した後、最後のステップは、要求を変更または検証するためのアドミッション コントロールです。 Kubernetes には、リソース要求の制限や Pod セキュリティ ポリシーの適用など、クラスター上で実行できるものを定義およびカスタマイズするのに役立つモジュールがいくつか用意されています。アドミッション コントローラーは、イメージ スキャンの実装など、高度なセキュリティを実現する Webhook を使用して Kubernetes API サーバーを拡張するためにも使用できます。

ロールベースのアクセス制御 (RBAC)

Kubernetes がこれほど広く採用されている理由の 1 つは、活発なコミュニティと定期的なアップデートです。 Kubernetes 1.6 で導入された重要なアップデートの 1 つは、ロールベースのアクセス制御 (RBAC) です。基本的な認証と承認は RBAC によって処理されますが、複数のクラスター環境ではロールの作成と保守が重要になります。組み込みの cluster-admin ロールを任意のユーザーに付与すると、そのユーザーはクラスター内で事実上すべてのアクションを実行できるようになります。役割とアクセス権の管理と追跡は困難です。

大規模なマルチクラスター環境を持つ企業では、多数のリソースが作成および削除されるため、使用されていないロールや失われたロールが放置されるリスクが高まります。将来新しいロールを作成すると、一部の非アクティブなロール バインディングによって予期せず権限が付与される可能性があります。これは、ロール バインディングが、もう存在しないロールを参照する可能性があるために発生します。将来同じロール名が使用されると、これらの未使用のロール バインディングによって、存在すべきではない権限が付与される可能性があります。

クラスターの複雑性とダイナミクス

クラスター、ロール、ユーザーの数が増えるにつれて、制御を確実に行うには、ユーザー、グループ、ロール、権限を適切に可視化する必要があります。新しいロールが追加されるたびに、追加のルールを構成する必要があります。大企業の場合、これは管理すべきルールが数百、あるいは数千に及ぶことを意味する場合があります。クラスター内のすべてのロールを管理する集中型システムがないことは、管理者にとって最悪の悪夢です。

Kubernetes が人気を博している理由の 1 つは、本質的にスケーラブルであることです。すぐに使用できるセキュリティ ツールが付属しており、必要に応じてアプリケーションとインフラストラクチャを拡張できます。つまり、Kubernetes クラスターは一時的なものであり、即座に作成および破棄できるということです。クラスターを作成または破棄するたびに、特定のユーザーのアクセス権限を構成する必要があります。クラスターへのアクセスが適切に管理されていない場合、クラスター全体への不正アクセスを許可するセキュリティ侵害が発生する可能性があります。

結論は

今日、ほとんどのチームは企業内のさまざまな事業部門に分散しています。一般的なシナリオでは、開発者、テスター、ビジネス アナリスト、コンサルタントがすべて同じアプリケーションで作業し、それぞれが異なるクラスターまたは同じクラスターの異なるコンポーネントにアクセスする必要がある場合があります。さまざまなユーザーに適切なレベルのアクセスを提供し、必要に応じてそのアクセスを取り消すことが重要です。

Kubernetes は、ノード、クラスター、ポッド、コンテナー、ボリュームなどの複数のコンポーネントで構成された、よく調整されたシステムです。大規模な場合、これらのコンポーネントの数百を世界中の複数のクラスターに分散できます。 「誰が」何を必要としているのかを特定し、「どの」リソースにアクセスするのかが困難になります。そうして初めて、組織のインフラストラクチャとシームレスに統合されるだけでなく、複数のクラスターへのアクセスを安全かつ統一された方法で管理できる Kubernetes セキュリティ ツールの必要性が認識されるでしょう。

原題:マルチクラスター Kubernetes 管理とアクセス、著者: Kyle Hunter