Vancouver, February 11, 2026. It's drizzly outside, single-digit temperatures, the kind of grey day that makes you grateful for a warm, cozy blanket and a kettle that works.
A short stretch this time, but a load-bearing one.
Almost everything else PodWarden does (provisioning hosts, deploying apps, holding secrets, talking to MCP clients) eventually comes back to one question: "who is doing this, and what are they allowed to do?" So we spent a few focused days on the identity stack, with the specific intention to avoid revisiting it for a long time.
There are areas of a product you come back to, redo properly, and then leave alone for two years. This time, it was authentication.
What we shipped
New functionality
- Generic OIDC login. PodWarden now talks to any standards-compliant identity provider: Keycloak, Authentik, Auth0, Okta. Drop your
OIDC_*env vars in, restart, and your users sign in with whatever SSO they already trust. We use Keycloak internally (sso.protrener.com); you don't have to. - Local users with passwords. Not every team wants SSO. We added plain username/password auth, with a proper hashing pipeline and a Settings → Users page where an admin can create, list, and disable accounts.
- Temporary admin bootstrap. The first-run problem, solved. When you start a fresh stack, it prints a one-time admin link in the logs. You click it, set your password, and the temp account dies. Don't have to type a default password again.
- Roles: viewer/operator/admin. Three tiers, RBAC where it has to be.
Changed/refactored
- The settings page got reorganised so identity-related controls (users, roles, OIDC config) all live in one place. They were previously scattered.
- Tightened the OIDC flow to be PKCE-clean from the ground up. "Bolt on PKCE later" is one of those shortcuts you really don't want to take.
Bugfixes
- An off-by-one in the password-strength meter that displayed "weak" for passwords that were actually fine. Cosmetic, but cosmetic on the login page is a bad place to be sloppy.
- A subtle race where the Settings → Users page would render a new user before the role assignment had committed, briefly showing them as "viewer" then flipping to "admin." Now it waits.
Experimenting
- We're still working out where the line between "system config" and "user config" should sit. The Settings UI is the first artifact of that conversation, and we expect it to wobble for a while.
Was this hard?
This took three concentrated days, with two engineers working in parallel. The OIDC flow alone took a full day because we wanted PKCE to be right from the start. The local-user side was lighter but had a long tail of edge cases (disabled accounts, role downgrades, password resets) that we worked through more carefully than we would usually have to.
How this helps our users
The first time you log into PodWarden, you should land on something that feels safe. No default admin/admin, no hand-edited config files, no "wait, where do I add a second user?"
For larger teams, OIDC means PodWarden plugs into your existing SSO with no user-management work on our side. For solo and small-team users, local accounts mean you don't need to set up an SSO provider just to sign in.
Notes from the room
KubeCon EU is happening in London in late March and we want to walk in with a working demo. We're using this as our deadline at the moment.
Mood: jittery -in a good way. We caught ourselves a few times this week saying "wait, we can just do the thing now, it's not a sketch anymore." That feeling carried us through the long Sunday-evening session that closed out the local-user form.