docs: add security/hardening deep-dive write-ups

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.

docs/sso-and-identity.md

@@ -0,0 +1,24 @@
+# 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:
+
+1. User opens the app on the browser-facing zone.
+2. 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.
+3. 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/identity-and-security/authentik/), [`stacks/platform/gitea/`](../stacks/platform/gitea/)