k8s-breakglass: Kubernetes の一時権限昇格を監査可能な workflow にする

Kubernetes の権限管理は、平常時だけを見ると比較的きれいに見えます。

普段は namespace 単位の権限に絞る;
production では cluster-admin を厳しく制限する;
RBAC rule は細かく分ける;
長期の高権限 credential はなるべく持たせない。

ただ、障害対応、migration、深い troubleshooting、cluster-wide な変更が必要になると、急に難しくなります。

誰かに一時的に強い権限が必要になる;
でも permanent に与えたくはない;
approval、reason、audit trail は残したい;
できれば RoleBinding の手作業追加と削除にも頼りたくない。

今日メモしておきたい telekom/k8s-breakglass は、この問題をかなり正面から扱っている project です。新しい Kubernetes platform を作るのでも、一般的な enterprise IAM を置き換えるのでもなく、Kubernetes の temporary privilege escalation を、より auditable な workflow として扱います。

GitHub repository page と release page を 2026-06-25 時点で確認すると、この repository は 29 stars、6 forks、主要言語は Go。repository の作成日は 2024-07-03、直近の公開更新は 2026-06-25 です。license は Apache-2.0。最新 release は v0.1.0-beta.29 で、公開日は 2026-06-23 です。

Project overview

項目	内容
Repository	telekom/k8s-breakglass
位置づけ	Kubernetes cluster 向け temporary privilege escalation system
Stars	29
Forks	6
主要言語	Go
作成日	2024-07-03
直近の公開更新	2026-06-25
License	Apache-2.0
Latest release	v0.1.0-beta.29
Release date	2026-06-23

普通の RBAC 管理ではなく、「緊急時にどう安全に強い権限を渡すか」を扱っている

README では、この project を secure, auditable privilege escalation system for Kubernetes clusters と定義しています。

大事なのは、単に「権限を上げられる」ことではありません。

user が request する;
approver が review して approve する;
access は一定時間だけ有効になる;
すべての action に audit trail が残る;
実際の authorization は Kubernetes webhook 経由で判定される。

多くの team の temporary access は、実際には次のような形になりがちです。

誰かが手で RoleBinding を追加する;
高権限 kubeconfig を一時配布する;
script で group を一時追加し、あとで戻す;
chat 上で合意して、そのまま作業してもらう。

これらは小規模なら回ることもありますが、共通の弱点があります。approval、real access、expiration が分離しやすい ことです。

k8s-breakglass は、その 3 つを同じ system に閉じ込めようとしています。

一番重要なのは、authorization を Kubernetes の webhook path に入れていること

この project で一番良いのは、approval UI を単なる申請フォームで終わらせていない点です。

基本の flow はこうです。

user がある cluster 上の elevated group を request する;
approver が approve する;
breakglass が central service 側で session を持つ;
target cluster の API Server が authorization 時に breakglass webhook を呼ぶ;
有効な session がある場合だけ request が許可される。

つまり、「approval 後に新しい credential を配る」よりも、temporary authorization state を実際の access 判定に直接つなぐ 設計です。

これはかなり実務的です。

権限の開始と終了が session lifecycle に従う;
期限切れ後の credential 回収を手でやらなくてよい;
audit trail と authorization decision が同じ system を見る;
複数 cluster を central hub で一貫管理しやすい。

README でも architecture は hub-and-spoke と説明されています。中央の breakglass service が複数 cluster を管理し、cluster 側は ClusterConfig と webhook で接続します。単一 cluster の utility というより、temporary elevated access 専用の control layer に近いです。

CRD 設計を見ると、単なる helper script ではなく状態機械として作られている

この project は主要な policy と state を Kubernetes CRD として表現しています。

README に挙がっている代表的な object は次の通りです。

BreakglassEscalation: どの escalation path を request できるか;
BreakglassSession: request、approval、active session の記録;
ClusterConfig: 管理対象 cluster の接続定義;
DenyPolicy: 明示的に拒否する access rule;
AuditConfig: Kafka、webhook、log、Kubernetes audit sink の設定;
IdentityProvider: OIDC provider の設定;
MailProvider: notification 設定;
DebugSession と関連 template: time-bounded debug workflow。

ここが重要です。単に database に request record を保存しているだけではなく、permission path、approval path、audit sink、cluster attachment を declaration として持っています。

Platform team にとって大事なのは、むしろこの部分です。

policy を version control に乗せられるか;
configuration を review できるか;
state から復元できるか;
audit data を export できるか;
複数 controller replica でも state が壊れないか。

Advanced documentation では session state、retain policy、timestamp preservation、terminal state の扱いまで説明されています。かなり「長く動く system」として考えられています。

Compliance 寄りの細部まで意識している

もう 1 つ良いのは、現実の approval flow で効いてくる細部がかなり揃っていることです。

たとえば advanced features では、

request reason を mandatory にできる;
approval reason も required / optional を選べる;
requester の self-approval を防げる;
approver の email domain を制限できる;
maxValidFor、idleTimeout、retainFor を設定できる;
DenyPolicy を escalation より先に評価できる;

と説明されています。

こうした機能は派手ではありませんが、実務ではかなり重要です。

組織が本当に困るのは、

reason を ticket ID と紐付けたい;
production access を誰が approve できるか厳密にしたい;
contractor や別 tenant の approver を制御したい;
session が終わった後も監査向けに一定期間残したい;
強い権限でも触れてはいけない resource を決めたい;

といった部分だからです。

k8s-breakglass は、その種の friction point に明示的な model を置いています。そこが toy project っぽくないところです。

Web UI だけではなく、CLI、API、debug session まである

README によると、利用面は次の 3 つがあります。

Web UI;
bgctl CLI;
REST API。

つまり単なる browser portal ではありません。Internal platform や automation script からも扱えます。

さらに面白いのは、ただ権限を上げるだけではなく debug session を first-class に扱っている点です。DebugSession、template、cluster binding があり、制御された debug pod や調査用 workflow を temporary session として扱う方向が見えます。

これは、「誰をどの group に入れるか」だけではなく、短時間の運用作業そのものを管理対象にする 発想です。

Quick Start を見ると、実際の導入ハードルもよく分かる

もちろん、この project は軽くはありません。

Quick Start にある前提はかなり明確です。

hub cluster が必要;
OIDC provider が必要;
tenant cluster から hub への network access が必要;
API Server に authorization webhook を設定する必要がある;
IdentityProvider、MailProvider、BreakglassEscalation、ClusterConfig などの resource を作る必要がある。

つまり、すでにある程度 platform 化された Kubernetes 環境向けです。

もし環境が

小さな開発 cluster だけ;
管理者が少ない;
OIDC や approval chain がない;
API Server の設定変更も難しい;

という状態なら、k8s-breakglass は重すぎるはずです。

逆に、

multi-cluster を運用している;
temporary production access を system 化したい;
approval と expiration を chat ではなく state machine にしたい;
audit と policy を code と object に寄せたい;

なら、この重さはむしろ意味があります。

向いている team

この project は、次のような team に向いています。

Kubernetes の temporary elevated access を厳密に管理したい platform team;
emergency access を chat や手作業から脱却させたい組織;
複数 cluster に対する共通の escalation / audit entry point がほしい環境;
OIDC と API Server webhook の変更を受け入れられる team;
approval、expiration、audit、debug workflow を同じ model に寄せたい人。

境界もかなり明確

k8s-breakglass は、

汎用 enterprise IAM の置き換えではない;
完全な multi-tenant Kubernetes platform でもない;
個人向けの zero-config utility でもない;
control plane を触らずに簡単導入できる tool でもない。

解いている問いはかなり具体的です。Kubernetes の高権限 access を、期限付き・承認付き・監査可能・回収可能な session として扱えるか。

問題設定がそこにあるなら、かなり面白い repository です。

まとめ

telekom/k8s-breakglass の価値は、「高権限を取りやすくする」ことではなく、雑になりがちな temporary privilege escalation を、きちんとした authorization path に押し込んでいることです。

request と approval は状態を持つ;
access 判定は webhook でリアルタイムに行う;
session には expiry と retention がある;
policy、audit、cluster integration は declarative object で表される。

もしあなたの team が、Kubernetes の temporary admin access をもう少し engineering discipline のある system にしたいなら、この repository は読む価値があります。