はじめに

こんにちは、ACS 事業部の埜下です。

今回は、PlatformCon 2023 の「Enable secure self-service access to Kubernetes clusters with Paralus」というセッションで紹介されている Kubernetes クラスタのアクセス管理で起こる認知負荷と、それを改善する Paralus というツールについて紹介します。

platformcon.com

Kubernetes クラスタのアクセス管理による認知負荷

ここでは、Kubernetes クラスタ内で複数の開発チームが名前空間ごとに開発しているものとして、Kubernetes クラスタのアクセス管理で発生する認知負荷について説明します。

このような環境の場合、チーム毎に「 Kubernetes クラスタのどのリソースを参照/変更できるか」というアクセス管理を RBAC (Role based Access Control) を使ってプラットフォームチームが管理することが多いでしょう。

この際、本来必要ない権限まで開発チームに割り当ててしまうと、他の開発チームによって

自分たちのアプリケーションが動かなくなる
Kubernetes クラスタの共通リソースが使用できなくなる

と言ったトラブルが発生する可能性が出てきます（セッション内ではより詳しいシナリオでトラブルを説明されています）。

このようなトラブルの原因調査や対処をせざるを得ない状況は、開発チームの認知負荷の増大に繋がります。

そのため、プラットフォームチームは「最小権限の原則」に従って、開発に必要な権限だけを開発チームに割り当てていく必要がありますが、このような作業は Kubernetes クラスタの数が少なければ手動で設定できますが、Kubernetes クラスタが 100、200 と増えていくと運用が回らなくなることは想像に難くないですよね。

Kubernetes クラスタを提供する Platform Engineering を進めていく中では、アクセス管理を Kubernetes クラスタのスケールに対応させることは必須と言えます。

Paralus

上記のようなアクセス管理の課題を解決するため Paralus というツールを紹介します。

www.paralus.io

Paralus には以下のような機能があります。

カスタムロール、ユーザ、グループの作成
権限の変更、削除
事前に構成したロールによる Kubernetes クラスタ、名前空間、プロジェクトのアクセス制御
シングルサインオン (GitHub、Google、Azure AD、Okta、etc）
kubectl から確認できる監査ログ
ウェブ GUI、CLI ツール pctl、API を使った操作

文字だけだと分かりづらいので、簡単な図で説明します。

Paralus を導入すると、ユーザは直接 Kubernetes クラスタにアクセスする代わりに Paralus にリクエストを投げます。
ユーザからのリクエストを受け取った Paralus は、認証/認可および監査ログを記録します。
Paralus がユーザに変わって Kubernetes クラスタの Operator にリクエストを投げます。Operator は API Server に対して一時的なサービスアカウントを作成、リクエストの処理、サービスアカウントの削除を依頼します。

大きな流れとしてはこのようになります。実際に触ってはいないこともあり、細かい挙動について説明できていない点はご了承ください。

Paralus を使うことにより、以下のことを実現できます。

プライベートネットワーク内の Kubernetes クラスタへのセキュアなアクセス
RBAC が自動フェデレーションされた一時サービスアカウントを使うことによるアクセス管理
kubectl を使った操作の一元的な監査

セッション内では「インターネットに公開された Kubernetes クラスタが多い」という話もされており、Kubernetes クラスタをプライベートネットワークに置いて、Paralus を使ってセキュアにアクセスしよう、ということのようです。本記事では焦点をアクセス管理に絞ったため説明を省略させていただきました。

以上で Paralus の紹介を終わります。