Keycloak OIDC Everywhere
A single identity provider wired through the whole stack, including k3s API authentication. Users and services authenticate against Keycloak, with OIDC-driven access to the Kubernetes API and the Headlamp dashboard.
Reference Architecture • Kubernetes • Preview
Project Armory
An open, end-to-end reference architecture for running AI agents inside regulated enterprises with identity, secrets, PKI, and audit wired in from the start. Keycloak OIDC across the stack, OpenBao for secrets and PKI, TLS-everywhere ingress, and the BeeAI agent runtime, all provisioned with Ansible and OpenTofu.
OIDC
Identity across the stack
IaC
Ansible + OpenTofu provisioning
Preview
Reference architecture, evolving
Agents Break the Rules Regulated Enterprises Run On
Why “just deploy an agent” stalls in healthcare, financial services, government, and defense.
Every vendor has a slide deck about enterprise AI agents. The moment you try to actually deploy one inside a regulated environment, you hit a wall the demos never mention. An agent wants to reach the open internet, call whichever model provider it likes, pull whatever data it can read, and act on it autonomously. That is precisely the behavior your security, compliance, and audit functions exist to prevent.
So most teams stall. They either spend months hand-building identity, secrets, certificate, and egress plumbing around an agent before it can do anything useful, or they wait for a SaaS vendor to clear a security review that may never come while the business keeps asking why the AI everyone else is using isn’t running yet.
Project Armory closes that gap. It is a working reference implementation (not a slide deck) that wires the controls a regulated enterprise actually requires around a modern agent runtime, using only open-source components you can run, inspect, and audit yourself. Clone it, stand it up in a VM, and you have a concrete blueprint for what a hardened enterprise agent stack really looks like.
Reference Architecture: Project Armory is a working blueprint for secure agent deployment, intended for evaluation and as a foundation to adapt to your environment. Production hardening (secret backends, network policy, and security review against your own controls) is expected before production use.
What “Enterprise-Ready” Actually Means
The non-negotiables an agent platform has to satisfy before it can run in a regulated environment.
- Every action attributable to a real identity: a human or a named service, never a shared login standing in for people.
- Every secret held in a vault and injected at runtime: not committed to Git or pasted into a config map.
- Every certificate issued by a private CA you operate: not a public authority you don’t control.
- Every cluster operation governed by RBAC: tied back to the same identity that logged in.
- Every secret rotatable without a redeploy: so a leaked credential is a rotation, not an outage.
- Egress treated as a control surface: communication paths auditable, not whatever the agent decides to call.
- Every component runnable on-premises: because “send your data to our cloud” is a non-starter for some auditors.
Project Armory is built to satisfy each of these with open-source components you can inspect line by line.
Security-First by Construction
Every layer is wired for identity, encryption, and auditability.
OpenBao Secret Management
OpenBao manages secrets and PKI, integrated with the Vault Secrets Operator and cert-manager. Credentials are generated and rotated automatically including hands-off realm admin password cycling.
TLS-Everywhere Ingress
RBAC and TLS-everywhere ingress configuration by default. cert-manager and nginx-ingress issue and terminate certificates so traffic is encrypted end to end across the platform.
Auditable by Default
TBD: While each component is already auditable, we do not have the "single pane of glass" implemented yet. This project is still a work in progress and we are considering a K3S -> PVC -> Loki solution but we welcome any suggestions.
BeeAI Agent Stack
This has moved to Project Garrison. Agents run on the BeeAI Agent Stack, a Linux Foundation project, deployed onto the secured k3s platform giving AI workloads a runtime that inherits the platform's identity and secret controls.
Self-Hosted Stateful Storage
PostgreSQL for relational state and SeaweedFS for S3-compatible object storage run inside the platform you control, so agent data, file handling, and persistence never leave infrastructure you own.
Ansible + OpenTofu
End-to-end provisioning via Ansible playbooks and OpenTofu. Granular task execution through Ansible tags, with multi-component readiness validation run after deployment.
Vagrant Local Deploy
Stand up the full platform inside a Vagrant VM for local evaluation. Retrieve credentials directly from OpenBao and inspect synced Kubernetes secrets without touching production infrastructure.
How the Pieces Fit Together
Identity and secrets form one control plane while the agent, the models it routes to, and the tools it calls all run inside it.
- k3s as the substrate. A lightweight, conformant Kubernetes distribution. The patterns here (OIDC auth, RBAC, cert-manager, Helm) transfer directly to OpenShift or any standards-based cluster.
- Keycloak as the single identity provider. One realm authenticates users and services across the platform, including the Headlamp dashboard and the k3s API server, both wired to Keycloak OIDC.
- OpenBao + Vault Secrets Operator. Secrets and PKI live in OpenBao; VSO syncs them into Kubernetes as native secrets, so no workload ever handles a credential that lives in Git or that it has to read in the clear.
- cert-manager + OpenBao PKI. A private CA issues and renews certificates automatically, so traffic across the platform is encrypted with certs from an authority you control.
- nginx ingress. Edge termination and routing, with certificates drawn from the private PKI.
- Headlamp & the management plane. Cluster visibility and operations sit behind the same Keycloak OIDC and RBAC as everything else.
- BeeAI Agent Stack, the workload all of this exists to protect. The agent runtime, the models it routes to, and the tools and MCP integrations it calls all run inside this envelope: the agent authenticates through Keycloak, draws its credentials (including the keys it uses to reach models and tools) from OpenBao, and communicates over TLS issued by your private CA.
That last point is the whole point. Most agent platforms get their own ungoverned path to the internet, their own keys, their own secrets sitting in a config file. In Project Armory the agent and everything it reaches inherit the same identity, secret, and encryption controls as the rest of your estate so an LLM call or a tool invocation runs under the same controls as any other workload, not as an exception carved out around them.
What’s Actually Hard About This
A working reference is worth more than an architecture diagram, because the integration points are where these systems fight each other.
Each component in this stack is well documented on its own. The difficulty is in the places where one system’s assumptions quietly break another’s. The parts that took real work to get right include:
- Keycloak’s in-cluster HTTP-versus-HTTPS behavior, which silently breaks OIDC if you get it wrong.
- Wiring the Vault Secrets Operator to OpenBao, including the hardened-fork requirement.
- Keeping the PKI trust chain consistent across the host, the VM, and the cluster.
- Holding the OIDC issuer URL identical across every consumer (the agent platform, Headlamp, and the k3s API server) or token validation fails in confusing ways.
- Configuring k3s to validate Keycloak-issued tokens directly, getting the whole JWT validation chain right.
Project Armory encodes the working answers to these, so you start from a stack that already fits together instead of rediscovering each failure mode yourself. That is the difference between a reference you can build on and a diagram you still have to implement.
Who It’s Built For
Organizations that want to adopt AI agents without giving up the controls their environment demands.
Regulated AI Adopters
Healthcare, financial services, and high-security teams that need agentic AI to run under the same identity, secret, and audit controls as the rest of their estate.
Security & Platform Teams
Engineers who want a vetted, auditable starting point for a Kubernetes AI platform (OIDC, PKI, and TLS already integrated).
Consultants & System Integrators
Teams building bespoke agent platforms for regulated clients who need a proven, auditable foundation to adapt not a greenfield rebuild for every engagement.
Air-Gap & Data-Sovereign Environments
Deployments that must stay on-premises and self-hosted. Identity, secrets, certificates, and agent runtime all run inside infrastructure you control, with no external dependency.
Open Architecture. Hands-On Support.
Project Armory is open source and available now for evaluation. McIndi Solutions builds and operates secure platforms like this for regulated enterprises. We can help you adapt the architecture to your environment, integrate it with your existing identity and secret backends, and harden it for production.