The Hub's network-policy routes create and remove Kubernetes NetworkPolicy
objects and compute pod-reachability impact. That acts outside Kubeshark's own
data, so it is not something a role should carry implicitly and not something
a deployment should offer unasked. It gets the same shape as scripting: a
switch the operator sets, rendering NETWORK_POLICIES_DISABLED for the Hub.
Off by default. The dashboard never calls these routes, so nothing in the UI
changes; a caller that wants them is asking on purpose.
The demo is now a configuration of the knobs every deployment has rather than
a mode of its own: tap.auth.enabled false so nobody logs in, and
tap.auth.defaultRole kubeshark-viewer so an unidentified caller may only read.
The Hub enforces that role on REST, MCP and Connect-RPC alike, so the keys
this flag used to render are redundant with it.
Scripting is the exception, because "may this caller run scripts" is not a
capability anyone holds. It stays a deployment-wide switch and now follows
scripting.enabled, the value that already decides whether scripting exists
for an install. Until now a default install hid the scripting UI while the
/scripts API kept answering.
DISSECTION_CONTROL_ENABLED goes rather than losing its demo term: with the
flag gone both branches of that expression render true.
The suites in tests/ carry the reasoning, since nothing named demo survives
in the templates for a reader to follow.
An ungated deployment had no authorization at all: every caller was
admin, and the only way to restrict anyone was to stand up an identity
provider. So a read-only dashboard needed a login it had no use for.
defaultRole now answers 'what may an unidentified caller do' as well as
'what may an authenticated caller with no recognized group do'. Setting
it to kubeshark-viewer gives a read-only deployment with no login and no
auth backend.
Its default becomes kubeshark-admin, so an ungated install behaves as it
always has, and the hub falls back to admin when the value is unset or
unrecognized rather than to strict-deny — nobody configuring a role must
not brick an install.
Adds install-notes coverage, since the notes are where an operator
learns which of the two ungated postures they got, and fills the
remaining gaps in the auth suites: dex and descope validation, incomplete
settings while auth is off, and worker token projection under licensing
and demo mode.
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.
Volodymyr Stoiko
