Jean-Gabriel Gill-Couture
78bb5d77d8
All checks were successful
Run Check Script / check (pull_request) Successful in 2m19s
The auth code (Reda's, proven locally) read 7 FLEET_AUTH_* env vars at the pod. Replace that with one typed Config value each, loaded the Harmony way. - harmony_zitadel_auth: ZitadelAuthConfig is now a `Config` (Serialize/ Deserialize/JsonSchema). Add OperatorCookieKey (secret Config) with a base64→Key decode. Drop config_from_env/cookie_key_from_env + the FLEET_AUTH_* consts. - operator: serve_dashboard loads ZitadelAuthConfig + OperatorCookieKey via ConfigClient::for_namespace (EnvSource → OpenBao). No env soup. - deploy: resolves the values (hosts derived from base_domain, client_id + audiences from FleetDeployConfig, cookie key from FleetDeploySecrets) and bakes them into the operator Secret as HARMONY_CONFIG_<KEY> JSON. The published chart wires the env→Secret refs at publish time (optional, pod-light); the deploy fills the Secret at deploy time — same pattern as the NATS credentials. A test locks the baked env names to the structs' Config keys. - fleet_staging_install seeds a generated cookie key; dev.sh exports the two HARMONY_CONFIG_* JSON values instead of 7 vars. Dashboard serves once the Zitadel app allows the staging redirect URIs (fleet-stg.<base>/auth/callback) — the one remaining non-code step.