2026-07 / 05
Harumi Platform — 3 つの管理ツールを 1 つに統合
成果3 つに分かれていた運用画面を 1 つの管理コンソールへ統合しました。退役させたツールが抱えていたデータは失わずに移行しています。
概要
クラスターのヘルス・リソース・ドキュメント・接続情報を一元化した単一コンソール。それぞれ運用情報の異なる断片を抱えていた 3 つの管理ツールを置き換えた。
背景
コンソールにはライブな ArgoCD データが必要でしたが、唯一分かっていた管理者資格情報は認証が通らず、権限を絞った読み取り専用アカウントは用意済みでもトークンを発行する手段がまだありませんでした。
システム
Role: get,list on pods · namespace-scoped, no secrets退役は、削除ではない。
Retire the surface, not the data.
3 ops surfaces → 1 console, zero downtime.課題
ドキュメントサイト・旧 Camunda ダッシュボード・infra リポジトリの各種メモという 3 つのツールが、それぞれ「ラボの現状」の異なる断片を保持しており、どこか一箇所を見れば済むという状態ではなかった。最も古いツールを退役させる（4 つ目のツールを追加するのではなく）には、その中に何が同居しているかを先に確認する必要があった——実際にはその前提が崩れていた。
調査
最初の仮説
既存の読み取り専用アカウント向けにトークンを自前で発行すれば、管理者パスワードを完全に回避できると考えました。
まずライブなクラスター状態に対する読み取り専用のコンソールを構築し、退役対象ツールの実際のコンテンツ——URL 一覧、サービスごとの接続情報、ディスク健康ボード——を先に移植した。最も古いツールの namespace に何が同居しているかを監査したところ、その内容とは無関係な共有インフラが 2 つ見つかった——ラボ内すべての公開ホスト名を支える Cloudflare トンネルと、ディスク健康監視 DaemonSet。どちらも新しい Pod へ移設し、健全性を確認してから（トンネルの新旧 Pod は仕様上一時的に同じトークンを共有した）、旧 namespace を削除した。
証拠
# resolved via the platform's own account-token endpoint, not a hand-built claim自前で組み立てた方法はサーバー側に明確に拒否され、その理由は回避策ではなく正規の専用エンドポイントの存在を示していました。
退けた修正
トークンをオフラインで自前構築する方法。複数回試しましたがサーバー側に拒否され、内部で期待される形を推測し続けることは、正規のエンドポイントが既に存在するインターフェースをリバースエンジニアリングすることに他なりませんでした。
判断
既存の管理者アクセス復旧手順で管理者アクセスをリセットし、内部の形を推測し続けるのではなくプラットフォーム自身のアカウントトークン発行エンドポイントでトークンを生成しました。
結果
ディスク健康監視エージェントの Go ソースは、リポジトリが消えた時点でどこにも残っていなかった——復旧できたはずの日次バックアップは、当時オフラインだったマシン上にあった。孤児化したイメージに永久に固定された DaemonSet を残すのではなく、ゼロから書き直した。3 台それぞれで一時的な特権デバッグ Pod を使い、まず実機の smartctl の JSON 出力を採取してからパーサーを実装——サイレントにゴミデータを生むところだった一点（明示的な ATA パススルーフラグでのみ SMART 属性が取得できる USB 接続ドライブ)も含めて確認済み。
次に変えること
現在の制約: 発行される資格情報はデフォルトで短命ではなく手動更新前提です——権限を絞った単一のサービスアカウントとしては許容範囲ですが、より広いシステムに転用すべきパターンではありません。
次の一手: 計画中の読み取り専用 AI 診断レイヤーにも、同じ最小権限・secrets 非許可のパターンを適用します。