CONSTELLATION PRODUCT / NETWORK

Policy from what actually talks.

Constellation records which workloads talk to which, turns those observed flows into candidate network policies, and rolls them out only after someone approves them. Every step is audited and can be undone.

Alpha · Visibility on by default · Nothing enforced until applied

01 / TRAFFIC MAP

Every conversation, with its verdict.#

The runtime agent’s data plane reports connections between pods: bytes, packets, sessions, the application protocol detected and the policy verdict. The network workspace shows them as a map, folded conversations, live sessions, packet captures, rules and DPI threats.

CLUSTER / NETWORK ACTIVITYCONSTELLATION
Network activity: Observed traffic between workloads with verdict, namespace and group filters, plus conversations, sessions, packet capture, rules and DPI threats.Network activity: Observed traffic between workloads with verdict, namespace and group filters, plus conversations, sessions, packet capture, rules and DPI threats.
Observed traffic between workloads with verdict, namespace and group filters, plus conversations, sessions, packet capture, rules and DPI threats.
FILTER

Narrow it down

Filter by time window, verdict, namespace and group, and save the views you come back to.

EXPOSURE

See what faces outward

Workloads that talk to the outside world, alongside their vulnerabilities, so exposure and CVEs are read together.

ACT

Cut it off

Isolate a workload with a default-deny NetworkPolicy, or kill a live session, from the map.

02 / POLICY LIFECYCLE

Approve, apply, demote, roll back.#

Constellation generates a candidate policy per workload from the flows it saw. A person approves it; applying it requires that approval and an unchanged candidate, so a policy that changed after review must be reviewed again. Workloads move from Discover to Monitor to Protect.

  • Demoting a policy requires a reason
  • Rollback returns to a recorded earlier state
  • Every action is written to the hash-chained audit log, with before and after modes
  • The policy applier puts only Protect policies on the cluster and removes the rest

Nothing is enforced until an operator approves and applies a policy. Constellation’s own component NetworkPolicies are a separate chart setting, off by default.

CLUSTER / NETWORK RULESCONSTELLATION
Network rules: Allow, deny and learned network rules for the cluster.Network rules: Allow, deny and learned network rules for the cluster.
Allow, deny and learned network rules for the cluster.

03 / CNIs

Your CNI enforces. Constellation decides.#

Policies render as native Kubernetes NetworkPolicy, CiliumNetworkPolicy or Calico GlobalNetworkPolicy; choose one flavor per cluster. The CNI’s own enforcement is the primary path.

CNI testing status in the alpha
CNIStatusNotes
flannel, kindnetTested live on kind/k3sDo not enforce NetworkPolicy themselves, so isolation by policy has no effect
CalicoTested live on kind/k3sNative or Calico policy flavor
CiliumTested live on kind/k3sNative or Cilium policy flavor; the agent’s inline data plane does not enforce in eBPF mode
EKS, GKE, AKS CNIsUnit-tested onlyNot yet run live
GKE AutopilotNot supportedPrivileged DaemonSets are not allowed

FAQ

Network questions.#

Will Constellation change our network policies on install?

No. The policy applier is installed, but it only applies policies an operator has approved and moved to Protect. #

Where does flow data come from on Cilium?

The agent can read flows from a Hubble relay on Cilium clusters, but connecting it is a manual agent setting today, not a chart value. Plan for it in an evaluation. #

Can we block an external IP?

A block-IP action exists for Cilium clusters. Native NetworkPolicy is allow-list only, so it cannot express it. #

NEXT STEP

Map one namespace first.

Tell AlphaBravo which CNI you run. We will walk through generating and approving a first policy.

Find your next step

12 pages

Tab through results · Enter to open · Escape to close