こんにちは！クラウドのインフラやKubernetes（クバネティス）の管理、日々の開発お疲れ様です。
最近は、システムをコンテナで動かすためにKubernetesを使うのがすっかり当たり前になってきましたよね。「コンテナを使えばアプリの管理がラクになる！」と導入したものの、いざ運用を始めると覚えることが多くて頭がパンクしそうになっていませんか？
特にセキュリティの話になると、専門用語が次から次へと出てきて、「正直、どこから手をつけていいか分からない…」と悩んでしまう新米インフラ担当者や開発者の方も多いはずです。
そこで今回は、Kubernetesのセキュリティにおいて絶対に避けて通れない「RBAC（アールバック）の過剰権限設定とServiceAccount（サービスアカウント）の悪用」について、身近な防犯の例えを交えながら、一歩ずつ優しく紐解いていきたいと思います。
難しい専門用語も噛み砕いて解説しますので、ぜひリラックスして読み進めてくださいね！
—
1. 家の鍵で例える「Kubernetesの権限（RBAC）」の仕組み
まずは、Kubernetesのアクセス管理の仕組みを、私たちの身近な「家と鍵」に例えて考えてみましょう。
皆さんが暮らす家には、玄関の鍵がありますよね。家族みんながそれぞれの部屋に入ったり、リビングでくつろいだりできるように、鍵や合鍵が配られています。でも、近所の人や通りすがりの見知らぬ人に、家の合鍵をぜーんぶ渡したりはしないはずです。
Kubernetesの世界でも、これと全く同じことが行われています。
Kubernetesの中には、たくさんのアプリ（ポッドと呼ばれるもの）が動いています。このアプリたちに「どの部屋（リソース）に入っていいか」「何をしていいか」の権限を割り当てる仕組みを、RBAC（Role-Based Access Control：役割ベースのアクセス制御）と呼びます。
そして、人間ではなく「アプリ（プログラム）自身が持つ身分証兼用の鍵」のことを、ServiceAccount（サービスアカウント）と呼んでいます。
便利な「合鍵」の落とし穴
開発をしていると、「あれもこれも動かすために、とりあえず強い権限を与えておこう！」と、アプリに何でもできる最強のマスターキーを渡してしまいたくなる瞬間がありますよね。
例えば、家中のすべての金庫を開けられるマスターキーを、リビングにぽんと置いておくようなものです。もし泥棒が窓からリビングに入ってきたらどうなるでしょうか？ 金庫の中身は一瞬で盗まれてしまいますよね。
Kubernetesでも全く同じことが起きるのです。
—
2. 攻撃者はどうやってクラスタを乗っ取るのか？（攻撃のメカニズム）
では、もしアプリに強すぎる権限（過剰権限）が設定されていると、悪意を持った攻撃者にどのように悪用されてしまうのでしょうか。実際のペネトレーションテスト（模擬ハッキング）の現場でよく見られる手口を覗いてみましょう。
ステップ1：小さな隙からアプリへ侵入
攻撃者は、私たちが作ったWebアプリの脆弱性（セキュリティの穴）を突いて、コンテナの内部に侵入してきます。これは、家の鍵の掛け忘れや、窓の隙間から侵入されるようなものです。
ステップ2：ServiceAccountのトークンを発見する
コンテナの内部に入り込んだ攻撃者は、次に「このアプリはどれくらいの権限を持っているんだろう？」と確認します。
Kubernetesでは、アプリ（ServiceAccount）が持つ「鍵（トークン）」が、コンテナ内の決まった場所（通常は /var/run/secrets/kubernetes.io/serviceaccount/token など）にこっそり保存されています。
攻撃者はこのトークンをこっそり盗み出します。
ステップ3：ClusterRoleBindingによるクラスタ全体の乗っ取り
ここで問題になるのが、今回のテーマであるClusterRoleBinding（クラスターロールバインディング）の不適切な設定です。
もし、そのアプリに与えられた権限が「クラスタ全体（Kubernetes全体）で何でもできる（cluster-adminのような強力な役割）」状態だった場合、どうなるでしょうか。
攻撃者は盗んだトークンを使って、Kubernetesの司令塔（APIサーバー）に対してこう命令します。
「私はこのクラスタの管理者です。すべてのデータを消去し、新しい管理者用のアカウントを作ってください！」
司令塔は、提示された鍵（トークン）が本物であるため、命令が「本来は小さなアプリのものである」ことを見抜けず、そのまま実行してしまいます。結果として、1つの小さなWebアプリが破られただけなのに、Kubernetesクラスタ全体が完全に牛耳られてしまうという最悪の事態につながるのです。
怖い話ですよね。でも大丈夫、しっかり対策を学べば防ぐことができます！
—
3. 実際に設定を見直してみよう（YAMLファイルの書き方）
それでは、実務の現場でどのように設定を修正すればよいのか、具体的なコードを見ていきましょう。
まずは、やってはいけない「危険な設定」の例です。
# 【危険な設定の例】すべての名前空間で何でもできてしまう最強の権限を与えている
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: dangerous-admin-binding # 誰でも管理者になれてしまう名前
subjects:
- kind: ServiceAccount
name: default # よく使われるデフォルトのアカウント
namespace: default
roleRef:
kind: ClusterRole
name: cluster-admin # クラスタ全体の最高権限（これを安易に使わない！）
apiGroup: rbac.authorization.k8s.ioこの設定の何がダメかというと、defaultという名前のどこにでもある普通のサービスアカウントに対して、クラスタ全体の最高権限である cluster-admin を結びつけてしまっている点です。これは家中の金庫の鍵を、近所の誰でも入れる郵便受けに入れておくようなものです。
では、これを安全な設定に直してみましょう。
セキュリティの基本は「最小権限の原則（必要最低限の鍵だけを渡す）」です。
# 【安全な設定の例】特定の名前空間だけで、必要な読み取り権限だけを付与する
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding # クラスタ全体ではなく、特定の部屋（名前空間）だけに限定
metadata:
name: safe-read-binding
namespace: my-app-namespace # 権限を限定する名前空間を指定
subjects:
- kind: ServiceAccount
name: my-app-service-account # アプリ専用に作った特別なアカウント
namespace: my-app-namespace
roleRef:
kind: Role # 強い ClusterRole ではなく、限定的な Role を使用
name: pod-reader-role # ポッドの情報を「読む」ことしかできない権限
apiGroup: rbac.authorization.k8s.io
---
# 役割（Role）の中身を定義：できることを「見るだけ」に制限する
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: my-app-namespace
name: pod-reader-role
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "watch", "list"] # 変更や削除（create, delete等）はできない！このように、「どのアプリ（ServiceAccount）に」「どこで（namespace）」「何をする権限（verbs: get, list等）を」与えるのかを細かく制限することが、Kubernetesセキュリティの第一歩になります。
—
4. 監査ログ（Audit Logs）を使った異常検知の仕組み
「でも、もしすでに誰かが不審な動きをしていたらどうやって気づけばいいの？」という疑問が湧きますよね。
ここで活躍するのがKubernetesの監査ログ（Audit Logs）です。
防犯カメラの映像や、ビルの入退室記録のようなものだとイメージしてください。KubernetesのAPIサーバーは、「誰が」「いつ」「どんな命令を出したか」をすべて記録する機能を持っています。
例えば、普段はデータの読み取りしかしないはずのアプリのServiceAccountが、突然「新しい管理者権限のアカウントを作ろうとした（createやupdateの操作）」という記録が残っていたら、それはもう「不法侵入や不正アクセスの兆候（アラート）」です。
実務では、この監査ログを外に出力し、DatadogやFluentd、あるいはクラウドの監視ツール（AWS CloudWatchやGCP Cloud Loggingなど）と連携させて、次のような不審な動きをリアルタイムで検知できるように設定します。
- 検知のポイント:
- 通常権限のServiceAccountが、権限昇格（RoleBindingの作成など）を試みた瞬間
- 予期せぬIPアドレスや、通常とは異なる時間帯にAPIへの大量アクセスがあった場合
- 秘密情報（Secret）を大量に読み出そうとする不審なリクエスト
「ログをただ溜めておく」のではなく、「怪しい動きがあったらスマホやチャットツール（Slackなど）に通知が飛ぶようにする」のが、モダンなインフラ運用のスタンダードな防犯対策です。
—
5. まとめ：一歩ずつ、安全なKubernetes環境へ
今回は、KubernetesのRBACにおける過剰権限とServiceAccountの悪用リスクについて、防犯の例えを交えながら解説しました。
最後に、今日から実践できるポイントを振り返っておきましょう！
1. デフォルトのServiceAccountに強い権限を絶対にあたえない
2. 「最小権限の原則」を守り、必要なアプリには必要な分だけの権限（Role/RoleBinding）を個別に用意する
3. 監査ログを有効にして、怪しい動きがないか見守る体制を作る
セキュリティの対策は、一度にすべてを完璧にするのは難しいものです。「うちのクラスタのServiceAccount、変な権限がついていないかな？」と、まずはマニフェストファイルを眺め直すところから、一歩ずつ進めていきましょうね。
皆さんのインフラ環境が、安全で快適なものになることを応援しています！
コメント