fcceed23ab
* 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.
Network Observability for SREs & AI Agents
Kubeshark indexes cluster-wide network traffic at the kernel level using eBPF — delivering instant answers to any query using network, API, and Kubernetes semantics.
What you can do:
- Download Retrospective PCAPs — cluster-wide packet captures filtered by nodes, time, workloads, and IPs. Store PCAPs for long-term retention and later investigation.
- Visualize Network Data — explore traffic matching queries with API, Kubernetes, or network semantics through a real-time dashboard.
- See Encrypted Traffic in Plain Text — automatically decrypt TLS/mTLS traffic using eBPF, with no key management or sidecars required.
- Integrate with AI — connect your favorite AI assistant (e.g. Claude, Copilot) to include network data in AI-driven workflows like incident response and root cause analysis.
Get Started
helm repo add kubeshark https://helm.kubeshark.com
helm install kubeshark kubeshark/kubeshark
kubectl port-forward svc/kubeshark-front 8899:80
Open http://localhost:8899 in your browser. You're capturing traffic.
For production use, we recommend using an ingress controller instead of port-forward.
Connect an AI agent via MCP:
brew install kubeshark
claude mcp add kubeshark -- kubeshark mcp
Network Data for AI Agents
Kubeshark exposes cluster-wide network data via MCP — enabling AI agents to query traffic, investigate API calls, and perform root cause analysis through natural language.
"Why did checkout fail at 2:15 PM?" "Which services have error rates above 1%?" "Show TCP retransmission rates across all node-to-node paths" "Trace request abc123 through all services"
Works with Claude Code, Cursor, and any MCP-compatible AI.
AI Skills
Open-source, reusable skills that teach AI agents domain-specific workflows on top of Kubeshark's MCP tools:
| Skill | Description |
|---|---|
| Network RCA | Retrospective root cause analysis — snapshots, dissection, PCAP extraction, trend comparison |
| KFL | KFL (Kubeshark Filter Language) expert — writes, debugs, and optimizes traffic filters |
Install as a Claude Code plugin:
/plugin marketplace add kubeshark/kubeshark
/plugin install kubeshark
Or clone and use directly — skills trigger automatically based on conversation context.
Query with API, Kubernetes, and Network Semantics
Kubeshark indexes cluster-wide network traffic by parsing it according to protocol specifications, with support for HTTP, gRPC, Redis, Kafka, DNS, and more. A single KFL query can combine all three semantic layers — Kubernetes identity, API context, and network attributes — to pinpoint exactly the traffic you need. No code instrumentation required.
KFL reference → · Traffic indexing →
Workload Dependency Map
A visual map of how workloads communicate, showing dependencies, traffic volume, and protocol usage across the cluster.
Traffic Retention & PCAP Export
Capture and retain raw network traffic cluster-wide, including decrypted TLS. Download PCAPs scoped by time range, nodes, workloads, and IPs — ready for Wireshark or any PCAP-compatible tool. Store snapshots in cloud storage (S3, Azure Blob, GCS) for long-term retention and cross-cluster sharing.
Snapshots guide → · Cloud storage →
Features
| Feature | Description |
|---|---|
| Traffic Snapshots | Point-in-time snapshots with cloud storage (S3, Azure Blob, GCS), PCAP export for Wireshark |
| Traffic Indexing | Real-time and delayed L7 indexing with request/response matching and full payloads |
| Protocol Support | HTTP, gRPC, GraphQL, Redis, Kafka, DNS, and more |
| TLS Decryption | eBPF-based decryption without key management, included in snapshots |
| AI Integration | MCP server + open-source AI skills for network RCA and traffic filtering |
| KFL Query Language | CEL-based query language with Kubernetes, API, and network semantics |
| 100% On-Premises | Air-gapped support, no external dependencies |
Install
| Method | Command |
|---|---|
| Helm | helm repo add kubeshark https://helm.kubeshark.com && helm install kubeshark kubeshark/kubeshark |
| Homebrew | brew install kubeshark && kubeshark tap |
| Binary | Download |
Contributing
We welcome contributions. See CONTRIBUTING.md.