[{"data":1,"prerenderedAt":344},["ShallowReactive",2],{"blog-ja-k3s-ai-agent-audit-log-traceability-gap":3,"blog-related-ja-k3s-ai-agent-audit-log-traceability-gap":294,"blog-ja-k3s-ai-agent-audit-log-traceability-gap-alt":282},{"id":4,"title":5,"author":6,"body":7,"date":276,"description":277,"extension":278,"image":279,"locale":280,"meta":281,"navigation":282,"path":283,"seo":284,"stem":285,"tags":286,"__hash__":293},"blog\u002Fblog\u002Fja\u002Fk3s-ai-agent-audit-log-traceability-gap.md","AIエージェントがKubernetes APIを叩いた後、何をしたのか追えなかった。Audit Logの設定に空いていた穴","Kubo Team",{"type":8,"value":9,"toc":266},"minimark",[10,15,23,26,37,46,50,56,63,92,95,112,116,122,125,134,137,155,158,162,168,171,182,193,199,208,212,218,221,235,244,247,250,253],[11,12,14],"h2",{"id":13},"_1-何が起きたか-aiエージェントが何をしたのかaudit-logから再現できなかった","1. 何が起きたか — AIエージェントが何をしたのか、Audit Logから再現できなかった",[16,17,18],"p",{},[19,20],"img",{"alt":21,"src":22},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-ai-agent-audit-log-traceability-gap\u002Fsection01.webp",[16,24,25],{},"社内でAIエージェントをKubernetes（K3s）上のPodとして動かし始めた直後のことだ。エージェントがクラスタ内のリソースに対して何らかの操作をした形跡があり、意図しない設定変更が起きていないかを確認する必要が出た。",[16,27,28,29,36],{},"まず見るべき場所は決まっている。kube-apiserverのAudit Logだ。",[30,31,35],"a",{"href":32,"rel":33},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Ftasks\u002Fdebug\u002Fdebug-cluster\u002Faudit\u002F",[34],"nofollow","Kubernetesの公式ドキュメント","によれば、Audit Logはクラスタへのすべてのリクエストを時系列で記録する仕組みで、「誰が」「いつ」「何に対して」操作したかを追跡するための一次情報のはずだった。",[16,38,39,40,45],{},"ところが実際にログを開いてみると、記録されていたのは「あるService Accountが、あるタイミングでAPIを呼んだ」という事実だけだった。そのAIエージェントが何を目的に、どんな一連の判断をしてその操作に至ったのかは、どこにも残っていなかった。",[30,41,44],{"href":42,"rel":43},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fcaptain-ai\u002F",[34],"Captain.AI","のようにAIエージェントを\"動かす基盤\"には、こうした追跡可能性まで含めた運用設計が要るのだと、このとき初めて気づいた。",[11,47,49],{"id":48},"_2-原因-audit-policyの既定設定ではリクエストの中身が記録されない","2. 原因① — Audit Policyの既定設定ではリクエストの中身が記録されない",[16,51,52],{},[19,53],{"alt":54,"src":55},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-ai-agent-audit-log-traceability-gap\u002Fsection02.webp",[16,57,58,59,62],{},"調べていくと、原因の一つはAudit Policyの設定そのものにあった。",[30,60,35],{"href":32,"rel":61},[34],"では、Audit Logの記録レベルを4段階で定義している。",[64,65,66,74,80,86],"ul",{},[67,68,69,73],"li",{},[70,71,72],"strong",{},"None",": そのルールに一致するイベントを記録しない",[67,75,76,79],{},[70,77,78],{},"Metadata",": リクエストしたユーザー・タイムスタンプ・リソース・verbなどのメタデータのみを記録し、リクエスト本文やレスポンス本文は記録しない",[67,81,82,85],{},[70,83,84],{},"Request",": メタデータに加えてリクエスト本文も記録するが、レスポンス本文は記録しない",[67,87,88,91],{},[70,89,90],{},"RequestResponse",": メタデータ・リクエスト本文・レスポンス本文のすべてを記録する",[16,93,94],{},"多くのクラスタでは、ログ量とストレージコストを抑えるために既定でMetadataレベルに寄せた設定になっている。この場合、「AIエージェントがPodのSpecを更新するAPIを呼んだ」という事実は残るが、「どのフィールドをどんな値に変更しようとしたか」というリクエストの中身は記録されない。人間のオペレーターが手動でコマンドを打つ運用であれば作業ログと突き合わせれば補完できるが、AIエージェントは自律的に次々とAPIを呼ぶため、この「中身の欠落」がそのまま調査の行き詰まりに直結する。",[16,96,97,102,103,107,108,111],{},[30,98,101],{"href":99,"rel":100},"https:\u002F\u002Franchermanager.docs.rancher.com\u002Fhow-to-guides\u002Fadvanced-user-guides\u002Fenable-api-audit-log-in-downstream-clusters",[34],"K3s\u002FRKE2をRancherで管理する場合の公式手順","では、",[104,105,106],"code",{},"machineSelectorConfig","経由でコントロールプレーンノードにのみAudit Policyを適用し、",[104,109,110],{},"level: RequestResponse","まで引き上げる設定例が示されている。つまり「K3sだから記録できない」わけではなく、既定値のままでは不十分なことがほとんど、というだけだ。",[11,113,115],{"id":114},"_3-原因-共有serviceaccount共有トークンではどのエージェントかが区別できない","3. 原因② — 共有ServiceAccount・共有トークンでは「どのエージェントか」が区別できない",[16,117,118],{},[19,119],{"alt":120,"src":121},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-ai-agent-audit-log-traceability-gap\u002Fsection03.webp",[16,123,124],{},"もう一つの原因は、認証の設計にあった。複数のエージェントタスクを同じService Accountや使い回しのトークンで動かしていたため、Audit Log上では全員が同じ「名前」として記録されていた。これではトレーサビリティ（事後に行動を追跡できること）は最初から成立しない。",[16,126,127,128,133],{},"この問題は本ブログに限った話ではない。",[30,129,132],{"href":130,"rel":131},"https:\u002F\u002Fwww.qovery.com\u002Fblog\u002Fai-agents-kubernetes-audit-trails-policy-guardrails",[34],"Qoveryの分析記事","は、共有されたkubeconfigや使い回しのCIトークンでエージェントを動かすと、Audit Logには固定の識別子しか残らず、「一度書き込まれた監査イベントに、後から身元を遡って割り当てることはできない」と指摘している。半年後に「あの変更は誰が・何のために行ったのか」と聞かれても、答えようがない状態になる。",[16,135,136],{},"同記事は、監査可能なエージェントの行動には最低限次の5項目が必要だとしている。",[138,139,140,143,146,149,152],"ol",{},[67,141,142],{},"行為者の識別情報",[67,144,145],{},"タイムスタンプ",[67,147,148],{},"実際のリクエストとレスポンスの内容",[67,150,151],{},"承認した人間、または自動承認したポリシー",[67,153,154],{},"結果として生じたリソースの状態",[16,156,157],{},"そしてこれらを「エージェントのワークロード自身が触れられない、クラスタ外のappend-onlyストレージ」に保存すべきだとしている。Audit Logの設定を直すだけでは足りず、認証の設計そのものを見直す必要がある、ということだ。",[11,159,161],{"id":160},"_4-対処-エージェント単位の識別子とaudit-policyの段階的強化","4. 対処 — エージェント単位の識別子と、Audit Policyの段階的強化",[16,163,164],{},[19,165],{"alt":166,"src":167},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-ai-agent-audit-log-traceability-gap\u002Fsection04.webp",[16,169,170],{},"実際に行った対処は3つだ。",[16,172,173,176,177,181],{},[70,174,175],{},"第一に、エージェントごとにService Accountを分ける。"," ",[30,178,35],{"href":179,"rel":180},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Fconcepts\u002Fsecurity\u002Fservice-accounts\u002F",[34],"にあるとおり、Kubernetes v1.22以降はTokenRequest APIを使った短命・自動ローテーションのトークンが既定になっている。これをエージェントの機能単位で分割すれば、Audit Log上でも「どのエージェントが」を区別できるようになり、トレーサビリティが初めて技術的に担保される。",[16,183,184,176,187,192],{},[70,185,186],{},"第二に、権限はnamespace-scopedなRoleに絞る。",[30,188,191],{"href":189,"rel":190},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Freference\u002Faccess-authn-authz\u002Frbac\u002F",[34],"RBACの公式ドキュメント","が示すとおり、ClusterRoleはクラスタ全体に効くため、1つのエージェントの誤動作が全namespaceに波及しうる。RoleBindingで対象namespaceを明示的に絞ることで、被害範囲そのものを小さくできる。",[16,194,195,198],{},[70,196,197],{},"第三に、操作系のAPIだけAudit Policyのレベルを引き上げる。"," すべてのリクエストをRequestResponseレベルで記録するとログ量が膨らみすぎるため、Secretsの操作やDeployment\u002FStatefulSetの変更など「AIエージェントに実行させたくない操作」に絞ってレベルを上げるルールを追加した。",[16,200,201,202,207],{},"こうした権限設計とログ設計を自前で一から組み上げるのではなく、最初から操作が可視化される基盤を使うという選択肢もある。",[30,203,206],{"href":204,"rel":205},"https:\u002F\u002Fkubo.hexabase.io\u002F",[34],"Kubo","のCaptain UIは、クラスタ内の操作をブラックボックスにしないことを設計の軸に置いており、Audit Policyの試行錯誤そのものを減らす方向で役に立つ。",[11,209,211],{"id":210},"_5-それでも塞ぎきれない穴-インフラ層とアプリ層両方の可観測性が要る","5. それでも塞ぎきれない穴 — インフラ層とアプリ層、両方の可観測性が要る",[16,213,214],{},[19,215],{"alt":216,"src":217},"section05","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-ai-agent-audit-log-traceability-gap\u002Fsection05.webp",[16,219,220],{},"ここまでやっても、まだ塞ぎきれない穴が残る。Audit Logはあくまで「kube-apiserverへのリクエストが許可されたか」という、インフラ層の記録でしかない。エージェントが外部のLLMに問い合わせて、その回答をもとにどのツールを呼び出すと判断したか、という意思決定のプロセスそのものは、Kubernetesの外側で起きている。",[16,222,223,228,229,234],{},[30,224,227],{"href":225,"rel":226},"https:\u002F\u002Fwww.cncf.io\u002Fblog\u002F2025\u002F08\u002F19\u002Fcelebrating-100-days-of-kagent\u002F",[34],"CNCFが支援するkagentプロジェクト","は、まさにこの「Kubernetes上でAIエージェントを宣言的に動かす」領域のOSSとしてCNCF Sandboxに採択されている。この領域の商用拡張を手がける",[30,230,233],{"href":231,"rel":232},"https:\u002F\u002Fwww.solo.io\u002Fblog\u002Fkagent-enterprise",[34],"Solo.ioの発表","では、ユーザー・エージェント・ツール・LLM間のやり取りをエンドツーエンドで追跡する「AgentOps」という考え方が示されており、インフラ層のAudit Logだけでなく、アプリケーション層のトレーシングを重ね合わせて初めて「エージェントが何をしたか」の全体像が見える、という方向性を裏付けている。",[16,236,237,238,243],{},"さらに俯瞰すると、これは一企業の運用ノウハウというより、業界全体の課題になりつつある。",[30,239,242],{"href":240,"rel":241},"https:\u002F\u002Fwww.nist.gov\u002Fitl\u002Fai-risk-management-framework",[34],"NISTのAIリスクマネジメントフレームワーク","でも、自律的に行動するAIシステムに対しては、どのツールを呼び出せるか・どのデータに触れられるかを事前に文書化し、説明責任の所在を明確にしておくことの重要性が整理されている。Audit Logの設定は、その説明責任を技術的に担保するための出発点の一つに過ぎない。",[11,245,246],{"id":246},"まとめ",[16,248,249],{},"Kubernetes Audit Logは「APIが許可されたか」までは教えてくれるが、「AIエージェントが何を考え、何をしたか」までは教えてくれない。これは設定ミスというより、インフラ層のログ機構が本来担保している範囲の限界だ。",[16,251,252],{},"AIエージェントを本番のK3s\u002FKubernetesクラスタで動かすなら、エージェント単位の識別子・namespace-scopedな権限設計・操作系APIに絞ったAudit Policyの強化、そしてアプリケーション層のトレーシングという4つの層を組み合わせて初めて、「何をしたのか分からない」状態から抜け出せる。",[16,254,255,256,259,260,265],{},"AIエージェントを本番運用するには、こうした堅牢なインフラが不可欠だ。",[30,257,44],{"href":42,"rel":258},[34],"は、Kubo上で動くAIエージェント実行基盤として、この透明性を前提に設計されている。Audit Policyの設計を一から試行錯誤するより、エージェントの行動が最初から見える基盤を検討するのも一つの選択肢だ。AIエージェントの運用を本格化する前に、",[30,261,264],{"href":262,"rel":263},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[34],"お問い合わせ","から一度相談してみてほしい。",{"title":267,"searchDepth":268,"depth":268,"links":269},"",2,[270,271,272,273,274,275],{"id":13,"depth":268,"text":14},{"id":48,"depth":268,"text":49},{"id":114,"depth":268,"text":115},{"id":160,"depth":268,"text":161},{"id":210,"depth":268,"text":211},{"id":246,"depth":268,"text":246},"2026-11-09","AIエージェントをKubernetes上で動かし始めたら、トラブル発生時にAudit Logだけでは「誰が・何の目的で」操作したのか追えないことに気づいた。Audit Policyの盲点とトレーサビリティ確保の実践を解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fja\u002Fk3s-ai-agent-audit-log-traceability-gap\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fk3s-ai-agent-audit-log-traceability-gap",{"title":5,"description":277},"blog\u002Fja\u002Fk3s-ai-agent-audit-log-traceability-gap",[287,288,289,290,291,292],"k3s","kubernetes","ai-agent","audit-log","rbac","observability","2JaSSfaCI1Lr2MtxcsM9qGud7IQFiJgCYoFC0JE-Aas",[295,302,310,319,328,336],{"path":296,"title":297,"description":298,"date":299,"tags":300},"\u002Fblog\u002Fja\u002Fk3s-mcp-ai-agent-rbac-permission-bypass","AIエージェントに『Pod見てきて』と頼んだら、K3sクラスタごと乗っ取れた。MCPサーバーの権限バイパスが教えるRBAC設計の盲点","MCP経由でAIエージェントにKubernetes操作を任せる際の権限バイパスの実例から、K3s\u002FKubernetesクラスタに必須のRBAC設計と監査ログ分離の実践を解説する。","2026-09-03",[287,288,301,291,289],"mcp",{"path":303,"title":304,"description":305,"date":306,"tags":307},"\u002Fblog\u002Fja\u002Fk3s-prometheus-agent-mode-stale-marker-edge-monitoring","K3sエッジのPrometheusをAgent modeにしたら、ターゲットが消えた瞬間にメトリクスも消えていた","K3sエッジクラスタでPrometheus Agent modeを使うと、ターゲット消失時のstale marker処理次第で中央監視に古い値が残り続けることがある。K3s edge環境の監視設計とつまずきポイントを解説する。","2026-11-03",[287,288,308,309,292],"prometheus","edge-computing",{"path":311,"title":312,"description":313,"date":314,"tags":315},"\u002Fblog\u002Fja\u002Fk3s-k8s-default-serviceaccount-automount-rbac-multi-tenant","K3sもKubernetesも\"デフォルトのServiceAccount\"が同じ罠を持っている。マルチテナント環境でautomountを放置すると何が起きるか","K3s vs K8sを比較しても、defaultのServiceAccountが抱えるautomountの罠は変わらない。マルチテナント環境での権限昇格リスクと、実際のCVEを交えた4層の対策を解説する。","2026-10-23",[287,288,291,316,317,318],"serviceaccount","multi-tenancy","security",{"path":320,"title":321,"description":322,"date":323,"tags":324},"\u002Fblog\u002Fja\u002Fk3s-hpa-prometheus-adapter-discovery-interval-stale-metrics","discoveryIntervalを疑え。K3sのHPAがPrometheus Adapter経由で\"古いメトリクス\"を掴み続ける設定ミス","K3sのHPAがCPU使用率は正常なのにスケールしない。原因はPrometheus Adapterのmetrics-relist-interval\u002Fmetrics-max-ageとHPA sync-periodが噛み合っていない設定ミスだった。3層の遅延構造と診断コマンドを解説する。","2026-10-12",[287,288,325,326,327,292],"hpa","prometheus-adapter","autoscaling",{"path":329,"title":330,"description":331,"date":332,"tags":333},"\u002Fblog\u002Fja\u002Fk3s-servicemonitor-prometheus-not-scraping-connection-points","ServiceMonitorのYAMLは合ってる。K3sでPrometheusにターゲットが出てこない『接続点』の診断手順","K3sでkubernetes service monitorを設定したのにPrometheusのTargetsに何も出てこない。原因の9割はラベルセレクタ・ポート名・RBAC・namespaceSelectorという4つの接続点にある。1段ずつ疑って直す診断手順を解説する。","2026-08-30",[287,288,308,334,335,292],"service-monitor","monitoring",{"path":337,"title":338,"description":339,"date":340,"tags":341},"\u002Fblog\u002Fja\u002Fk3s-opentelemetry-observability-correlation","3つのダッシュボードを往復する障害対応はもう終わり。K3sの可観測性をOpenTelemetryで『相関』させる設計","PrometheusとLokiとJaegerを個別に確認して原因究明に時間を溶かしていないか。K3sクラスタの可観測性をOpenTelemetryで相関させ、障害調査時間を短縮する設計とOpenTelemetry Collectorの導入パターンを、K3s\u002FKubernetes運用の現場目線で解説する。","2026-08-20",[287,288,342,292,343],"opentelemetry","distributed-tracing",1794305477876]