Kubernetes Dashboardはなぜ非推奨になったのか — 代替としてのHeadlampへの移行

Kubernetesを初めて使う人にとって、Kubernetes Dashboardは馴染みのあるツールでした。PodやDeploymentの状態をウェブ画面で確認し、ログを見たりYAMLを修正したりできるため、kubectlに不慣れなユーザーにとって良い出発点でした。

しかし、状況は変わりました。Kubernetesの公式ドキュメントは、Dashboardをdeprecated and unmaintained、つまり使用中止予定であり、メンテナンスされていないプロジェクトとして明記しています。プロジェクトのリポジトリも2026年1月21日にアーカイブされ、読み取り専用の状態になりました。

公式ドキュメントが新規インストールの代替として案内するツールがHeadlampです。Headlampは単に以前のDashboard画面を再作成した製品ではなく、マルチクラスター・プラグイン・デスクトップ実行とインクラスターデプロイメントを共にサポートする現代的なKubernetes UIです。

この記事では、Dashboardの非推奨化が運用環境にどのような意味を持つのか、Headlampが何を改善したのか、実際の移行プロセスで認証とRBACをどのように設計すべきかをまとめます。

古い単一クラスター管理画面から現代的なマルチクラスターUIへの移行の様子

Kubernetes Dashboardに何が起こったのか

Kubernetes公式Dashboardドキュメントには現在次の内容が明確に表示されています。

Kubernetes Dashboard is deprecated and unmaintained.

これは単に最新機能の追加が遅れるという意味ではありません。リポジトリがアーカイブされ、積極的なメンテナンスが終了したため、新しいKubernetesバージョンとの互換性、セキュリティ脆弱性への対応、依存関係の更新を期待することが難しくなったという意味です。

区分	現在の状態
Kubernetes Dashboard ドキュメント	deprecated and unmaintained と明記
GitHub リポジトリ	2026年1月21日にアーカイブ、読み取り専用
新規インストール推奨	Headlamp を検討
既存のインストール	即時停止ではなく、使用状況を把握した上で計画的に移行

非推奨化が直ちにすべてのインストールが動作を停止するという意味ではありません。既存のDashboard PodとServiceは引き続き実行できます。しかし、時間が経つにつれて、サポートされていない管理画面をクラスターAPIに接続し続ける負担が大きくなります。

特にDashboardは、以下のような機密性の高い機能を提供できます。

クラスターリソースの参照
YAMLの作成と修正
Podログの参照
Pod内部でのコマンド実行
Secretを含む構成リソースへのアクセス
Deploymentのスケーリングと再起動

メンテナンスが終了したUIを、高い権限を持つServiceAccountと共に公開し続けることは、良い運用上の選択ではありません。

なぜKubernetes Dashboardは限界に達したのか

Kubernetes Dashboardは、単一のクラスター内で実行されるシンプルなWeb UIとして始まりました。小規模な実習環境では十分でしたが、Kubernetesの運用方法が変化するにつれて、その限界が明らかになりました。

一度に一つのクラスターを見る構造

Dashboardは通常、クラスターごとに個別にインストールされます。開発・ステージング・運用クラスターが複数ある場合、それぞれのDashboard URLと認証トークンを個別に管理することになります。

クラスター数が増えるにつれて、以下の問題が発生します。

クラスターごとにDashboardのデプロイとアップグレードが必要
複数のURLとIngressポリシーの管理
ServiceAccountとRoleBindingの重複
ユーザーが現在どのクラスターを見ているか混乱
環境間のリソース比較が困難

Bearer Token中心の不便なログイン

Dashboardは主にServiceAccountのBearer Tokenを入力してログインする方式で使われていました。シンプルですが、組織環境ではトークンの発行・伝達・保管・回収が煩雑です。

利便性のために長期間有効なトークンやcluster-admin権限のアカウントを共有すると、セキュリティリスクが増大します。トークンがブラウザの履歴、メッセンジャー、ドキュメント、またはターミナル出力に残る可能性もあります。

拡張しにくい固定されたUI

現代的なKubernetesプラットフォームは、基本的なリソースだけを表示するだけでは不十分です。

Argo CDとFluxのデプロイ状態
Prometheusメトリクス
TrivyとKubescapeのセキュリティ結果
OpenCostのコスト情報
KubeVirt仮想マシン
組織固有のCRDと運用ワークフロー

Dashboardは、これらのツールを一つのユーザーエクスペリエンスに拡張することが困難でした。

Headlampとはどのようなプロジェクトか

Headlampは、使いやすく拡張可能なKubernetes Web UIです。現在、Kubernetes SIG UIに属する公式Kubernetesサブプロジェクトとして開発されています。

Headlampは二つの形式で実行できます。

実行方式	接続方法	適切な使用事例
デスクトップアプリ	ユーザーのkubeconfig	個人オペレーター、複数クラスター、迅速な導入
インクラスターWeb UI	ServiceAccountまたはOIDC	チーム共通UI、中央URL、組織認証連携

デスクトップアプリは、クラスター内にUIをデプロイする必要がありません。ユーザーの既存のkubeconfigに登録された複数のクラスターを一つのアプリで切り替えることができます。

Headlampで複数のKubernetesクラスターを切り替える公式画面

図：単一クラスター中心のDashboardからマルチクラスターHeadlampへの拡張の流れ · 出典：Kubernetes公式移行ドキュメント (CC BY 4.0)

インクラスター方式は、DashboardのようにKubernetesにHeadlampをデプロイし、ブラウザでアクセスします。チームに共通のURLを提供したり、OIDCログインを連携させたい場合に適しています。

DashboardとHeadlampの比較

項目	Kubernetes Dashboard	Headlamp
プロジェクトの状態	非推奨、リポジトリアーカイブ済み	活発に開発されているKubernetes SIG UIプロジェクト
デプロイ方式	インクラスター	デスクトップまたはインクラスター
マルチクラスター	クラスターごとに個別のアクセス	デスクトップでkubeconfigベースの切り替え
認証	主にServiceAccountトークン	kubeconfig、トークン、クライアント証明書、OIDC
権限制御	Kubernetes RBAC	Kubernetes RBAC
拡張性	制限的	プラグインサポート
アプリケーションの視点	リソース中心	ProjectsやMap Viewなど拡張された視点
エコシステム連携	制限的	Flux、Prometheus、Trivy、OpenCostなどのプラグイン

Headlampが独自の権限システムを作成するわけではありません。ユーザーが見ることができるリソースと実行可能な操作は、Kubernetes APIのRBACの結果に従います。

Headlamp Map Viewでワークロードとサービスの関係を視覚化した公式画面

図：Headlamp Map Viewがワークロードとサービスの関係を視覚化した様子 · 出典：Kubernetes公式移行ドキュメント (CC BY 4.0)

この点が重要です。

Headlampをインストールしたからといって権限が安全になるわけではなく、Headlampにどのような認証情報とRBAC権限を接続したかが安全性を決定します。

最も簡単な移行：Headlampデスクトップアプリ

個別のオペレーターやプラットフォームエンジニアが使用する環境であれば、デスクトップアプリが最も簡単です。

macOSではHomebrewでインストールできます。

brew install --cask headlamp

WindowsではWinGetを使用できます。

winget install headlamp

LinuxではFlatpakパッケージが提供されています。

flatpak install flathub io.kinvolk.Headlamp

Headlampデスクトップアプリは、デフォルトでユーザーのkubeconfigを読み込みます。複数のkubeconfigを使用する場合は、KUBECONFIG環境変数で指定できます。

KUBECONFIG=~/.kube/dev:~/.kube/staging:~/.kube/prod headlamp

デスクトップ方式の利点は以下の通りです。

クラスターに新しいWeb UIをデプロイする必要がない
Ingressと共通Serviceが不要
既存のkubeconfigとユーザー認証を再利用
複数のクラスターを一つの画面で切り替え
各ユーザーのKubernetes権限をそのまま適用

一方、ユーザーPCのkubeconfigのセキュリティとアプリのデプロイ・アップデートを管理する必要があります。共通の運用画面を提供したい目的には、インクラスター方式の方が適している場合があります。

チーム共通UI：Helmによるインクラスターインストール

Headlamp公式Helmリポジトリを追加します。

helm repo add headlamp https://kubernetes-sigs.github.io/headlamp/
helm repo update

別途Namespaceを作成し、Headlampをインストールします。

kubectl create namespace headlamp

helm upgrade --install headlamp headlamp/headlamp 
  --namespace headlamp

PodとServiceの状態を確認します。

kubectl get pods,svc -n headlamp

初めて機能を試す際は、外部に公開するよりもport-forwardを使用する方が安全です。

kubectl port-forward -n headlamp svc/headlamp 8080:80

ブラウザで次のアドレスにアクセスします。

http://127.0.0.1:8080

運用環境では、Helmのデフォルト値をそのまま公開せず、Ingress、TLS、認証、NetworkPolicy、リソース制限を組織の基準に合わせて設定する必要があります。

cluster-adminトークンを作成する前に考えるべきこと

Headlampの公式インストールドキュメントでは、ServiceAccountにcluster-adminを接続する迅速なテスト例が示されています。機能確認には便利ですが、運用環境の基本設計として使用すべきではありません。

以下の構成は強力な権限を持ちます。

kubectl create serviceaccount headlamp-admin -n headlamp

kubectl create clusterrolebinding headlamp-admin 
  --serviceaccount=headlamp:headlamp-admin 
  --clusterrole=cluster-admin

kubectl create token headlamp-admin -n headlamp

このトークンが露出すると、クラスター全体を制御できます。Dashboardで使用していたcluster-adminトークンを名前だけ変えてHeadlampに設定した場合、UIは置き換わりますが、セキュリティ上の問題はそのまま残ります。

運用環境では、以下の原則が必要です。

各個人は個別のIDを使用します。
可能な限りOIDCを通じて組織アカウントでログインします。
Namespaceと職務に合ったRole・ClusterRoleを定義します。
読み取り専用ユーザーと変更権限ユーザーを分離します。
Secretの参照とPod exec権限を別途検討します。
共有ServiceAccountトークンの使用を最小限に抑えます。
監査ログでユーザーごとの作業を追跡できるようにします。

読み取り専用権限から始める例

クラスター全体を参照できるが変更はできないアカウントが必要な場合は、Kubernetesのデフォルトview ClusterRoleを活用できます。

kubectl create serviceaccount headlamp-viewer -n headlamp

kubectl create clusterrolebinding headlamp-viewer 
  --serviceaccount=headlamp:headlamp-viewer 
  --clusterrole=view

kubectl create token headlamp-viewer -n headlamp

しかし、view権限もすべての組織にそのまま適しているわけではありません。特定のNamespaceのみを表示する必要がある場合は、ClusterRoleBindingの代わりにNamespace単位のRoleBindingを使用します。

kubectl create rolebinding headlamp-team-a-view 
  --namespace team-a 
  --clusterrole view 
  --serviceaccount headlamp:headlamp-viewer

実際の権限はデプロイ前にkubectl auth can-iで確認します。

kubectl auth can-i --list 
  --as system:serviceaccount:headlamp:headlamp-viewer

特定の高リスクな操作も別途確認します。

kubectl auth can-i get secrets 
  --all-namespaces 
  --as system:serviceaccount:headlamp:headlamp-viewer

kubectl auth can-i create pods/exec 
  --all-namespaces 
  --as system:serviceaccount:headlamp:headlamp-viewer

UIにボタンが表示されないことだけを確認するのではなく、Kubernetes APIが実際に操作を拒否するかどうかを検証する必要があります。

OIDCを連携させると何が良いのか

チームで共有するインクラスターHeadlampであれば、OIDC連携を検討する価値は大きいです。

OIDCを使用すると、以下のような運用モデルを構築できます。

사용자
  → 조직 Identity Provider
  → Headlamp
  → Kubernetes API
  → 사용자·그룹 기반 RBAC

利点は明確です。

共有トークンを渡す必要がない
退職や部署異動を中央アカウントで処理
ユーザーとグループをKubernetes RBACにマッピング
監査ログで個人のIDを区別
MFAと条件付きアクセスポリシーの活用が可能

OIDC設定では、Redirect URI、Client ID、Client Secretの保存方式とKubernetes API ServerのOIDC設定を合わせて調整する必要があります。HeadlampのURLが変更された場合、Redirect URIも更新する必要があります。

Headlampプラグインは利点であり、新たなサプライチェーンの境界でもある

Headlampの大きな差別化要因はプラグインです。基本的なKubernetesリソースだけでなく、組織が使用するツールをUIに統合できます。

公式ドキュメントとプロジェクト資料には、以下のようなエコシステム連携が紹介されています。

Flux
Prometheus
Trivy
Kubescape
OpenCost
KubeVirt
Backstage

プラグインは運用体験を大幅に改善しますが、信頼境界も広げます。

プラグインの出所とメンテナンス状況
要求されるKubernetes権限
フロントエンドからアクセスするデータ
外部APIとネットワーク通信
バージョン互換性と更新手順
パッケージの整合性とサプライチェーンセキュリティ

プラグインをインストールする前に、ソース、リリース署名、権限、ネットワーク動作を確認する必要があります。使用しないプラグインを無闇に追加しないことをお勧めします。

DashboardからHeadlampへの現実的な移行手順

新しいUIをインストールしたからといって、既存のDashboardをすぐに削除する必要はありません。一定期間並行して運用し、主要な機能と権限を比較する方が安全です。

ステップ1：現在のDashboard使用状況の調査

誰がDashboardを使用しているか
どのNamespaceとクラスターにアクセスしているか
ログ・exec・YAML修正のうち、どの機能を使用しているか
どのServiceAccountとRoleBindingが接続されているか
Ingressと外部アクセス経路があるか

ステップ2：Headlampの実行方式を選択

要件	推奨される開始点
オペレーター個人が複数のクラスターを管理	デスクトップアプリ
チーム共通のURLが必要	インクラスター
組織アカウントとMFA連携	インクラスター + OIDC
クラスターにUIを追加したくない	デスクトップアプリ
プラグインでプラットフォーム機能を統合	両方の方式を検討可能

ステップ3：最小権限での機能検証

リソースリストと詳細情報
ログとイベント
YAMLの参照・修正
Pod exec
Namespaceの切り替え
マルチクラスターの切り替え
カスタムリソースの表示
必要なプラグイン

各機能は、権限が許可されたユーザーと拒否されるべきユーザーの両方でテストします。

ステップ4：Headlampアクセス経路のセキュリティ

TLSが適用された別のホストを使用
OIDCまたは承認された認証方式を適用
公開インターネットへの露出を最小限に抑える
NetworkPolicyとファイアウォール制限
CSPとセキュリティヘッダーの確認
アクセス・変更作業の監査
Helm Chartとイメージバージョンの固定

ステップ5：Dashboardの削除

Headlampで主要な業務と権限検証を終えた後、既存のDashboardを削除します。

Helmでインストールした場合は、次のように削除できます。

helm uninstall kubernetes-dashboard 
  -n kubernetes-dashboard

残りのリソースを確認します。

kubectl get all,sa,role,rolebinding 
  -n kubernetes-dashboard

Dashboard専用のClusterRoleBindingも確認します。

kubectl get clusterrolebinding 
  -o custom-columns='NAME:.metadata.name,SERVICE_ACCOUNTS:.subjects[*].name' 
  | grep -i dashboard

ここで発見されたリソースをすべて自動削除してはなりません。他のツールが共有している権限であるかを確認した後、Dashboard専用のリソースのみを削除します。

Headlampがすべての状況の正解ではない

HeadlampはKubernetes公式ドキュメントが提案する自然な代替手段ですが、すべての運用要件を解決するプラットフォームではありません。

以下のような場合には、他のツールと組み合わせて使用する必要があります。

宣言的デプロイと変更履歴：Argo CD、Flux
メトリクスとアラート：Prometheus、Grafana
ログ検索：Loki、OpenSearch、Elasticsearch
コスト分析：OpenCost
セキュリティ状態管理：Trivy、Kubescapeなど
開発者セルフサービスポータル：Backstage

HeadlampはKubernetes APIを探索し、問題を調査するUIに近いものです。モニタリング、GitOps、コスト、セキュリティツールを代替すると考えると、その役割が過度に大きくなります。

移行チェックリスト

領域	確認項目
プロジェクトの状態	Dashboardが非推奨・アーカイブ状態であることを運用ドキュメントに反映
インストール方式	デスクトップとインクラスターの中から目的に合わせて選択
認証	共有トークンよりも個人IDとOIDCを優先
RBAC	cluster-adminのデフォルト使用禁止、最小権限の検証
ネットワーク	TLS、Ingress、NetworkPolicy、外部露出の点検
機能	ログ、イベント、YAML、exec、CRD、マルチクラスターのテスト
プラグイン	出所、権限、アップデート、サプライチェーンリスクの検討
削除	Dashboard専用のServiceAccountとBindingの整理
運用	Headlampのバージョン・イメージ・Chart更新手順の確立

結論：UIの置き換えよりもアクセス権限を再設計する機会

Kubernetes Dashboardの非推奨化は、単なる画面の置き換えのニュースではありません。メンテナンスされていない管理UIをクラスターAPIに接続し続けるべきかを判断する必要がある運用上のシグナルです。

Headlampは、デスクトップとインクラスター実行、マルチクラスター、OIDC、プラグイン拡張性を提供し、Dashboard以降のKubernetes UIとして適切な方向性を示しています。

ただし、移行の核心はHeadlampをインストールするコマンドではありません。

Dashboardで使っていたcluster-adminトークンをそのままHeadlampに移行するのではなく、ユーザーごとの認証と最小権限RBACを再設計する必要があります。

個別のオペレーターは、デスクトップアプリと既存のkubeconfigで小さく始めることができます。チーム共通のUIが必要な場合は、インクラスターデプロイメントとOIDCを検討します。主要な機能と権限を並行して検証した後、Dashboard専用のServiceAccount、RoleBinding、および外部アクセス経路まで整理すれば、移行を完了できます。