Test a CiliumNetworkPolicy against what's actually happening on your cluster — before it merges, not after it pages someone.
Live demo · Docs · Roadmap · License
A CiliumNetworkPolicy that looks correct in review can still silently break
production: a forgotten reserved:host entity drops kubelet's liveness
probe, a scoped-too-narrow selector drops an observability sidecar's
scrape, DNS egress gets missed. None of that shows up in code review or CI
— every one of those rules is syntactically valid YAML. The first signal is
usually a page, not a diff.
GuardBee diffs a candidate CiliumNetworkPolicy/CiliumClusterwideNetworkPolicy
against real recent traffic from your cluster, judged by Cilium's own
policy engine (pkg/policy — the same code your cluster actually runs,
embedded directly, not reimplemented). The result is a verdict: which real
flows would newly break, which would newly be allowed, and which stay
unchanged — before you merge, not after.
No in-cluster agent, no persisted flow store, no new cluster footprint: GuardBee runs locally with your own kubeconfig and read-only RBAC.
Four subcommands — policies, flows, verdict, and a local ui — all
read-only against the cluster. verdict is the actual engine: it diffs a
candidate CiliumNetworkPolicy/CiliumClusterwideNetworkPolicy against
today's live policy state, judging real recent Hubble flows against both,
using Cilium's own pkg/policy engine. See the
full command reference
and how verdict works
for flag-by-flag detail, known v1 simplifications, and two real
regressions it caught.
mise run build
export KUBECONFIG=/path/to/kubeconfig
./guardbee verdict -n your-namespace --last 50 your-candidate.yaml
./guardbee ui
Needs a kubeconfig with read access to your cluster — either your own, or
the read-only service account in kubernetes/rbac.yaml. Full build options
(plain Go, shell completions) and run details (RBAC,
flag conventions) are in the
Build and
Run guide
pages.
GuardBee's own version tracks the Cilium version it embeds
(go.mod's github.com/cilium/cilium) directly — e.g. v1.20.2 means built
against and validated against Cilium v1.20.2's actual pkg/policy engine and
CRD schema. A GuardBee-only change with no Cilium bump appends a trailing
qualifier instead of a new Cilium version number (v1.20.2-1, v1.20.2-2, …).
This makes compatibility legible at a glance instead of two independent
version numbers that drift apart — see
#2 for the open problem
of also detecting the cluster's real Cilium version at runtime, since the
two can still differ from each other even with this scheme.
- CLI verdict engine
- Web UI with a graph-based policy editor
- Egress-side evaluation (today: ingress-at-destination only, an explicit v1 simplification)
- Natural-language policy authoring — describe the intent in plain English, GuardBee drafts and validates the candidate (exploring)
Issues and PRs welcome. See AGENTS.md for the project's architecture
principles, known engine gotchas, and house style before making non-trivial
changes to the verdict engine (verdict.go).