[{"data":1,"prerenderedAt":309},["ShallowReactive",2],{"blog-ja-ai-agent-authentication-kubernetes-keycloak-spiffe":3,"blog-related-ja-ai-agent-authentication-kubernetes-keycloak-spiffe":254,"blog-ja-ai-agent-authentication-kubernetes-keycloak-spiffe-alt":242},{"id":4,"title":5,"author":6,"body":7,"date":236,"description":237,"extension":238,"image":239,"locale":240,"meta":241,"navigation":242,"path":243,"seo":244,"stem":245,"tags":246,"__hash__":253},"blog\u002Fblog\u002Fja\u002Fai-agent-authentication-kubernetes-keycloak-spiffe.md","AIエージェントに鍵を持たせるな。KubernetesでMCPサーバーを『キーレス』に認証する設計","Kubo Team",{"type":8,"value":9,"toc":224},"minimark",[10,14,19,22,25,36,40,63,72,79,83,91,99,107,110,116,120,123,131,143,151,159,167,173,177,180,183,190,199,205,208,211],[11,12,13],"p",{},"AIエージェントとKubernetesを組み合わせて本番運用する現場で、静かに広がっている問題がある。人間のエンジニアに発行してきたAPIキーの仕組みを、そのままAIエージェントの認証にも流用してしまうことだ。しかし、この延長線上の設計は遅かれ早かれ破綻する。本稿では、Kubernetes上でMCP（Model Context Protocol）サーバーを運用する際になぜ静的シークレットが限界を迎えるのか、そしてKeycloakとSPIFFE\u002FSPIREを組み合わせた「キーレス」な認証設計がどう現実解になり得るのかを整理する。",[15,16,18],"h2",{"id":17},"なぜaiエージェントに鍵を持たせてはいけないのか","なぜAIエージェントに「鍵」を持たせてはいけないのか",[11,20,21],{},"人間のエンジニアの認証は、1日に数回ログインし、パスワードやMFAを都度入力するというモデルを前提にしてきた。シークレットの漏洩リスクは「たまにログインする少数のアカウント」を守れば大部分をカバーできた。",[11,23,24],{},"ところがAIエージェントはこの前提を崩す。1つのエージェントが1秒間に何十回もAPIを呼び出し、タスクに応じて新しいインスタンスが動的に増減する。不審な挙動として気づけていたログインパターンも、エージェント間の呼び出しに紛れると識別が難しくなる。",[11,26,27,28,35],{},"業界でも、AIエージェントは「人間のユーザー」でも従来の「非人間型ワークロード」でもない、新しい第三のアイデンティティ区分として扱うべきだという議論が広がっている。実際、AIエージェントに関わる「アイデンティティと権限の濫用」は、エージェント型アプリケーションのセキュリティ課題の中でも上位に位置づけられている（",[29,30,34],"a",{"href":31,"rel":32},"https:\u002F\u002Fsecureflo.net\u002Fai-agent-identity-management-a-2026-ciso-playbook\u002F",[33],"nofollow","AI Agent Identity Management: A 2026 CISO Playbook","）。",[37,38,39],"h3",{"id":39},"静的シークレットが引き起こす典型的な事故パターン",[41,42,43,51,57],"ul",{},[44,45,46,50],"li",{},[47,48,49],"strong",{},"影響範囲の拡大",": 1つのAPIキーが複数のエージェント・タスクで使い回され、漏洩時の被害範囲が予測できない",[44,52,53,56],{},[47,54,55],{},"ローテーションの形骸化",": 「動いているから触りたくない」という理由で、鍵の更新が先送りされ続ける",[44,58,59,62],{},[47,60,61],{},"監査証跡の欠如",": 「誰が」ではなく「どのキーが」しか記録されず、原因追跡が困難になる",[11,64,65,66,71],{},"マネージドK3s環境では、証明書・シークレットのライフサイクル管理をどう仕組み化するかが避けて通れないテーマになる。",[29,67,70],{"href":68,"rel":69},"https:\u002F\u002Fkubo.hexabase.io\u002F",[33],"Kubo"," のようなマネージドK3sサービスでは cert-manager が標準搭載されており、証明書の発行・更新の仕組みが最初から組み込まれている。",[11,73,74],{},[75,76],"img",{"alt":77,"src":78},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fai-agent-authentication-kubernetes-keycloak-spiffe\u002Fsection01.webp",[15,80,82],{"id":81},"mcpサーバーの認証で静的シークレットが限界を迎える理由","MCPサーバーの認証で静的シークレットが限界を迎える理由",[11,84,85,86,35],{},"MCP（Model Context Protocol）は、LLMベースのAIエージェントが外部ツールやAPIと接続するオープンな標準規格だ。MCPの公式仕様では、保護されたMCPサーバーはOAuth 2.1のリソースサーバーとして振る舞い、アクセストークンを検証する役割を担うと定義されている（",[29,87,90],{"href":88,"rel":89},"https:\u002F\u002Fmodelcontextprotocol.io\u002Fspecification\u002Fdraft\u002Fbasic\u002Fauthorization",[33],"Model Context Protocol Authorization仕様",[11,92,93,94,35],{},"問題は、このOAuthクライアント認証の部分に、従来型の「長期間有効なクライアントシークレット」をそのまま当てはめてしまうケースが多いことだ。クライアントシークレットは本質的に「めったにローテーションされない」静的な共有情報であり、ログや設定ファイルへの誤コピーといった人為的ミスによる漏洩リスクを常に抱える（",[29,95,98],{"href":96,"rel":97},"https:\u002F\u002Fblog.christianposta.com\u002Fauthenticating-mcp-oauth-clients-with-spiffe\u002F",[33],"Authenticating MCP OAuth Clients With SPIFFE and SPIRE",[11,100,101,102,35],{},"さらにMCPサーバー特有のリスクとして、ツールの説明文に悪意のある指示を埋め込む「ツールポイズニング」や、承認後にツールの挙動がひそかに書き換えられる問題も指摘されている。現実的な防御策として、静的トークンを「短命でスコープが限定されたアクセストークン」に置き換えるOAuth 2.0ベースの認証と、ツール単位のきめ細かな認可を組み合わせる「二本柱」のアプローチが提案されている（",[29,103,106],{"href":104,"rel":105},"https:\u002F\u002Fwww.infracloud.io\u002Fblogs\u002Fsecuring-mcp-servers\u002F",[33],"Securing MCP Servers: A Comprehensive Guide",[11,108,109],{},"つまり、MCPサーバーの認証を「静的シークレットを配って終わり」にする設計は、エージェントの数が増えるほど破綻の確率が上がる構造的な欠陥を抱えているということだ。",[11,111,112],{},[75,113],{"alt":114,"src":115},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fai-agent-authentication-kubernetes-keycloak-spiffe\u002Fsection02.webp",[15,117,119],{"id":118},"keycloakspiffespireopaでキーレスを実現する設計","Keycloak・SPIFFE\u002FSPIRE・OPAで「キーレス」を実現する設計",[11,121,122],{},"この問題への現実的な回答が、静的シークレットの代わりにワークロード自体の暗号学的なアイデンティティを認証の起点にする設計だ。",[11,124,125,126,35],{},"SPIFFE（Secure Production Identity Framework For Everyone、非人間型ワークロードにも暗号学的な身元を発行する標準仕様）は、CNCFがGraduatedプロジェクトとして認定しており、SPIRE はそれを実装するランタイムだ。各ワークロードには短命で検証可能な識別子（SVID）が発行され、SPIREがそのライフサイクル（発行・検証・ローテーション）を自動管理する（",[29,127,130],{"href":128,"rel":129},"https:\u002F\u002Fspiffe.io\u002Fdocs\u002Flatest\u002Fspire-about\u002Fspire-concepts\u002F",[33],"SPIRE Concepts | SPIFFE公式ドキュメント",[11,132,133,134,139,140,35],{},"この仕組みとKeycloakを組み合わせる実装も具体化しつつある。Keycloakは2026年のリリースで、Kubernetes ServiceAccountトークンを静的シークレットの代わりにクライアント認証の資格情報として使えるFederated Client Authenticationをプレビュー機能として搭載した（",[29,135,138],{"href":136,"rel":137},"https:\u002F\u002Fwww.keycloak.org\u002F2026\u002F01\u002Fkeycloak-2650-released",[33],"Keycloak 26.5.0 released","）。さらにSPIRE発行のJWT SVIDを検証するカスタム認証拡張をKeycloakのSPIモデル上に実装し、MCPクライアントが「短命かつ自動ローテーションされる」資格情報だけでOAuth認証を完結させる実証も報告されている（",[29,141,98],{"href":96,"rel":142},[33],[11,144,145,146,35],{},"認証（誰が呼んでいるか）が確立された後は、認可（何をしてよいか）の判断が必要になる。ここで使われるのがOpen Policy Agent（OPA）だ。OPAはKubernetesのアドミッションコントロールにとどまらず、宣言的なポリシー言語でAPIサーバーやアプリケーション側の認可判断を統一的に扱える汎用ポリシーエンジンとして、CNCFエコシステムで広く採用されている（",[29,147,150],{"href":148,"rel":149},"https:\u002F\u002Fwww.openpolicyagent.org\u002Fdocs",[33],"Open Policy Agent 公式ドキュメント",[11,152,153,154,35],{},"この「SPIRE（アイデンティティ発行）→ Keycloak（トークン交換・認証）→ OPA（認可判断）」という3層構成にすることで、静的な鍵をどこにも配布しない「キーレス」なMCPエージェント認証が実現できる。実際、業界の議論でも「静的な資格情報ファイルをゼロにし、人手で作成するKeycloakクライアントもゼロにする」ことを明確な設計目標に掲げる動きが出てきている（",[29,155,158],{"href":156,"rel":157},"https:\u002F\u002Fwww.cncf.io\u002Fblog\u002F2026\u002F07\u002F14\u002Fkeycloakcon-japan-2026-navigating-cloud-native-identity-and-the-ai-frontier\u002F",[33],"KeycloakCon Japan 2026: Navigating cloud native identity and the AI frontier | CNCF",[11,160,161,162,166],{},"マネージドK3s環境でこの構成を実践する場合、証明書・トークンのライフサイクルをクラスタ横断で可視化できるかが運用上の鍵になる。",[29,163,165],{"href":68,"rel":164},[33],"Kubo Cloud"," はRancherベースの管理基盤を備え、マルチクラスタでの証明書・アイデンティティ関連の状態を把握できる点が、こうしたゼロトラスト設計との相性がよい。",[11,168,169],{},[75,170],{"alt":171,"src":172},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fai-agent-authentication-kubernetes-keycloak-spiffe\u002Fsection03.webp",[15,174,176],{"id":175},"aiエージェント専用の新しいid基盤は本当に必要か","「AIエージェント専用の新しいID基盤」は本当に必要か",[11,178,179],{},"AIエージェントの台頭を受けて、「エージェント専用の新しいアイデンティティ基盤が必要だ」という主張も増えている。しかし、これは半分正しく半分は行き過ぎだ。",[11,181,182],{},"認証・認可・監査証跡・権限委任という要素そのものは、長年アイデンティティ業界が向き合ってきた古典的な課題であり、AIエージェントによって根本から変わったわけではない。むしろ課題になるのは、人間→エージェント→別のエージェント→APIという「権限の連鎖」が長くなったときに、途中でなりすましが起きても検知できるかという点だ。",[11,184,185,186,189],{},"この文脈で近年注目されているのが、トークンの委任連鎖を安全に扱う「Identity Assertion JWT Authorization Grants（ID-JAG）」のような仕組みで、権限が本来意図しない主体に渡ってしまう「Confused Deputy（混乱した代理人）」問題への対策として議論されている（",[29,187,158],{"href":156,"rel":188},[33],"）。MCPのガバナンスも、OAuth 2.0のトークン委任・交換・きめ細かなスコープ制御といった既存の標準技術の組み合わせで「プロダクションレディ」な水準に到達できるという見方が有力になりつつある。",[11,191,192,193,198],{},"つまり、ゼロから専用基盤を作り込む前に、Keycloakのような既存のID基盤をSPIFFE\u002FSPIREやOPAで拡張するアプローチを検討する価値は十分にある。データ主権や監査要件が厳しい業種であれば、認証基盤ごと自社管理下に置ける",[29,194,197],{"href":195,"rel":196},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[33],"Kubo On-Premise"," が現実的な受け皿になる。",[11,200,201],{},[75,202],{"alt":203,"src":204},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fai-agent-authentication-kubernetes-keycloak-spiffe\u002Fsection04.webp",[15,206,207],{"id":207},"まとめ",[11,209,210],{},"AIエージェントの運用が本番規模に拡大するほど、認証基盤の設計ミスは静かに、しかし確実に効いてくる。人間向けの静的シークレット運用をそのまま流用するのではなく、SPIFFE\u002FSPIREでワークロードのアイデンティティを暗号学的に発行し、KeycloakとOPAで認証・認可を分離して扱う「キーレス」な設計を最初から前提に組み込んでおくことが重要だ。",[11,212,213,214,217,218,223],{},"AIエージェントを組織の一員として本番稼働させるには、こうした認証基盤を含めた堅牢なインフラが不可欠になる。",[29,215,70],{"href":68,"rel":216},[33]," のK3sベースのマネージドKubernetes基盤の上で、",[29,219,222],{"href":220,"rel":221},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fcaptain-ai\u002F",[33],"Captain.AI"," のようなAIエージェント実行基盤を安全に動かす発想は、AI時代のインフラ戦略として今後さらに重要性を増していくだろう。",{"title":225,"searchDepth":226,"depth":226,"links":227},"",2,[228,232,233,234,235],{"id":17,"depth":226,"text":18,"children":229},[230],{"id":39,"depth":231,"text":39},3,{"id":81,"depth":226,"text":82},{"id":118,"depth":226,"text":119},{"id":175,"depth":226,"text":176},{"id":207,"depth":226,"text":207},"2026-08-18","AIエージェントに静的なAPIキーを持たせる運用は、いずれ破綻する。KubernetesでMCPサーバーを運用する現場で起きている静的シークレット問題の構造的な限界と、KeycloakとSPIFFE\u002FSPIREを組み合わせて鍵を配らずに認証する『キーレス』設計思想を解説する。","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fai-agent-authentication-kubernetes-keycloak-spiffe\u002Ftitle.webp","ja",{},true,"\u002Fblog\u002Fja\u002Fai-agent-authentication-kubernetes-keycloak-spiffe",{"title":5,"description":237},"blog\u002Fja\u002Fai-agent-authentication-kubernetes-keycloak-spiffe",[247,248,249,250,251,252],"k3s","kubernetes","ai-agent","mcp","keycloak","zero-trust","mmGc1LIZ49lr7pTPuyGPtzJd2DgFDLwn42S1c5ojukM",[255,263,273,282,292,300],{"path":256,"title":257,"description":258,"date":259,"tags":260},"\u002Fblog\u002Fja\u002Fai-agent-sandbox-kata-containers-kubernetes","AIエージェントのコードは「信頼できる製品」じゃない。Kubernetesサンドボックス設計の答え","AIエージェントが生成・実行するコードはもう「信頼できる製品」ではない。KubernetesでAIエージェント向けサンドボックスを設計する際、コンテナ分離の限界とKata Containersによるマイクロ VM分離がなぜ必要になるのかを解説する。","2026-08-08",[247,248,261,249,262],"kata-containers","security",{"path":264,"title":265,"description":266,"date":267,"tags":268},"\u002Fblog\u002Fja\u002Fk3s-container-image-security-supply-chain-checklist","「スキャン済み」は本番投入の許可証にならない。K3sコンテナイメージセキュリティ、署名からアドミッション制御まで","コンテナ セキュリティ ガイドラインというと『スキャンしてるから大丈夫』で止まりがちだ。K3s環境でベースイメージの最小化から脆弱性スキャン、SBOM生成、署名、アドミッション制御まで、本番投入前に通すべき工程を実務チェックリストとして具体的に解説する。","2026-08-24",[247,248,269,270,271,272],"container-security","image-scanning","sbom","supply-chain-security",{"path":274,"title":275,"description":276,"date":277,"tags":278},"\u002Fblog\u002Fja\u002Fk3s-harbor-private-registry-docker-hub-rate-limit","Docker Hubの無料枠が凍りついた朝、K3sクラスタは静かに詰む。Harborを自前で持つべきタイミング","Docker Hubのpull rate limitで本番K3sクラスタのイメージ取得が止まるリスクが現実味を増している。CNCF卒業プロジェクトHarborを自前運用する設計判断と隠れたコストを解説する。","2026-08-23",[247,248,279,280,281],"harbor","container-registry","cncf",{"path":283,"title":284,"description":285,"date":286,"tags":287},"\u002Fblog\u002Fja\u002Fkubernetes-cost-management-eks-aks-billing-visibility","EKSの請求書は月末にならないと読めない。Kubernetesのコストが『後から分かる』構造的な理由","EKS\u002FAKSのKubernetesコストはなぜ想定外に膨らむのか。オートスケールとクロスAZ課金がコストを見えなくする構造を分解し、K3sベースのマネージドインフラで固定費化する方法を解説します。","2026-08-22",[247,248,288,289,290,291],"cost-optimization","managed-kubernetes","aks","finops",{"path":293,"title":294,"description":295,"date":296,"tags":297},"\u002Fblog\u002Fja\u002Fkubernetes-operations-specialization-managed-k3s-hiring","eBPFもcert-managerもService Meshも。Kubernetes運用がひとりのエンジニアの手に負えなくなった理由","Kubernetes運用の求人がなぜ埋まらないのか。原因はツール知識の不足ではなく、専門分野が広がりすぎたことにある。採用で埋めるのではなく基盤に吸収させる、マネージドK3sという解決策を解説する。","2026-08-21",[247,248,289,298,299],"devops","platform-engineering",{"path":301,"title":302,"description":303,"date":304,"tags":305},"\u002Fblog\u002Fja\u002Fk3s-opentelemetry-observability-correlation","3つのダッシュボードを往復する障害対応はもう終わり。K3sの可観測性をOpenTelemetryで『相関』させる設計","PrometheusとLokiとJaegerを個別に確認して原因究明に時間を溶かしていないか。K3sクラスタの可観測性をOpenTelemetryで相関させ、障害調査時間を短縮する設計とOpenTelemetry Collectorの導入パターンを、K3s\u002FKubernetes運用の現場目線で解説する。","2026-08-20",[247,248,306,307,308],"opentelemetry","observability","distributed-tracing",1787649510006]