thesabear
d5f37b5787
Secrets & PKI, Secret Distribution Model, SSO & Identity, Firewall & Network Segmentation, DNS Naming Model, and Security Monitoring - the first batch of per-system write-ups linked from the new README, sourced and sanitized from the internal KB.
2.4 KiB
SSO & Identity
Dual-zone SSO registration
Every app that needs single sign-on gets a provider + application pair registered per reverse-proxy zone it's exposed on — up to two registrations for the same app, one for the browser-facing zone and one for the internal service-to-service zone. About a dozen apps also use native OIDC/SAML instead of (or alongside) proxy-based forward-auth, where the upstream app supports it directly.
The login flow is the same shape regardless of which app or which zone it's normally accessed through:
- User opens the app on the browser-facing zone.
- The app redirects the browser to the identity provider for the actual OAuth authorize/token exchange — and that exchange always happens against the internal zone's identity-provider address, even though the app itself is normally reached via the browser-facing zone.
- On success, the browser lands back on the app's browser-facing address.
Every app-specific setting beyond this shape (token lifetime, scopes, flow type) is deliberately not generalized across apps — each app's own OIDC documentation gets read fresh rather than copying another app's provider config, since the details genuinely differ per vendor.
A real platform limitation, documented rather than hidden
LDAP-based login through the identity provider's own outpost isn't viable for the primary superuser account: the outpost hides superuser accounts from LDAP directory search, so any app that requires a search-then-bind flow can never authenticate that account through LDAP. The two ways around it — creating a second non-admin account, or demoting the primary account from superuser — were both rejected as worse than the problem. Header-based forward-auth is used instead for apps in that situation, which sidesteps the LDAP search-then-bind requirement entirely.
Git access: least privilege, not the admin account
CI and automation pushes to the internal Git server run through a dedicated, non-admin bot account with scoped write access — not through an administrator identity. Other hosts that only need to read (pulling code, not pushing) get separate read-only deploy keys instead of any shared credential. This keeps a compromised automation credential from ever being an admin credential.
Related stacks: stacks/identity-and-security/authentik/, stacks/platform/gitea/