Derive Kubernetes network authorization policy from a GitOps repository's own manifests — the source of truth — rather than from a live cluster.
Given a repo of Gateway API HTTPRoutes and Services, PolySieve resolves the least-privilege
ingress each namespace actually needs and emits the corresponding policy objects (Cilium
CiliumClusterwideNetworkPolicy, Istio AuthorizationPolicy, …) in the shape a given cluster
expects, selected by a profile.
A sieve is a filter that decides what passes; a network policy is a sieve over traffic (the allow-list is what gets through). "Poly" ⇒ policy and poly-backend.
Deriving policy from the live cluster inverts GitOps layering — the committed policy becomes a function of the running cluster. That is non-deterministic, needs cluster access, and can't generate policy for an app that isn't deployed yet (a deploy-then-catch-up gap). Reading the repo instead is deterministic, reproducible, CI-runnable with no cluster, and lets a new app and its policy land in one commit, no gap.
polysieve generate --repo <gitops-repo> --profile dungeon # write derived policy files
polysieve check --repo <gitops-repo> --profile dungeon # diff vs committed (nonzero on drift)
--root overrides the profile's kustomize build directories; --kustomize sets the binary.
repo → Discovery (generic route-graph) → Render (profile) → policy files
Discovery renders the repo and walks the Gateway API graph
(HTTPRoute.backendRefs → Service → targetPort) into a typed RouteGraph. A profile maps that
graph to a cluster's concrete policy. See docs/DESIGN.md.
AGPL-3.0-only.