A pod runs as root.
Its service account can list secrets across the namespace. The base image was pulled from an unofficial registry three releases ago and hasn't been scanned since. Meanwhile the cluster is CIS-non-compliant in seven places nobody has flagged. Every one of those is fine on its own — until an attacker gets shell access on that pod.
The risk of not knowing
If it is not surfaced today, it is exposed today. Attackers do not wait for your quarterly review — and neither do auditors.
The mechanism, not the marketing
- 1
Onam connects to EKS, AKS, GKE, ECS, and self-managed clusters via read-only Kubernetes RBAC or the equivalent cloud service integration.
- 2
The engine evaluates cluster, node, and workload configuration against CIS Kubernetes Benchmark plus Onam's cloud-native container rules.
- 3
Container images referenced by running workloads are scanned for CVEs in base and application layers, correlated with EPSS and CISA KEV.
- 4
Pod-level analysis flags privileged containers, host mounts, root users, missing security contexts, and over-scoped service accounts.
- 5
Findings feed the same attack-path graph as posture and identity, so a vulnerable image on a pod with a permissive service account shows up as one prioritised risk.
Specific outputs, measurable outcomes
Container Security in the real console.
Not a mockup — the actual Onam console on a live demo account, showing exactly what your team sees.
Questions we get a lot
Ready to see Container Security in your cloud?
Connect a read-only role in three minutes. Your first findings surface in under five.