mirror of
https://github.com/kubeshark/kubeshark.git
synced 2026-09-01 00:57:17 +00:00
Volodymyr Stoiko
12a8993752
The chart answered three unrelated questions with one switch: whether the Hub gates its API, whether the dashboard must log in to fetch a licence key, and which product features exist. So a default install rendered AUTH_ENABLED=true purely to make the cloud login reachable, and tap.auth.enabled=true with type=saml rendered AUTH_ENABLED=false, shipping an unauthenticated Hub to an operator who had asked for SSO. kubeshark.authEnabled is now tap.auth.enabled verbatim. AUTH_TYPE is the configured type verbatim, instead of being rewritten to 'default' whenever cloud licensing or demo mode was on. Settings that cannot work now fail the render rather than being quietly rewritten into something that does. The dashboard's REACT_APP_AUTH_ENABLED was a second, hand-maintained copy of the old expression with an extra internetConnectivity term, so air-gapped installs rendered a gated Hub against a dashboard that never mounted a login. It uses the same helper now. The worker hub token is projected unconditionally. Gating it on the auth decision coupled a DaemonSet rollout to that decision, so anything enabling auth without re-rendering workers left them holding no token against a Hub that required one. The CLI no longer writes AUTH_ENABLED, AUTH_TYPE or AUTH_SAML_IDP_METADATA_URL. Those come from the values the release was installed with; writing them from the CLI's own config meant a plain 'kubeshark tap' against an SSO release could silently reconfigure or disable its authentication.