CNCFのブログに掲載された資料は、Kubernetesクラスターへのアクセス制御を、ネットワークやストレージと並ぶ基本的な設定項目の一部として扱うことを推奨している。これは、マネージドKubernetesサービスのようにIAMやSSOとの統合が通常すぐに利用できない自己ホスト型環境で特に重要である。中心となる考え方は、KeycloakのようなOIDC準拠のアイデンティティープロバイダーを使用し、共有キーを持つ秘密クライアントではなく、PKCEを使用する一般クライアントとしてクライアントを登録することである。
多くのローカルクラスターでは、アクセスに固定されたクライアント証明書や、一度だけ発行される長期有効なトークンが使用されている。従業員が退職した後、役割が変わった後、またはそれらを保存したデバイスを紛失した後も、これらの認証情報は有効なままになる。また、アクセスを取り消すには、証明書ファイルやトークンのすべてのコピーを見つけなければならない。デバイスやユーザーが増えると、この作業を完全に実施できる保証は難しい。人数が増え、権限レベルが異なるようになると、ファイルの配布と管理は継続的な運用作業になる。
OIDCによって何が変わるのか
権限は証明書ファイルではなく、ユーザーアカウントとアイデンティティープロバイダー内のグループメンバーシップに結び付けられる。統合は、kubectlとkubeloginまたはkubectl oidc-loginプラグイン、ユーザーを認証してIDトークンを発行するアイデンティティープロバイダー、そしてトークンを検証してユーザー名とグループを抽出し、許可される操作の決定をKubernetes RBACに委ねるkube-apiserverという、相互に関連する3者で構成される。
kubectlは、ログインを開始するために最初にAPIサーバーへ接続するわけではない。exec-credentialプラグインがアイデンティティープロバイダーでブラウザーを介したログインを開始し、その後IDトークンをkubectlに返して、ベアラートークンの認証情報として送信する。APIサーバーは、アイデンティティープロバイダーの公開署名鍵を使用してトークンを検証する。資料によれば、サーバーがアイデンティティープロバイダーへの継続的な接続を必要とすることはなく、必要に応じてこれらの鍵を取得する場合を除く。
クライアントはなぜ一般クライアントであるべきなのか
秘密クライアントでは、鍵が発行され、kubeloginプラグインの設定に追加され、アクセスを必要とするすべてのデバイスに配布される。資料は、すべてのクライアントに配布しなければならない鍵は、もはや実際の秘密ではなく、ローテーションが難しい共有された固定認証情報だと指摘している。コマンドラインアプリケーションやネイティブアプリケーションでは、最も適切な選択は、秘密を持たない一般クライアントにPKCE（Proof Key for Code Exchange）を有効にすることである。
クライアントはローカルでランダムな値を生成し、初期ログイン要求でその値のハッシュを送信し、その後、認可コードをアクセストークンと交換する際に元の値を所有していることを証明する。そのため、認可コードだけを傍受した者は処理を完了できない。資料に示されたKeycloakの設定では、クライアント認証を無効にし、標準フローを有効にし、ダイレクトアクセスグラントを無効にし、S256を使用するPKCEを強制する。また、リダイレクトURIとWebオリジンを127.0.0.1やlocalhostなどのループバックアドレスに限定する。
基本的な設定手順
- Keycloakのクライアントスコープにグループメンバーシップマッパーを追加し、IDトークン内にgroupsという名前のクレームが現れるようにする。
- oidc-issuer-url、oidc-client-id、oidc-username-claim、oidc-groups-claimなどのフラグを使用してkube-apiserverを設定する。
- アイデンティティープロバイダーが一般に信頼された認証局によって署名されていない証明書を使用する場合は、oidc-ca-fileを追加し、APIサーバーがTLS接続を検証して署名鍵を取得できるようにする。
- 証明書や固定トークンを埋め込むのではなく、kubectl oidc-loginを介したexec-credentialエントリを使用するようkubeconfigを変更する。秘密のフィールドは追加しない。
- アイデンティティープロバイダーのグループをKubernetes RBACのロールに関連付ける。たとえば、platform-viewerグループをviewロールに関連付ける。
実際の影響と制限
この連携後は、アクセスに関する変更をクラスター内で行ったりkubeconfigを再配布したりするのではなく、アイデンティティープロバイダー内で行う。ユーザーをグループに追加または削除すると、ユーザーが次に取得するトークンに新しいグループメンバーシップが反映され、そのグループに関連付けられたRBACルールが適用される。資料によれば、初回ログインではブラウザーが開くが、kubeloginは保存されたトークンを有効期限が切れるまで再利用し、その後は新たにブラウザーを開くことなくリフレッシュトークンを使用する。実際のアイデンティティーとグループは、kubectl auth whoamiコマンドで確認できる。
これは、統合に運用上の要件がないという意味ではない。グループクレームを正確に設定し、アイデンティティープロバイダーの証明書を検証し、リダイレクトURIを限定し、RBACロールが必要な権限を反映していることを確認する必要がある。また、資料は設定時間や運用コストについて独立した測定値を示しておらず、プラットフォーム全体を移行するのではなく、1回の勤務時間内に準備できる可能性があると見積もっている。
セキュリティ面および管理面で最も重要な利点は、Kubernetesのログが実際のユーザーアイデンティティーに結び付くことである。cluster-adminのような一般アカウントに依存するログでは、リクエストの実行者を区別できない。一方、OIDCを介して送信された各リクエストには、ユーザー名と関連するグループが含まれる。これは資料の詳細に基づく編集上の解釈である。改善点はログイン方法だけではなく、行為をその実行者に帰属させやすくなること、そして権限の付与と撤回が、分散した認証情報ファイルを探す作業ではなく、中央集約されたアイデンティティーの処理になることである。