【入門編】 Kubernetes API Serverの監査ログによる特権昇格の検知 – インシデントレスポンス & フォレンジック（DFIR）防御ガイド

こんにちは！日々のインフラ運用や開発、本当にお疲れ様です。
皆さんは「Kubernetes（K8s）」という言葉を耳にしたことがありますか？コンテナ技術を束ねる現代のインフラの要ですが、「設定が複雑すぎて、どこから手をつければいいか分からない…」と悩む新人エンジニアの方や開発者の方も多いのではないでしょうか。

今回は、Kubernetesの心臓部である 「API Serverの監査ログ（Audit Log）」 を使って、こっそり行われる不正な「特権昇格（権限泥棒）」を見破る監視設計について、身近な防犯のたとえ話を交えながら、一歩ずつ優しく紐解いていきたいと思います。

難しいセキュリティ用語が出てきても置いてけぼりにしませんので、安心してくださいね。一緒に一つずつ学んでいきましょう！

—

1. 家の鍵に例えるKubernetesの「権限管理（RBAC）」

まず、Kubernetesの世界観を私たちの生活に置き換えて考えてみましょう。

皆さんのご自宅を想像してみてください。玄関の鍵はあなた（管理者）が持っていますよね。家族には合鍵を渡すかもしれませんが、ご近所さんに家のマスターキーを丸ごと渡したりはしないはずです。もし合鍵を勝手に複製されて、泥棒が侵入してきたら……想像するだけでもゾッとしますよね。

Kubernetesの世界でも同じです。

Kubernetes API Server：家全体の「玄関のドア」であり、すべての出入りを管理する管理人さん。
RBAC（Role-Based Access Control）：誰がどの部屋（リソース）に入っていいかを決める「鍵と身分証のルール」。
ServiceAccount（SA）：人間ではなく、Kubernetes上で動く「アプリケーション（お掃除ロボットや宅配ボックスなど）」に持たせた専用の身分証。

攻撃者は、この「お掃除ロボットの身分証（ServiceAccount）」を乗っ取ったり、自分たちの都合のいいように「玄関の鍵のルール（RBAC）」をこっそり書き換えたりして、管理者だけが使えるマスターキーを手に入れようとします。これが 「特権昇格」 という手口です。

—

2. 泥棒の足あとを見逃さない「監査ログ」の力

では、もし泥棒がこっそり合鍵を作ったり、マスターキーを持ち出そうとしたりしたとき、どうやって気づけばよいでしょうか？

家の中に防犯カメラや、誰がいつどこを通ったかを記録する「入退室管理ノート」があれば安心ですよね。Kubernetesにおけるそのノートが 「監査ログ（Audit Log）」 です。

API Serverの監査ログは、誰が（User）、いつ、どのリソースに対して、何をしたのか（Verb）のすべてを細かく記録してくれます。このログをリアルタイムで監視できれば、泥棒が侵入した瞬間に「おや、このお掃除ロボット、マスターキーの保管庫を開けようとしているぞ！」と検知できるのです。

—

3. 監視すべき「危ない動き」のパターン

実際のインシデント現場（セキュリティの最前線）で、私たちが特に目を光らせている「危ない動き」は主に次の2つです。

1. RBAC設定の不審な変更（自分に偉い権限をあげる行為）

攻撃者が、自分たちが持っている平社員用の権限を、社長権限（ClusterRoleBinding など）にこっそり書き換える操作です。

2. 不審なServiceAccountによるシークレット（機密情報）の取得

データベースのパスワードや外部サービスのAPIキーが入った「シークレット（Secret）」という宝箱を、本来アクセスするはずのないアプリがこっそり盗み見る操作です。

—

4. 実践！監査ログの監視設計と検知ルール

ここからは、実際にKubernetesの環境でどのような設定を行い、どうやってログを監視すればよいのかを具体的なコードを交えて見ていきましょう。

ステップ1：API Serverで監査ログを有効にする

まずは、API Serverに「すべての出入りをノートにしっかり記録してね」と指示を出します。設定ファイル（通常は /etc/kubernetes/manifests/kube-apiserver.yaml など）に以下のパラメーターを追加します。

apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
  - name: kube-apiserver
    image: k8s.gcr.io/kube-apiserver:v1.28.0
    command:
    - kube-apiserver
    # 以下の監査ログ関連の引数を追加して、詳細な記録を残すようにします
    - --audit-policy-file=/etc/kubernetes/audit/audit-policy.yaml
    - --audit-log-path=/var/log/kubernetes/audit.log
    - --audit-log-maxbackup=10
    - --audit-log-maxsize=100

ステップ2：どんなログを保存するか決めるポリシーを書く

すべての操作を記録するとログの容量がパンクしてしまうため、「重要な動きだけをしっかり残す」ためのポリシーファイル（audit-policy.yaml）を作成します。

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
  # 1. 権限設定（RBAC）の変更は、一番詳しいレベル（RequestResponse）で記録する
  - level: RequestResponse
    resources:
    - group: rbac.authorization.k8s.io
      resources: ["clusterroles", "clusterrolebindings", "roles", "rolebindings"]

  # 2. シークレット（機密情報）へのアクセスも厳重に記録する
  - level: Metadata
    resources:
    - group: ""
      resources: ["secrets"]

ステップ3：不審な操作を検知するルール（SIEMやログ分析クエリの例）

集まった監査ログの中から、特権昇格の兆候を検知するための検索クエリのイメージです。今回は一般的なログ分析ツールで使えるような論理を表現しています。

{
  "query": "verb: (create OR update OR patch) AND (objectRef.resource: clusterrolebindings OR objectRef.resource: rolebindings)",
  "description": "権限の割り当て（RBAC）を変更・作成する操作を検知します。予期せぬユーザーやServiceAccountが実行していないか確認してください。",
  "severity": "HIGH"
}

「あれ？この開発用のServiceAccountが、なぜか管理者権限のバインディング（clusterrolebindings）を作っているぞ？」――これを見つけたら、即座に該当のコンテナを停止し、パスワードやトークンの無効化（インシデントレスポンスの初動）に移行します。

—

5. まとめ：日々の小さな積み重ねがセキュリティを守る

いかがでしたでしょうか？
「Kubernetesの監査ログ」と言われると難しく聞こえますが、要するに 「家の鍵のルールや重要書類の持ち出し履歴を記録し、不審な動きがないか見張る仕組み」 のことです。

セキュリティの対策に「これで完璧」というゴールはありません。しかし、今回ご紹介したような監査ログの基本を押さえておくだけで、万が一の侵入があった際にも「すぐに気づいて被害を最小限に食い止める」ことができるようになります。

焦らず、一歩ずつ、ご自身の環境のログ設定から確認を始めてみてくださいね。あなたのインフラストラクチャの安全を、心から応援しています！