[{"data":1,"prerenderedAt":286},["ShallowReactive",2],{"blog-en-ai-agent-authentication-kubernetes-keycloak-spiffe":3,"blog-related-en-ai-agent-authentication-kubernetes-keycloak-spiffe":231,"blog-en-ai-agent-authentication-kubernetes-keycloak-spiffe-alt":219},{"id":4,"title":5,"author":6,"body":7,"date":213,"description":214,"extension":215,"image":216,"locale":217,"meta":218,"navigation":219,"path":220,"seo":221,"stem":222,"tags":223,"__hash__":230},"blog\u002Fblog\u002Fen\u002Fai-agent-authentication-kubernetes-keycloak-spiffe.md","Don't Hand AI Agents the Keys. A Keyless Design for Authenticating MCP Servers on Kubernetes","Kubo Team",{"type":8,"value":9,"toc":201},"minimark",[10,14,19,22,25,36,41,64,73,77,85,93,101,104,108,111,119,131,139,147,155,159,162,165,172,181,185,188],[11,12,13],"p",{},"A quiet problem is spreading across teams running AI agents on Kubernetes in production: the API key mechanisms built for human engineers are simply being reused for AI agent authentication. Sooner or later, this approach breaks down. This article explains why static secrets hit their limit when running MCP (Model Context Protocol) servers on Kubernetes, and how a \"keyless\" authentication design combining Keycloak and SPIFFE\u002FSPIRE can become a practical solution.",[15,16,18],"h2",{"id":17},"why-you-shouldnt-hand-ai-agents-keys","Why You Shouldn't Hand AI Agents \"Keys\"",[11,20,21],{},"Human engineer authentication has always assumed a model where a person logs in a few times a day, entering passwords and MFA each time. Under that assumption, covering the leak risk of secrets mostly meant protecting a small number of accounts that log in occasionally.",[11,23,24],{},"AI agents break this assumption. A single agent can call APIs dozens of times per second, and new agent instances spin up and down dynamically depending on the task. Login patterns that would look suspicious for a human become hard to distinguish once buried in agent-to-agent calls.",[11,26,27,28,35],{},"Across the industry, a growing argument holds that AI agents should be treated as a new, third identity category — neither a \"human user\" nor a traditional \"non-human workload\" (such as a service account). In fact, \"identity and privilege abuse\" involving AI agents is ranked among the top security concerns for agentic applications (",[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,40],"h3",{"id":39},"typical-failure-patterns-caused-by-static-secrets","Typical Failure Patterns Caused by Static Secrets",[42,43,44,52,58],"ul",{},[45,46,47,51],"li",{},[48,49,50],"strong",{},"Expanding blast radius",": A single API key gets reused across multiple agents and tasks, making the impact of a leak unpredictable",[45,53,54,57],{},[48,55,56],{},"Rotation in name only",": Keys go un-rotated because \"it's working, so nobody wants to touch it\"",[45,59,60,63],{},[48,61,62],{},"Missing audit trail",": Logs record \"which key\" was used rather than \"who\" used it, making root-cause tracing difficult afterward",[11,65,66,67,72],{},"In a managed K3s environment, how you systematize certificate and secret lifecycle management is an unavoidable theme. Managed K3s services like ",[29,68,71],{"href":69,"rel":70},"https:\u002F\u002Fkubo.hexabase.io\u002F",[33],"Kubo"," ship with cert-manager built in by default, so certificate issuance and renewal are already wired in from the start.",[15,74,76],{"id":75},"why-static-secrets-hit-their-limit-in-mcp-server-authentication","Why Static Secrets Hit Their Limit in MCP Server Authentication",[11,78,79,80,35],{},"MCP (Model Context Protocol) is an open standard that lets LLM-based AI agents connect to external tools and APIs. The official MCP specification defines that a protected MCP server acts as an OAuth 2.1 resource server, responsible for validating access tokens (",[29,81,84],{"href":82,"rel":83},"https:\u002F\u002Fmodelcontextprotocol.io\u002Fspecification\u002Fdraft\u002Fbasic\u002Fauthorization",[33],"Model Context Protocol Authorization Specification",[11,86,87,88,35],{},"The problem is that teams often plug traditional \"long-lived client secrets\" straight into this OAuth client authentication step. Client secrets are inherently static shared information that is \"rarely rotated,\" and they constantly carry the risk of leaking through human error — accidentally copied into logs or config files (",[29,89,92],{"href":90,"rel":91},"https:\u002F\u002Fblog.christianposta.com\u002Fauthenticating-mcp-oauth-clients-with-spiffe\u002F",[33],"Authenticating MCP OAuth Clients With SPIFFE and SPIRE",[11,94,95,96,35],{},"MCP servers also carry risks of their own: \"tool poisoning,\" where malicious instructions are embedded in tool descriptions, and cases where a tool's behavior is quietly rewritten after approval. As a practical defense against these risks, a \"two-pillar\" approach has been proposed: replacing static tokens with short-lived, narrowly scoped access tokens under OAuth 2.0-based authentication, combined with fine-grained, per-tool authorization (",[29,97,100],{"href":98,"rel":99},"https:\u002F\u002Fwww.infracloud.io\u002Fblogs\u002Fsecuring-mcp-servers\u002F",[33],"Securing MCP Servers: A Comprehensive Guide",[11,102,103],{},"In other words, designing MCP server authentication as \"hand out a static secret and call it done\" carries a structural flaw whose failure probability rises as the number of agents grows.",[15,105,107],{"id":106},"a-keyless-design-using-keycloak-spiffespire-and-opa","A \"Keyless\" Design Using Keycloak, SPIFFE\u002FSPIRE, and OPA",[11,109,110],{},"The practical answer to this problem is a design that anchors authentication in the workload's own cryptographic identity, instead of a static secret.",[11,112,113,114,35],{},"SPIFFE (Secure Production Identity Framework For Everyone — a standard specification for issuing cryptographic identities even to non-human workloads) is a CNCF Graduated project for workload identity, and SPIRE is the runtime that implements it. Each workload is issued a short-lived, verifiable identifier (an SVID), and SPIRE automatically manages its lifecycle — issuance, verification, and rotation (",[29,115,118],{"href":116,"rel":117},"https:\u002F\u002Fspiffe.io\u002Fdocs\u002Flatest\u002Fspire-about\u002Fspire-concepts\u002F",[33],"SPIRE Concepts | SPIFFE official documentation",[11,120,121,122,127,128,35],{},"Implementations that combine this mechanism with Keycloak are also taking shape. In a 2026 release, Keycloak shipped Federated Client Authentication as a preview feature, letting Kubernetes ServiceAccount tokens be used as client authentication credentials in place of static secrets (",[29,123,126],{"href":124,"rel":125},"https:\u002F\u002Fwww.keycloak.org\u002F2026\u002F01\u002Fkeycloak-2650-released",[33],"Keycloak 26.5.0 released","). Beyond that, a custom authentication extension built on Keycloak's SPI model to validate SPIRE-issued JWT SVIDs has also been demonstrated, letting MCP clients complete OAuth authentication using only \"short-lived, automatically rotated\" credentials (",[29,129,92],{"href":90,"rel":130},[33],[11,132,133,134,35],{},"Once authentication (who is calling) is established, you still need authorization (what they're allowed to do). This is where Open Policy Agent (OPA) comes in. OPA goes beyond Kubernetes admission control — it's a general-purpose policy engine widely adopted across the CNCF ecosystem for handling authorization decisions in API servers and applications through a declarative policy language (",[29,135,138],{"href":136,"rel":137},"https:\u002F\u002Fwww.openpolicyagent.org\u002Fdocs",[33],"Open Policy Agent official documentation",[11,140,141,142,35],{},"Structuring this as a three-layer stack — \"SPIRE (identity issuance) → Keycloak (token exchange\u002Fauthentication) → OPA (authorization decision)\" — makes it possible to achieve \"keyless\" MCP agent authentication that distributes no static keys anywhere. Indeed, industry discussion is increasingly setting an explicit design goal of driving static credential files, and manually created Keycloak clients, down to zero (",[29,143,146],{"href":144,"rel":145},"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,148,149,150,154],{},"When putting this architecture into practice on a managed K3s environment, the operational key is whether you can make certificate and token lifecycles visible across the cluster. ",[29,151,153],{"href":69,"rel":152},[33],"Kubo Cloud"," comes with a Rancher-based management layer, and its ability to surface certificate- and identity-related state across multiple clusters pairs well with this kind of zero-trust design.",[15,156,158],{"id":157},"do-we-really-need-a-new-identity-platform-built-just-for-ai-agents","Do We Really Need a \"New Identity Platform Built Just for AI Agents\"?",[11,160,161],{},"As AI agents rise in prominence, the argument that \"we need a brand-new identity platform built specifically for agents\" is also gaining traction. But this claim is only half right.",[11,163,164],{},"Authentication, authorization, audit trails, and permission delegation are themselves classic problems that the identity industry has grappled with for years — AI agents haven't fundamentally changed them. The real challenge instead arises as the \"chain of authority\" grows longer — human → agent → another agent → API — and whether impersonation can still be detected if it happens at some link along that chain.",[11,166,167,168,171],{},"One mechanism drawing attention in this context is \"Identity Assertion JWT Authorization Grants (ID-JAG),\" which safely handles chains of token delegation, discussed as a countermeasure to the \"Confused Deputy\" problem, where authority ends up in the hands of an unintended party (",[29,169,146],{"href":144,"rel":170},[33],"). On MCP governance too, a view is gaining ground that a combination of existing standard technologies — OAuth 2.0 token delegation, token exchange, and fine-grained scope control — can already reach a \"production-ready\" bar.",[11,173,174,175,180],{},"In other words, before building a dedicated platform from scratch, it's well worth considering the approach of extending an existing identity platform like Keycloak with SPIFFE\u002FSPIRE and OPA. For industries with strict data sovereignty or audit requirements, an option like ",[29,176,179],{"href":177,"rel":178},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[33],"Kubo On-Premise"," — where you keep the entire authentication foundation under your own management — becomes a realistic fallback in this context.",[15,182,184],{"id":183},"conclusion","Conclusion",[11,186,187],{},"The more AI agent operations scale into production, the more quietly — but surely — mistakes in authentication design come back to bite you. Rather than simply carrying over static-secret operations built for humans, it's important to build in from the start a \"keyless\" design where SPIFFE\u002FSPIRE cryptographically issues workload identity, and Keycloak and OPA separately handle authentication and authorization.",[11,189,190,191,196,197,200],{},"Running AI agents as full-fledged members of an organization in production requires robust infrastructure that includes this kind of authentication foundation. The idea of safely running an AI agent execution platform like ",[29,192,195],{"href":193,"rel":194},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fcaptain-ai\u002F",[33],"Captain.AI"," on top of ",[29,198,71],{"href":69,"rel":199},[33],"'s K3s-based managed Kubernetes foundation is only going to grow more important as an infrastructure strategy for the AI era.",{"title":202,"searchDepth":203,"depth":203,"links":204},"",2,[205,209,210,211,212],{"id":17,"depth":203,"text":18,"children":206},[207],{"id":39,"depth":208,"text":40},3,{"id":75,"depth":203,"text":76},{"id":106,"depth":203,"text":107},{"id":157,"depth":203,"text":158},{"id":183,"depth":203,"text":184},"2026-08-18","Handing AI agents static API keys is an operating model that eventually breaks down. This article explains why static secrets hit a wall when running MCP servers on Kubernetes, and how Keycloak combined with SPIFFE\u002FSPIRE enables a 'keyless' authentication design.","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fai-agent-authentication-kubernetes-keycloak-spiffe\u002Feyecatch.webp","en",{},true,"\u002Fblog\u002Fen\u002Fai-agent-authentication-kubernetes-keycloak-spiffe",{"title":5,"description":214},"blog\u002Fen\u002Fai-agent-authentication-kubernetes-keycloak-spiffe",[224,225,226,227,228,229],"k3s","kubernetes","ai-agent","mcp","keycloak","zero-trust","H61CshtA-LKg2hVpHkQPF1PVNQBKS1TU6l3zXMzikBQ",[232,240,250,259,269,277],{"path":233,"title":234,"description":235,"date":236,"tags":237},"\u002Fblog\u002Fen\u002Fai-agent-sandbox-kata-containers-kubernetes","AI Agent Code Isn't a \"Trusted Product\" Anymore. Kubernetes Sandbox Design Has an Answer","Code generated and executed by AI agents can no longer be treated as a trusted, reviewed product. This article explains the limits of container isolation and why Kata Containers' microVM isolation is becoming essential when designing AI agent sandboxes on Kubernetes.","2026-08-08",[224,225,238,226,239],"kata-containers","security",{"path":241,"title":242,"description":243,"date":244,"tags":245},"\u002Fblog\u002Fen\u002Fk3s-container-image-security-supply-chain-checklist","'Scanned' Is Not a Production Clearance Certificate: K3s Container Image Security From Signing to Admission Control","Container security guidelines often stop at 'we run a scanner.' This guide walks through the practical checklist you need to pass before production in K3s: minimal base images, vulnerability scanning, SBOM generation, signing, and admission control.","2026-08-24",[224,225,246,247,248,249],"container-security","image-scanning","sbom","supply-chain-security",{"path":251,"title":252,"description":253,"date":254,"tags":255},"\u002Fblog\u002Fen\u002Fk3s-harbor-private-registry-docker-hub-rate-limit","The Morning Docker Hub's Free Tier Freezes Up, Your K3s Cluster Quietly Grinds to a Halt: When to Run Your Own Harbor","Docker Hub's pull rate limit is an increasingly real risk to image pulls on production K3s clusters. Kubo explains the design decisions and hidden costs of self-hosting Harbor, a CNCF Graduated project.","2026-08-23",[224,225,256,257,258],"harbor","container-registry","cncf",{"path":260,"title":261,"description":262,"date":263,"tags":264},"\u002Fblog\u002Fen\u002Fkubernetes-cost-management-eks-aks-billing-visibility","Your EKS Bill Only Makes Sense at Month-End: Why Kubernetes Costs Are Structurally 'Discovered Too Late'","Why do Kubernetes costs on EKS\u002FAKS balloon unexpectedly? We break down how autoscaling and cross-AZ billing hide costs, and explore how K3s-based managed infrastructure turns them into a fixed cost.","2026-08-22",[224,225,265,266,267,268],"cost-optimization","managed-kubernetes","aks","finops",{"path":270,"title":271,"description":272,"date":273,"tags":274},"\u002Fblog\u002Fen\u002Fkubernetes-operations-specialization-managed-k3s-hiring","eBPF, cert-manager, Service Mesh: Why Kubernetes Operations Outgrew What One Engineer Can Handle","Why do Kubernetes operations roles stay unfilled for months? It isn't a lack of tool knowledge — it's that the discipline has splintered into too many specialties. Instead of hiring more heads, absorb the specialization into the platform with managed K3s.","2026-08-21",[224,225,266,275,276],"devops","platform-engineering",{"path":278,"title":279,"description":280,"date":281,"tags":282},"\u002Fblog\u002Fen\u002Fk3s-opentelemetry-observability-correlation","Stop Bouncing Between Three Dashboards: Correlating K3s Observability with OpenTelemetry","Are you burning incident-response time checking Prometheus, Loki, and Jaeger separately? Learn how to correlate metrics, logs, and traces with OpenTelemetry to cut investigation time on K3s clusters, with practical Collector deployment patterns.","2026-08-20",[224,225,283,284,285],"opentelemetry","observability","distributed-tracing",1787649514227]