What we still need to verify : 2 points in this profile are not yet confirmed against vendor documentation.
- Current scanner component and its vulnerability data sources: verify against vendor documentation
- Feature parity between the upstream open source project and the Red Hat product: confirm with vendor
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
The premise is that Kubernetes already knows most of what a security tool needs, so the platform reads the cluster rather than guessing about it. A Sensor per cluster watches the API server for deployments, services, RBAC bindings, secrets and network configuration, and a Collector on each node gathers process and network telemetry from the kernel using eBPF. That lets the product evaluate a deployment in context: not just that an image has a vulnerability, but that a deployment running as root with a writable filesystem and a host mount is also reachable from the internet. Risk is a ranked list of deployments rather than a flat list of CVEs.
Policies are the unit of work, and the same policy is evaluated at more than one lifecycle stage. A rule about privileged containers can fail a CI check, be rejected by a ValidatingWebhook at admission, and alert or kill a pod if it starts running anyway. Network observation feeds a policy generator that proposes NetworkPolicy manifests from traffic actually seen, the most practical route to default deny most teams will find. Image scanning, CIS benchmark evaluation and compliance reporting round it out. The upstream project is open source, with Red Hat shipping the supported product.
Where it fits
Central runs once, Sensor and Collector run in every cluster you want covered, and the operator is a security or platform team. The natural integration points are a CI step that queries policy before promoting an image, an admission webhook in front of each cluster, and alerting into your incident path. It expects a real cluster inventory and someone willing to own the policy set, since the defaults are a starting point rather than a finished posture.
Strengths
- Risk ranking that combines image findings with deployment configuration and exposure gives you an order to work in, not a backlog.
- One policy definition enforced at build, admission and runtime removes the drift of restating rules in separate tools.
- Network policy generation from observed traffic makes segmentation achievable without hand authoring rules per service.
Limitations
- Central plus per-cluster components is real infrastructure to run and upgrade, and Collector's kernel telemetry needs compatibility attention.
- Runtime detection is rule driven, so tuning is required before enforcement is credible, and untuned policies generate noise.
- The value is concentrated in Kubernetes. Workloads outside the cluster fall outside its view.
Who it suits
A strong fit for organizations standardized on OpenShift, and for teams running multiple Kubernetes clusters that want posture, admission control and runtime detection from one policy model. Less compelling for a single small cluster, where operational weight outweighs benefit, and not the tool to reach for if your estate is mostly outside Kubernetes.
Used Red Hat Advanced Cluster Security (StackRox)? Recommend it under your own name and title.
Recommend this tool