【入門編】 Kubernetesのダッシュボードと外部公開のセキュリティリスク – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

こんにちは、セキュリティバイブルの主筆ライターです。日々、サイバー空間の最前線で「守り」の設計図を引いています。

今日は、Kubernetes（K8s）を使い始めたばかりの皆さんや、インフラの運用を任された新人担当者の方に向けて、非常に重要、かつ「ついうっかり」で大事故になりやすい「Kubernetes Dashboard（ダッシュボード）」の守り方についてお話しします。

Kubernetesは、たくさんのコンテナ（アプリの小部屋）を管理してくれる巨大なマンションのようなものです。その管理をグラフィカルに、マウス操作で行える「ダッシュボード」は非常に便利ですよね。しかし、この便利さは諸刃の剣。一歩間違えると、「マンションの全室の合鍵を、表札のすぐ横にぶら下げておく」くらい危険な状態になりかねません。

一歩ずつ、泥棒（攻撃者）に狙われないための「家の守り方」を学んでいきましょう！

—

1. なぜ「ダッシュボード」が狙われるのか？

泥棒の気持ちになって考えてみてください。高い塀を乗り越えて窓を割るよりも、「管理室のタッチパネルが外から丸見えで、しかもログイン不要で操作できる」状態を見つけたら、これほどラッキーなことはありませんよね。

過去には、有名企業がKubernetes Dashboardをインターネットに「そのまま」公開していたために、攻撃者にインフラを乗っ取られ、勝手に仮想通貨のマイニング（採掘）に使われて莫大な電気代と計算リソースを盗まれるという事件（Teslaの事例などが有名です）も起きています。

過去の弱点（CVE）を振り返る

かつてのダッシュボードには、特定の条件下で認証をスキップできてしまう脆弱性（例：CVE-2018-18264 など）が存在していました。これによって、本来は見ることができないはずの「機密情報（パスワードやAPIトークン）」が盗み見られるリスクがあったのです。

現在の最新バージョンでは修正されていますが、「そもそも外から見える場所に置かない」というのがセキュリティの鉄則です。

—

2. 最初の防衛線：インターネットに公開しない

一番の対策はシンプルです。「ダッシュボードの入り口を、公道（インターネット）に面した場所に作らない」ことです。

通常、ダッシュボードを起動しても、それはクラスターという「マンションの敷地内」だけで動いています。これを Type: LoadBalancer などに設定して、誰でもアクセスできるURLを発行してはいけません。

推奨されるアクセス方法：kubectl port-forward

開発者が自分のPCから安全に確認したいときは、専用の「秘密のトンネル」を一時的に掘る方法を使いましょう。

# ダッシュボードへのポートフォワード（秘密のトンネル）を作成するコマンド
# これを実行している間だけ、自分のPCの http://localhost:8001 からアクセスできます
kubectl port-forward -n kubernetes-dashboard service/kubernetes-dashboard 8001:443

この方法なら、トンネルを通れるのは「あなたのPC」と「クラスター」の間だけ。外の泥棒からは、入り口すら見えません。

—

3. どうしても外部からアクセスしたい場合の「二重の鍵」

「運用の都合上、どうしてもVPN越しや特定のネットワークからブラウザでアクセスしたい」という場面もあるでしょう。その場合は、Ingress（インgress）という「マンションの正門」に、強力な鍵をかけます。

ここでは、Nginx Ingress Controller を使って、特定のIPアドレスからしか入れないようにする（門前払いする）設定例を見てみましょう。

Ingressによるアクセス制御の例

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: kubernetes-dashboard-ingress
  namespace: kubernetes-dashboard
  annotations:
    # 1. SSL/TLSで通信を暗号化（盗聴防止）
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
    
    # 2. IP制限：会社や自宅の特定のIPアドレスからのみ許可する（重要！）
    # 「許可された人」以外は、入り口にたどり着くことすらできません
    nginx.ingress.kubernetes.io/whitelist-source-range: "1.2.3.4/32"

    # 3. 追加の認証（Basic認証など）を設定することも可能です
    nginx.ingress.kubernetes.io/auth-type: basic
    nginx.ingress.kubernetes.io/auth-secret: dash-auth-secret
spec:
  rules:
  - host: k8s-dash.example.com # あなた専用の管理ドメイン
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: kubernetes-dashboard
            port:
              number: 443

このように、「IPアドレス制限」と「認証」を組み合わせることで、万が一ダッシュボード自体に未知の脆弱性が見つかっても、攻撃者がそこに到達することを防げます。

—

4. RBAC（権限管理）で「万が一」の被害を最小限に

もし、ダッシュボードにログインできたとしても、その人が「何でもできる王様（管理者権限）」である必要はありませんよね。

Kubernetesには RBAC（Role-Based Access Control） という仕組みがあります。これは「この鍵を持っている人は、1階のロビーだけ見てもいいけど、地下の金庫室は開けられないよ」というルール決めです。

危険な設定（絶対に避けてください！）

かつてよく見られた「とりあえず動かしたいから」という理由での危険な設定がこちらです。

# ⚠️ これは非常に危険な「ダメな例」です！
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: dashboard-admin
subjects:
- kind: ServiceAccount
  name: kubernetes-dashboard
  namespace: kubernetes-dashboard
roleRef:
  kind: ClusterRole
  name: cluster-admin # 誰でも「全権限」を持ててしまう設定
  apiGroup: rbac.authorization.k8s.io

この設定をしてしまうと、ダッシュボードのURLがバレた瞬間に、クラスター内のすべてのデータを消去したり、新しい悪意のあるコンテナを立ち上げたりし放題になります。

対策： 必要な権限だけを絞った Role を作成し、それを割り当てる「最小権限の原則」を徹底しましょう。

—

5. まとめ：安全な運用のためのチェックリスト

最後に、今日学んだことを整理しましょう。

1. 原則非公開： ダッシュボードをインターネット（0.0.0.0）に晒さない。
2. トンネルを使う： kubectl port-forward を活用して、必要な時だけアクセスする。
3. 正門を固める： どうしても公開が必要なら、Ingressで「IP制限」と「TLS暗号化」を必須にする。
4. 権限を絞る： ダッシュボード用のサービスアカウントに cluster-admin（全権）を与えない。
5. VPNの活用： 外部公開するのではなく、社内LANやVPN経由でしかアクセスできない閉じたネットワーク内に配置する。

セキュリティは「これさえやれば100点」というものではなく、いくつもの小さな鍵を重ねていく作業です。一見面倒に感じるかもしれませんが、その「一手間」が、あなたの大切なシステムとデータを守る最強の盾になります。

「これ、うちの設定はどうなってるかな？」と気になった方は、ぜひ一度設定ファイルを見直してみてくださいね。一歩ずつ、安全なインフラを一緒に築いていきましょう！