Posts

Your AI users shouldn't need API keys

How we put identity-aware access in front of a model gateway so developers sign in with their directory account instead of holding API keys. We did not want our internal users establishing individual relationships with external model providers. Personal accounts and provider-issued credentials would allow AI traffic to bypass our organization's access controls, approved-model policies, and compliance requirements. Instead, we introduced an open source model gateway as the shared entry point for AI traffic. It gave us centralized model access, routing, and provider credential management — but created another problem: authenticating our users. The gateways we evaluated generally offered directory integration and single sign-on only in their enterprise editions — with pricing beyond what our budget could justify for this specific requirement. We needed something narrower: authenticate users with our existing directory and authorize models based on their groups or roles. Ga...

A powerful platform can start with a tiny API

Image
How we build a DIY internal developer platform by engineering backwards from one reviewed config.json file. A JSON file powers the platform The networks are defined. Managed cloud and on-prem Kubernetes clusters are provisioned. Autoscaling is in place. The observability backend is running and waiting for data ingestion. That was the easy part of building the internal developer platform with infrastructure as code and automation. Easy for the platform team, at least. Then someone asks the obvious question: How are people going to deploy their applications to the platform without knowing anything about our infrastructure and tooling layer? Wasn't the plan to make it easy for them? That is where the platform interface becomes the hard part. A portal is tempting. It gives users buttons, forms, dropdowns, and a feeling of completeness. But if the portal tries to solve everything from day one, it can quickly become a second cloud console. Every implementation detail...

Your Kubernetes OIDC issuer is just two static files

How we brought on-prem Kubernetes clusters into an AKS-based GitOps platform without rebuilding a control plane every time we created one. One platform, two kinds of hardware Our developer platform runs on managed Kubernetes in the cloud, on AKS, and it is driven by GitOps. A team describes a service in a registry entry, Argo CD picks it up, and the service appears in the right namespace on the right cluster. Nobody files a ticket, and nobody runs kubectl by hand. Not everything belongs in the cloud, though. Some workloads need to sit close to machines on the shop floor, some data is not allowed to leave the building, and some things are simply cheaper on hardware we have already paid for. So we also run Kubernetes clusters in our own data centre, on vSphere. Early on we decided those clusters would not be a second platform with its own rules. They join the existing one. That word "join" carries most of the design. What we are after is roaming: a service should be...