mirror of
https://gitlab.kube.huskypup.net/Scooby/Homelabv4.git
synced 2026-08-21 05:26:49 +00:00
Scooby HuskyandClaude Sonnet 5
bb749b32b9
Two pre-existing gaps (not caused by this session's earlier work),
surfaced when the user started testing the VPS's standby Vault
(infrastructure/vps-standby/vault/) login via Authentik SSO:
1. VPS Vault's own auth/oidc/role/default allowed_redirect_uris only had
vault.kube.huskypup.net (home) and localhost:8250 - never had
vault.vps.huskypup.net registered, even though VPS's Vault shares the
same Authentik OAuth2 provider/client_id as home's. Fixed on both
sides: the shared blueprint (redirect_uris list) and VPS Vault's own
role config directly (separate Vault instance/backend, needed its own
write).
2. auth.kube.huskypup.net (Authentik itself) had NO public DNS record at
all - it only ever resolved via UniFi's local DNS for home-LAN
clients. Vault's OIDC backend runs server-side on the VPS and needs to
fetch Authentik's discovery document directly - it silently returned
an empty auth_url because it couldn't resolve the hostname at all
('missing auth_url' in Vault's UI, root cause only found by checking
DNS resolution from inside the VPS's own vault pod). Added a public
Cloudflare A record, same pattern as vault.kube.huskypup.net and
pg-authentik.ha.huskypup.net earlier - user confirmed before adding,
given it's Authentik itself. This likely also fixes OIDC for any other
VPS-hosted app doing SSO against home's Authentik, not just Vault.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>