Authentication
Every route in this fleet is protected one of three ways, plus a fourth case (internal-only agents) that isn’t reachable from outside the cluster at all. Almost all of it sits behind one shared Azure Entra ID login.
The three patterns
| Pattern | Used by | Why |
|---|---|---|
Shared login gate |
The fleet dashboard, this documentation site, the podcast dashboard, and other plain browser tools |
The default for anything a human reaches with a browser and has no login of its own — one shared gate, one login, reused everywhere. |
App’s own login |
A few apps that already have real logins of their own (their own OIDC client, reusing the same Entra identity) |
Putting the shared gate in front of an app that already logs people in would just be a second, redundant login. |
Deliberately no auth |
The login callback itself, and the public podcast feed |
Each earned this individually — the caller genuinely can’t complete a browser login (an RSS reader) or auth to reach it would be circular. |
This documentation site is not a fifth no-auth exception — it has an ordinary human browser audience, so it gets the default shared gate like everything else.
A fourth case: no route at all
The small internal agents and the podcast pipeline’s own inbound API have no public route and no login check of their own — they’re reachable only from inside the cluster, and only by whatever specifically calls them (the orchestrator agent, mainly), enforced by network policy rather than a credential on the call. See Namespaces & Apps for how that’s enforced.
