誰も教えてくれない「Kubernetes API Server 監査ログ」の真実：監視なき要塞はただの箱だ
現場のエンジニア諸君。Kubernetes（K8s）の構築、お疲れ様。マニフェストを書いてデプロイして、Serviceを公開して……それで「運用完了」だと思っているなら、今すぐ考えを改めてほしい。
君たちが必死に守っているそのクラスタ、実は「誰が、いつ、どの権限で、何をしたか」を追跡できていないのではないか？
攻撃者は、アプリケーションの脆弱性よりも先に、設定が甘いAPI Serverを狙う。一度でもkube-apiserverの認証をすり抜けられれば、クラスタ内の全Podの機密情報、シークレット、そしてノードへのフルアクセス権を掌握される。これは「防御」ではなく「丸裸」の状態だ。
今日は、数々のインシデント現場で見てきた「なぜ監査ログが必要なのか」という本質と、明日から使える「実戦的な監査ポリシー」の書き方を伝授する。
—
1. なぜ「監査ログ」が攻撃者の最大の障壁になるのか
攻撃者は、クラスタに侵入した際、必ず「権限の列挙（Enumeration）」を行う。kubectl get pods や kubectl get secrets を連発し、どこに何があるかを探るのだ。
もし君たちが監査ログを取っていなければ、彼らは痕跡を残さずに「管理者権限」を奪い、バックドアを作成し、クラスター全体をボットネット化して去っていく。後から残るのは、AWSやGCPから突きつけられた莫大なインフラ請求書と、顧客情報の流出という悪夢だけだ。
監査ログは、攻撃者が「やりたい放題」するための「猶予時間」を奪う唯一の手段だ。 誰が怪しい動きをしているか、ログをリアルタイムで検知（モニタリング）できていれば、侵害が深刻化する前にAPIを無効化できる。
—
2. 実戦的：Kubernetes監査ポリシーの設定
監査ログを有効にするには、まずポリシーファイル（YAML）を定義し、API Serverに読み込ませる必要がある。デフォルトの「全て記録」はログが膨大になりすぎて破綻する。「必要なものだけを、深く記録する」のがプロの流儀だ。
以下は、実務でそのまま使える、攻撃者の挙動を確実に捉えるポリシー設定だ。
# audit-policy.yaml
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
# 1. センシティブなリソースへの変更は確実に記録（RequestとResponseのメタデータ）
- level: RequestResponse
resources:
- group: ""
resources: ["secrets", "configmaps"]
- group: "rbac.authorization.k8s.io"
resources: ["rolebindings", "clusterrolebindings"]
# 2. 権限変更（Auth）の試行を記録
- level: Request
verbs: ["create", "update", "patch", "delete"]
users: ["system:serviceaccount:default:risky-app"]
# 3. 読み取り専用操作は最低限の記録（ログの肥大化を防ぐ）
- level: Metadata
resources:
- group: ""
resources: ["pods", "services"]
verbs: ["get", "list", "watch"]これを、API Serverの起動オプション（--audit-policy-file）で指定する。この設定により、誰かが「Secretsを奪おうとした」瞬間、ログにはそのリクエスト内容が詳細に残る。
—
3. 「異常なAPI呼び出し」を検知するパターン
ログをファイルに書き出すだけでは意味がない。SIEM（Splunk, Datadog, CloudWatch Logsなど）に飛ばし、以下のパターンにアラートを設定しろ。
- 匿名ユーザー（system:anonymous）によるアクセス:
user.username: "system:anonymous" が発生した場合は、即座に「kubeconfigの漏洩」や「認証設定のミス」を疑え。
- 短時間での大量のList操作:
特定のServiceAccountが数秒間に何百もの list pods を実行している場合、それはクラスタの列挙攻撃（偵察行為）だ。
- 不自然な権限昇格の試行:
rolebindings や clusterrolebindings に対する create アクション。特に深夜帯であれば、内部犯行か外部からの侵入の可能性が極めて高い。
—
4. 運用エンジニアへのアドバイス
最後に、泥臭い教訓を一つ。「ログは改ざんされる」という前提を持て。
もし君たちのクラスタが乗っ取られたら、攻撃者はまず「証拠隠滅」のためにログを消しに来る。だからこそ、監査ログは「ローカルのノード」に保存してはいけない。必ず外部のログ管理サーバー、あるいはマネージドの監視サービス（AWS CloudWatch, GCP Cloud Logging等）へリアルタイムでストリーミングしてくれ。
実践の心得：
1. ポリシーは「最小権限」ならぬ「最小記録」で: 無駄なログは監視コストを跳ね上げ、本当に見るべき異常を見逃させる。
2. アラートを磨け: 「エラー」ではなく「異常な振る舞い」に反応するようにチューニングする。
3. 定期的な演習: たまに自分で kubectl でわざと怪しい操作をして、ログが通知されるかテストしろ。それができない監視はただのお守りだ。
セキュリティは「設定して終わり」の静的なゴールではない。攻撃者との終わりのない追跡劇だ。今日のこの設定が、君たちのクラスタを次なるインシデントから救うことを祈っている。
質問があれば、いつでも現場の知恵を共有する。健闘を祈る。
コメント