One operator. Observe, Segment and Respond on the same map.
Axera is a single Red Hat certified operator that installs the agents, the telemetry store, the policy engine and the console. The same live picture of traffic drives every edition.
What gets installed
Five parts, one custom resource. Everything runs inside your clusters.
Operator
A Red Hat certified operator that installs and upgrades the whole platform from one Axera custom resource, on OpenShift, or on any Kubernetes via Helm.
Agents (flow, process, OneBox)
Kernel-level (eBPF) agents that record connections and the processes that open them, per cluster, with no sidecars and no change to your network plugin (CNI). OneBox bundles both agents in a single DaemonSet.
Telemetry store
Flows and process events stream over Kafka into PostgreSQL you control, external for production or in-cluster for evaluation.
Policy engine
Turns observed traffic into Kubernetes NetworkPolicy and Istio AuthorizationPolicy, versions every change, and drives containment during an incident.
Console
One web console for topology, policy lifecycle, incidents and response, with role-based access and a full audit trail.
Where Axera fits, and where it does not.
Four ways teams handle Kubernetes network security today. Each column describes a category, not a named vendor, and each has a job it does well.
| Capability | Axera | Hand-written NetworkPolicy | CNI-vendor enterprise | Cloud CNAPP |
|---|---|---|---|---|
| Where it runs | Self-hosted in your clusters; air-gapped supported | In the cluster (it is the cluster's own object) | Self-hosted, tied to that vendor's CNI | Vendor cloud control plane; agents report out |
| Network plugin (CNI) support | Any CNI: OVN-Kubernetes, Cilium, Calico and more | Any CNI that enforces NetworkPolicy | That vendor's CNI only | Any CNI for visibility; enforcement varies |
| Policy written from real traffic | Yes: generated, reviewed, versioned, rolled back | No: written and maintained by hand | Often, in the vendor's own policy format | Recommendations, usually applied elsewhere |
| Service mesh coverage | Istio ambient and sidecar policy from the same map | Separate mesh policy, maintained by hand | Vendor-specific, often application-layer only | Typically visibility only |
| Detection and verified response | 18 detectors mapped to MITRE ATT&CK; containment verified against live traffic | None | Some runtime detection; response is usually manual | Broad detection; containment is often a separate product |
| Catch a bad policy before it ships | Yes: scans Git repositories and recommends policy pre-live | Only with your own CI checks | Varies by vendor | Infrastructure-as-code scanning is common |
| Cloud posture and image scanning | Not a focus; pairs with the scanner you already run | No | Rarely | Yes, this is its core strength |
These are category descriptions, not claims about a specific vendor. If you run a tool we have described unfairly, tell us and we will fix the row.
Built for the sectors that cannot afford a breach, or a cloud dependency.
Banking
Contain lateral movement between payment, core-banking and customer-data workloads, and prove segmentation and detection to auditors.
Insurance
Protect PII and claims systems with least-privilege policy and process-level detection, self-hosted, with no data leaving the perimeter.
Public sector
Air-gapped-ready segmentation and NDR for sovereign and regulated government workloads.
Telecom
Segment multi-tenant platforms and detect east-west threats across large, multi-cluster estates.