kubeloginはkubectlのOIDC認証をブラウザログインへつなぐ
Kubernetes OpenID Connect 認証用の kubectl プラグイン (kubectl oidc-login)。
ひと目でわかる
- これは何?
- int128/kubeloginが提供するclient-go資格情報プラグイン、ブラウザログイン、トークンキャッシュ、setup、Apache-2.0ライセンスをREADMEから整理する。
- 誰に向いている?
- kubeloginは、OIDCを使うKubernetesクラスタへkubectlから接続するチーム向けです。クラスタ側がOIDCを提供しない場合や、ブラウザを開けない運用を想定する場合は前提が合いません。
- 商用利用できる?
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている?
- されています。最後のコミットは 3 日前です。
- 何の言語で書かれている?
- 主に Go です(GitHub の言語統計による)。
回答はプロジェクトの GitHub データ(最終同期:2026年9月14日)と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
kubectlのexec資格情報プラグイン
kubeloginはkubectlのプラグインで、OpenID Connect認証を使ってKubernetesへログインします。READMEはclient-goのCredential Pluginとして位置付けており、kubectlそのものに認証機能を追加するというより、exec経由で資格情報を返す部品です。
この形なら、既存のkubeconfigに認証コマンドを組み込めます。評価時は、認証前のkubeconfig、kubeloginが生成したexec設定、kubectl get namespacesなどの実行結果を分けて確認します。OIDCプロバイダーのissuer、client ID、redirect URIは環境依存なので、READMEにない値を推測せずクラスタ管理者の設定と照合します。
kubeloginでは、kubeconfigを共有する前にユーザー名、issuer、client ID、exec引数をレビューします。OIDCのグループ変更がRoleBindingの結果へ反映されるか、ブラウザ認証をキャンセルしたときにkubectlが明確な失敗を返すか、期限切れ後のキャッシュが再利用されないかを確認します。
ブラウザログイン後にトークンを扱う
READMEの説明では、ユーザーはブラウザでログインし、その結果をKubernetesの資格情報として利用します。人のSSOをクラスタアクセスへつなぐため、パスワードをkubeconfigへ直接保存しない方式を取りやすい点が特徴です。
実際の確認では、初回にブラウザが開くこと、認証後にkubectlがAPIへ到達すること、別ユーザーの権限が混ざらないことをテストします。ログイン画面の表示だけで成功とせず、kubectl auth can-iで予定した権限を確認します。MFAやグループ連携の動作はOIDCサーバーとクラスタの設定も含めて検証します。
kubeloginを配布する際は、ユーザーごとに異なるOIDC情報をkubeconfigへ混ぜないようにします。認証プロバイダーのログイン監査とKubernetes APIの監査を時刻で照合し、退職者のIdPアカウントを無効にした後にキャッシュだけでアクセスできないことを確認します。
トークンキャッシュが再ログイン回数を左右する
kubeloginはトークンキャッシュをREADMEで説明しています。キャッシュが利用できれば毎回ブラウザを開く必要を減らせますが、保存場所、暗号化、失効時の扱いは利用環境で確認すべき管理項目です。
検証では、初回ログイン後に同じkubeconfigで再実行し、ブラウザなしで期限内のアクセスが通るかを見ます。キャッシュを削除または期限切れにした場合に再認証へ戻ること、共有端末に別ユーザーのトークンが残らないことも確認します。READMEに保管方式の保証がなければ、OSの権限と端末管理を前提に置きます。
setupコマンドでkubeconfigを組み立てる
READMEはsetupコマンドを含むセットアップ手順を案内しています。手動でexecブロックを編集するより、必要な引数を指定してkubectlが呼ぶ認証コマンドを構成する入口として使えます。
採用前は、まず検証用のkubeconfigをコピーし、setupを実行した前後で差分を確認します。issuer URL、client ID、listen addressなど実環境に関係する値がどこへ書かれたかを確認し、共有リポジトリやログへトークンを出さないようにします。生成物を本番設定へ上書きする前に、対象コンテキストを限定してください。
権限境界はOIDCとRBACの組み合わせ
kubeloginは認証の部品であり、ユーザーが何を操作できるかを決めるRBACそのものではありません。OIDCで得たユーザーやグループの情報を、クラスタ側のRoleBindingなどがどう扱うかがアクセス範囲を決めます。
テストは管理者アカウント一つだけで終えず、一般ユーザー、グループ所属の変更、期限切れトークンを分けます。kubectlの成功と認可の正しさを別々に記録し、execプラグインが返す資格情報をデバッグログへ不用意に出さない設定も確認します。READMEは個別のRBAC設計を規定していません。
OIDCを採用できるクラスタに絞る
Apache 2.0のkubeloginは、OIDCログインとclient-goの資格情報プラグインを必要とする環境に価値があります。静的証明書だけで運用するクラスタ、完全な無人ジョブ、ブラウザのない閉域端末は追加設計が必要です。
対象チームは、認証プロバイダー、Kubernetes APIのOIDC設定、利用端末のブラウザとキャッシュ保護を管理できる組織です。まずsetupで生成されたexec設定をレビューし、初回ログイン、再利用、期限切れ、権限不足の四つの結果を取得してから全員へ展開してください。
kubeloginの実証では、検証用OIDCクライアントと一つのKubernetesコンテキストを用意し、setup実行前後のkubeconfig差分を保存します。初回のブラウザログイン、同じキャッシュを使う再実行、キャッシュ削除後の再認証、期限切れトークンの四つを分けて試します。一般ユーザーのkubectl getと管理操作をkubectl auth can-iで比較し、認証成功とRBAC認可を別の結果として記録します。端末共有時はキャッシュのファイル権限とログ出力にトークンが含まれないことも点検します。
編集部の結論
kubeloginは、OIDCを使うKubernetesクラスタへkubectlから接続するチーム向けです。クラスタ側がOIDCを提供しない場合や、ブラウザを開けない運用を想定する場合は前提が合いません。採用前にREADMEのsetup手順で検証用kubeconfigを作り、認証後のexec設定、トークンキャッシュの場所、期限切れ後の再ログインを確認してください。
コミュニティノート