* auth: drop AUTH_ROLES; add AUTH_GROUP_MAPPING + built-in defaultRole
Companion to kubeshark/hub#permissions-refactoring. Aligns the CLI
config struct, chart values, and rendered ConfigMap with the
post-refactor hub.
config/configStructs/tapConfig.go:
- Drop AuthConfig.Roles (admin-authored map[string]Role) and the
Role + ScriptingPermissions structs they referenced.
- Drop AuthConfig.DefaultFilter (no namespace scoping in v1).
- Add AuthConfig.GroupMapping (map[string]string) — SSO group name
→ built-in role translation.
- Tighten DefaultRole godoc to reference the four built-in role
constants (kubeshark-admin / kubeshark-realtime /
kubeshark-snapshot / kubeshark-viewer) and the strict-deny
semantics on empty.
config/configStruct.go:
- Drop the legacy "admin" entry from the AuthConfig default —
operators now configure DefaultRole + GroupMapping instead.
- Default RolesClaim is now "groups" (Okta/OIDC convention; was
"role"), matching the hub's runtime default.
helm-chart/templates/12-config-map.yaml:
- Drop AUTH_ROLES emission (key no longer read by hub).
- Add AUTH_GROUP_MAPPING emission from tap.auth.groupMapping (JSON
map; hub validates each value against the built-in role names at
sync time).
helm-chart/values.yaml: regenerated from the Go config — drops the
tap.auth.roles block, adds tap.auth.groupMapping with the new
documentation header for DefaultRole.
Breaking change: deployments carrying tap.auth.roles in their values
will silently lose those role definitions. Migration is to remove the
roles: block and either (a) name their SSO groups to match the four
built-in role constants, or (b) populate tap.auth.groupMapping with
explicit translations.
* auth: set helm default role to kubeshark-viewer
Per round-2 permissions clarifications: SSO users whose claim doesn't
match any built-in role and isn't in AUTH_GROUP_MAPPING should fall
back to a read-only baseline instead of strict-deny ("").
defaultRole="" causes the dashboard to 403-storm gated endpoints from
unmatched users; viewer (snapshot:read only) gives them a sensible
read-only UX while still preventing any state change.
* auth: add tap.auth.roles operator-defined role catalogue
Chart-side companion to hub commit 67162b2e (Phase C of the permissions
refactor). Operators can now declare named roles with their own
capability set + namespace scope under tap.auth.roles; the
12-config-map renders these as AUTH_ROLES JSON for the hub to consume.
- config/configStructs: AuthConfig.Roles map[string]RoleConfig with
Capabilities + Namespaces; doc comments updated for groupMapping +
defaultRole to reflect that user-defined names are now accepted.
- config/configStruct.go: zero-value initializer for Roles so
`kubeshark config` renders `roles: {}` consistently.
- helm-chart/templates/12-config-map.yaml: AUTH_ROLES emits the
full roles map as JSON; hub-side syncAuthRoles validates names
(kubeshark-* prefix reserved) and capabilities (unknown caps
warn-dropped).
- helm-chart/values.yaml: regenerated. Diff is the single `roles: {}`
line under tap.auth.
Spot-checked the rendered ConfigMap:
AUTH_ROLES: '{"payments-viewer":{"capabilities":["snapshot:read",
"dissection:live"],
"namespaces":"payments"}}'
which is exactly the shape the hub parser expects.
* auth: emit CHART_VERSION into hub ConfigMap (Phase V)
Hub commit 51abc954 reads this key on first SyncConfig and warns when
its embedded version.Ver disagrees with the chart at the major
component. Provided alongside as the chart-side companion to keep
both sides on one PR per repo on the permissions-refactoring branch.
* Revert "auth: emit CHART_VERSION into hub ConfigMap (Phase V)"
This reverts c21e4c42. Companion to hub revert 61a275b6 — the hub no
longer reads CHART_VERSION, so emitting it serves no purpose.
* chore: drop internal plan ref from auth config comment
Plans live as local working docs, not in the repo — strip the cross-repo
plans/permissions-decisions.md reference from the AuthConfig.Roles comment.
* cli: authenticate Hub HTTP requests with License-Key (gated-auth phase 1)
Add a License-Key RoundTripper plus NewHubHTTPClient / HubAuthTransport
helpers in utils, and route the MCP runner's Hub clients (connect, --url
validate, file download, tools list) through them so the CLI keeps working
once the Hub enforces auth. License-Key is a custom header, so it survives
the kube API-server service proxy (a bearer token would not). Surface
ErrHubAuthRequired on a 401/302 from the Hub.
console already sends License-Key on its ws connection. pprof is not
covered here: it shells out to 'go tool pprof <hubUrl>' / opens a browser,
external fetches that can't carry a custom header (follow-up).
* cli: mint a ServiceAccount token for gated Hub auth (phase 2a)
Provider.MintHubToken requests a short-lived token (audience kubeshark-hub)
for the kubeshark-cli ServiceAccount via the TokenRequest API. The Hub
client now prefers that token via the X-Kubeshark-Authorization custom
header (which survives the kube API-server proxy), falling back to
License-Key when minting isn't possible (--url mode, SA missing, or no
RBAC to mint). The MCP runner mints once at startup.
Pairs with hub branch cli-sa-auth. Needs the helm kubeshark-cli SA + RBAC
and the hub AUTH_CLI_SERVICE_ACCOUNTS allowlist to validate end-to-end.
* cli: authenticate console ws with the ServiceAccount token (phase 2a)
console mints the kubeshark-cli token like the MCP runner and sends it via
X-Kubeshark-Authorization, falling back to License-Key when minting isn't
possible.
* helm: kubeshark-cli ServiceAccount + token-minter RBAC + allowlist (phase 2a)
When tap.auth.cli.enabled, create the kubeshark-cli ServiceAccount and a
Role granting 'create' on serviceaccounts/token for it (bound to
configurable tap.auth.cli.subjects), and set AUTH_CLI_SERVICE_ACCOUNTS so
the Hub allowlists it. Binding the Role to a subject is what grants that
subject CLI access to a gated Hub.
* helm: render AUTH_GROUP_MAPPING in the hub config-map
The local chart never rendered AUTH_GROUP_MAPPING, so tap.auth.groupMapping
was silently dropped — SSO groups and the kubeshark-cli SA fell back to
AUTH_DEFAULT_ROLE instead of their mapped roles.
* helm: project kubeshark-hub SA token onto worker for internalauth (gated-auth)
The worker seeds its name-resolution map and capture targets via plain
HTTP GETs to the hub (/resolver/history, /pods/targeted, /pods/all). With
auth enabled these routes sit behind Auth() and return 401, leaving the
worker with an empty resolver map (all traffic shows unresolved).
Project a short-lived SA token (audience kubeshark-hub) onto the sniffer
container and expose its path via HUB_INTERNAL_TOKEN_PATH so the worker
presents it as a Bearer to the hub's internalauth gate. Gated on
tap.auth.enabled; auth-disabled clusters are unchanged.
* cli/mcp: auto-renew hub token in proxy mode; explicit token + clear expiry in --url mode
The MCP server minted a hub SA token once at startup and reused it for
the life of the process, so a long-running server 401'd silently after
the ~1h token TTL.
- utils/http: the hub round-tripper now sources the SA token via a
func() string per request (static constructors preserved), so a
renewing source keeps long-lived clients authenticated.
- kubernetes: add HubTokenRenewer — re-mints the kubeshark-cli token
before expiry (using the TokenRequest expiry, 5m margin), concurrency-safe.
- mcp proxy mode: use the renewer so the token auto-renews.
- mcp --url mode: cannot mint (no kube access) — accept an explicit
--token / KUBESHARK_HUB_TOKEN, and on 401 surface a clear 'token
expired/invalid, re-mint and restart' message instead of an opaque
API error.
console is intentionally untouched (non-functional pending the
Connect-RPC re-point); it gets renewal when that migration lands.
* cli/mcp: throttle hub-token re-mint on failure; accurate proxy 401 message
Review follow-up. HubTokenRenewer.Token() re-minted on every request while
the token was empty, so a cluster where minting can't succeed (no RBAC, SA
missing) paid a blocking ~10s CreateToken round-trip per request (under the
lock). Add a 30s retry throttle: on mint failure, back off and fall back to
the prior token / License-Key. Also correct the proxy-mode 401 message — a
token-bearing 401 means the minted token was rejected (allowlist/audience),
not an RBAC-to-mint failure.
* cli/mcp: authenticate --list-tools with the hub token source
fetchAndDisplayTools used a no-token client, so 'kubeshark mcp
--list-tools' 401'd against a gated Hub even with a valid --token. Factor
the proxy/url token-source selection into hubTokenSource() (reused by
runMCPWithConfig) and pass it through to fetchAndDisplayTools, which now
also reports a clear 401 instead of an opaque parse error.
* docs(mcp): document gated-Hub auth — --token for URL mode, proxy auto-renew
Explain that proxy mode mints and auto-renews the kubeshark-cli token, URL
mode needs an explicit --token / KUBESHARK_HUB_TOKEN (can't auto-renew) and
reports a clear 401 on expiry. Add --token to the CLI options table.
* cli/mcp: address Copilot review (token fallback, SSO redirects, messages)
- hubtoken: HubTokenRenewer.Token() no longer hands out an already-expired
token on mint failure — returns "" so the round-tripper falls back to the
License-Key instead of looping on 401s.
- utils/http: hub clients no longer follow SSO redirects (StopOnSSORedirect
CheckRedirect on 302/303), and IsAuthRequired covers 302+303, so auth
detection is reliable instead of silently following to an HTML login page.
- mcpRunner: fetchHubMCP/callHubTool/fetchAndDisplayTools/callDownloadFile
use utils.IsAuthRequired (401 + unfollowed redirect) instead of bare 401;
download path checks it before writing the body to disk; URL-mode auth
message now also mentions the License-Key fallback.
* Merge branch 'master' into gated-auth
Conflicts were in the helm chart's auth config, where master's permissions
refactor (fcceed23) reordered the AUTH_* config-map keys and replaced the
inline tap.auth.roles tree with roles/rolesClaim/defaultRole/groupMapping —
directly alongside gated-auth's new CLI ServiceAccount-token auth. Neither
side removed the other's work, so both are kept.
Also promote tap.auth.cli to a real config field. It had been hand-written
into helm-chart/values.yaml, which is generated by `make generate-helm-values`
(bin/kubeshark__ config > helm-chart/values.yaml). The next regeneration would
have silently dropped the key, leaving 22-cli-auth.yaml unable to render the
ServiceAccount. Add CliAuthConfig/CliAuthSubject to AuthConfig and regenerate
values.yaml from source, so the block now round-trips.
Subject fields carry omitempty so User/Group entries don't emit an empty
namespace and ServiceAccount entries don't emit an empty apiGroup, keeping
the rendered RoleBinding idiomatic.
values.yaml is generated and cannot hold comments, so the tap.auth.cli docs
live in helm-chart/README.md alongside the other tap.auth.* rows. Drop the
internal plan phase labels from the CLI and utils comments; phases exist only
in local planning docs.
---------
Co-authored-by: Alon Girmonsky <1990761+alongir@users.noreply.github.com>
* Migrate auth.saml.roles to unified auth.roles
Follows the hub-side introduction of the backend-neutral AUTH_ROLES /
AUTH_ROLES_CLAIM / AUTH_DEFAULT_ROLE config (hub commit 51177bcb).
CLI and Helm chart now surface the unified location:
tap.auth.roles — map of role -> permissions (shared SAML/OIDC)
tap.auth.rolesClaim — token/assertion claim name carrying roles
tap.auth.defaultRole — fallback role for authenticated users with
no matching role in their token
Helm ConfigMap template emits AUTH_ROLES / AUTH_ROLES_CLAIM /
AUTH_DEFAULT_ROLE and no longer emits AUTH_SAML_ROLES or
AUTH_SAML_ROLE_ATTRIBUTE. Hub's back-compat fallback still reads those
keys from any existing ConfigMap that hasn't been helm-upgraded.
Legacy struct fields (SamlConfig.Roles, SamlConfig.RoleAttribute) stay
in place so existing values.yaml files with auth.saml.roles still parse
without errors, but the CLI and the chart ignore them. Follow-up release
can remove the struct fields once telemetry confirms migration.
Breaking for users with customized auth.saml.roles in their values.yaml
— the customization is masked by the new default auth.roles.admin and
must be migrated to auth.roles for the custom permissions to take
effect. Documented in the chart README and release notes.
Part of authz-refactoring (Step 2 of hub-oidc-rbac.md, CLI side).
* Remove legacy
* Align CLI + Helm chart with hub AUTH_TYPE rename
Follows hub commit 11564fef. The canonical AUTH_TYPE is now `oidc` for
generic OIDC; `dex` is a permanent alias; `descope` is a new explicit
label. This change surfaces the new vocabulary in the CLI config struct
and the Helm chart, and renames the nested `auth.dexOidc` values.yaml
field to `auth.oidc` for consistency.
Helm chart:
- 12-config-map.yaml: AUTH_OIDC_* keys now read `.Values.tap.auth.oidc.*`
instead of `auth.dexOidc.*`. The cloud-license override that forced
AUTH_TYPE=default unless the admin picked `dex` now accepts `oidc` too.
- 13-secret.yaml: OIDC_CLIENT_ID / OIDC_CLIENT_SECRET read from
`auth.oidc.*` (was `auth.dexOidc.*`).
- 06-front-deployment.yaml: REACT_APP_AUTH_ENABLED / REACT_APP_AUTH_TYPE
conditionals accept both `oidc` and `dex` where they previously only
matched `dex`.
- values.yaml: comment on `tap.auth.type` lists valid values and flags
the breaking change.
- README.md: `tap.auth.type` row lists valid values. All `dexOidc`
references renamed to `oidc`. Sample values.yaml blocks now show
`type: oidc` as the canonical form.
CLI:
- config/configStructs/tapConfig.go: AuthConfig.Type documented with the
full list of valid values and the migration hint.
Breaking changes (repeated in release notes):
1. `tap.auth.type: oidc` now routes to the generic OIDC middleware
(previously Descope). Switch to `tap.auth.type: descope` or `default`
if you were using `oidc` for Descope.
2. `tap.auth.dexOidc.*` values are no longer read. Rename to
`tap.auth.oidc.*`. No fallback.
3. `tap.auth.type: dex` continues to work — permanent alias of `oidc`.
Part of authz-refactoring (Step 4 of hub-oidc-rbac.md, CLI/Helm side).
* default kfl
* Authz Refactoring: Step 8: namespaces-list role filter
Align with hub PR kubeshark/hub#756. Per-role auth.roles[].filter (KFL)
is replaced by auth.roles[].namespaces (comma-separated list with "*",
literal, and glob semantics). Standalone tap.auth.defaultFilter knob
removed.
helm-chart/values.yaml
- admin role example uses namespaces: "*" instead of filter: "".
- Comment block explains the new namespaces semantics.
- defaultFilter: "" entry + accompanying comment block deleted.
helm-chart/templates/12-config-map.yaml
- AUTH_DEFAULT_FILTER ConfigMap entry removed (hub no longer reads it).
helm-chart/README.md
- tap.auth.defaultFilter row removed.
- tap.auth.roles default value example updated: filter: "" → namespaces: "*";
description gains the per-role namespaces semantics legend.
* In preparation for v200
* updated README
* Enable raw capture
* changed 0.0.0.0 to 127.0.0.1
as 0.0.0.0 is insecure address
* added tip: kubeshark proxy
* added new TCP/UDP connection dissectors
Set API2 as the default
* increased storageLimit per worker.
* Updated makefile
* updated the complementary license
to the end of Jan 2026.
* readme touch ups
* Updated snapshot image
* updated license
removed dashboard subproject
* 🚑 Migrate to `kubehq.com` in helm values
* 🚑 Migrate to `kubehq.com` in cloud-api-url envs
* 🚑 Migrate to `kubehq.com` in manifest label keys
* 🚑 Migrate to `kubehq.com` in `Chart.yaml`
* 🚑 Migrate to `kubehq.com` in helm-chart notes/readme
* Disable Intercom support by default.
Support can be enabled using a helm flag.
* updated the license notification
as a result of a successful helm installation.
* GenAI assistant enabled by default
* 🔨 Add `tap.routing.front.basePath` helm value
* 🔨 Use `tap.routing.front.basePath` to adjust nginx blocks
* 🔨 Set `front` base path to empty string
* 📝 Update `front` base path docs
* 📝 Add `front` base path example
* 📝 Add base-path to Kubeshark URL in instructions
---------
Co-authored-by: Alon Girmonsky <1990761+alongir@users.noreply.github.com>
Serhii PonomarenkoandGitHub
Ilya GavrilovandGitHub
cloudclaimandGitHub