项目文件夹
* 🔒 decide API gating from tap.auth.enabled alone 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. * 🔒 apply tap.auth.defaultRole when authentication is disabled 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. * chart: drop demoModeEnabled in favour of auth.defaultRole 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. * config: stop the default-config literal overriding the auth defaults values.yaml is generated by serialising CreateDefaultConfig, and that literal sets the Auth fields explicitly instead of leaving them to the struct tags. The tag said kubeshark-admin while the literal said kubeshark-viewer, so the chart's committed default only held until the next generate-helm-values, which would have rewritten every ungated install from admin to read-only and 403ed deployments that never configured authorization. Regenerating now reproduces the committed values.yaml byte for byte, which is what says the two sources agree rather than merely happening to look alike. The test compares the literal against the tag instead of asserting a role name, so it keeps holding if the default is deliberately changed and only fails when the two drift apart. Also documents that scripting.enabled closes the scripting API rather than only hiding the UI, now that it is the switch demo mode used to be. * chart: add tap.networkPolicies.enabled, off by default 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. * chart: regenerate the rendered manifest manifests/complete.yaml is generated from the chart and committed, so it went stale when demoModeEnabled was removed: it still advertised DEMO_MODE_ENABLED and the six keys that flag used to fan out into, and carried none of the NETWORK_POLICIES_DISABLED gate. Anyone reading it to find out what the chart renders was reading the previous release. * chart: name the configured auth type in the issuer failure, fix a doc default Both oidc and dex take tap.auth.oidc.issuer, but the failure hard-coded "oidc", so a dex operator was sent looking for a setting they had not configured. The README also documented tap.auth.rolesClaim as `role` where the chart defaults it to `groups`, which is the kind of mismatch an operator only finds after their SSO claims fail to map. * config: gofmt tapConfig struct tags after the master merge Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
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.




