25Sekisho — Zero-Long-Lived-Keys Gateway for Entra-Only Microsoft Foundry
OpenAI-SDK clients reach Entra-only Foundry — inbound key, outbound managed identity
Role: Creator & Maintainer
Executive summary
Built an experimental, stateless reverse-proxy gateway that exposes an Entra-only Microsoft Foundry deployment as an OpenAI-compatible endpoint, so any OpenAI-SDK-compatible client can use it without ever handling Entra tokens or a Foundry API key.
- FastAPI
- Microsoft Foundry
- Entra ID (Managed Identity)
- Azure Key Vault
- Azure Container Apps
- Bicep
Some Azure environments enforce policy that disables local/key auth on Microsoft Foundry (Entra-only access), which breaks any client expecting a standard OpenAI-compatible API key. I wanted a personal project to explore a clean way to bridge that gap without ever exposing a Foundry key.
- Design a thin, stateless proxy that authenticates inbound callers with its own key, then exchanges that for a managed-identity Entra token outbound to Foundry.
- Expose chat, responses and audio (speech-to-text / text-to-speech) endpoints in an OpenAI-compatible shape.
- Support key issuance, rotation and revocation, plus infrastructure-as-code and a deployment runbook.
I built a FastAPI app that accepts a "Sekisho Key" (`Authorization: Bearer`) from callers, calls Foundry using its system-assigned managed identity (Entra token, `https://ai.azure.com/.default` scope) with automatic 401 → refresh → retry, and exposes `/openai/v1/*` for chat, responses and audio models. Key lifecycle (issue/rotate/revoke) is backed by Azure Key Vault via an `/admin` UI protected by Entra Easy Auth. Infrastructure (Foundry + project, Key Vault, Container Apps, least-privilege RBAC) is defined in Bicep, with a multi-stage Docker build, a deployment runbook and ADRs.
A working experimental gateway with a pytest suite covering the proxy, auth, keys and token exchange. Security posture is explicit by design — no Foundry API key exists anywhere in the system, inbound keys are issued, rotated and revoked from Key Vault, and the admin surface sits behind Entra Easy Auth—all stated up front because an auth gateway is only as strong as its threat model. It is explicitly documented as an experiment, not for production use — the expected result is a working, personal proof of the managed-identity bridging pattern, not a shipped product.
Designing the inbound-key / outbound-managed-identity split clarified how to keep zero long-lived model credentials anywhere in the system, and labeling this clearly as an experiment (not a product) kept the scope tight enough to actually finish it.
Architecture diagram coming soon
Drop an image at assets/img/diagrams/sekisho-foundry-gateway.png