Container & Kubernetes Security

Onam's Container Security engine evaluates every container surface in your cloud — Kubernetes clusters (EKS, AKS, GKE, OKE, IKS, ACK, self-managed), ECS task definitions, container registries, and the workloads running on top — without installing anything on your nodes. The output is a prioritized list of cluster-takeover risks, workload misconfigurations, image vulnerabilities, and missing network controls, mapped to CIS and NSA/CISA hardening guidance.

This page covers the six coverage surfaces, the scan pipeline, Kubernetes RBAC analysis, Pod Security Standards, NetworkPolicy coverage, and image/supply-chain checks.

Coverage at a Glance

The Kubernetes attack surface is uniquely large: every cluster has a control plane, a workload plane, an image supply chain, an RBAC system, and a network policy system. A single weak default in any one of them gives an attacker who compromises one pod a path to every other pod. Onam covers six surfaces, and once a cluster is connected every applicable check runs on every scan — surfaces are not enabled individually.

Supported Platforms

The Kubernetes rule set — 718 rules across 51 resource kinds in Onam's master registry — applies across every supported distribution. ECS is covered via task-definition analysis.

How the Security Check Works

Every scan runs three stages: discover cluster state, evaluate against rule catalogs, emit prioritized findings. No agents on nodes — every check uses your read-only kubeconfig or IAM-based cluster access.

1. Discovery. Onam reads cluster state through the Kubernetes API server with your read-only credential: Pods, Deployments, Services, Roles, RoleBindings, NetworkPolicies, Namespaces, ConfigMaps (Secret references only — never values), Nodes, and the images running on each. In parallel, container registries are scanned for image inventory.
2. Evaluation. Three rule catalogs apply: the CIS Kubernetes Benchmark v1.8 (112 controls), NSA/CISA Kubernetes Hardening Guidance (2024 edition), and custom rules — YAML rules you define for org-specific policies via the Rule Builder.
3. Findings. Output is categorized into RBAC findings (over-privileged service accounts, cluster-admin bindings), workload findings (privileged pods, missing limits), network findings (no policies, exposed services), and image findings (CVEs, unsigned images). Each is severity-graded and CIS-mapped.

Kubernetes RBAC Analysis

RBAC misconfiguration is the single most common path to cluster compromise. Onam traces the full chain — service account, RoleBinding, Role, effective verbs × resources × apiGroups — and computes the resolved effective permission set per service account.

The five high-risk patterns flagged:

Worked example: ClusterRoleBinding dev-admin grants cluster-admin to service account default/app-runner in namespace production — a Critical finding. Suggested fix: create a least-privilege ClusterRole limited to the permissions the app actually used in the last 90 days, bind that, then remove the cluster-admin binding.

Pod Security Standards

Every pod is graded against the official Kubernetes Pod Security Standards (the replacement for the deprecated PodSecurityPolicy):

Findings are tagged with the violated level, so you can roll out enforcement via your admission controller (Kyverno, OPA, or native Pod Security Admission) without trial and error.

Network Policy Coverage

By default, Kubernetes allows all pod-to-pod traffic across the cluster. Without NetworkPolicy resources there is no firewall between pods — one compromised pod can reach every database, queue, and admin service in the namespace.

What Onam flags:

• Namespaces with zero NetworkPolicy resources — likely never configured
• Pods with no matching NetworkPolicy — policies exist but selectors miss the pod
• Unrestricted egress — pods that can reach the internet, a precursor to exfiltration paths
• Cluster-wide allow-all policies — usually added during debugging and never removed

The fix is rarely "deny everything". Onam suggests policy templates based on the traffic that actually flows in the namespace, derived from VPC Flow Logs or service-mesh telemetry where available.

Image Security

Images are scanned in two contexts — at rest in registries and at runtime in the cluster — for four classes of issues:

Supported registries: ECR (AWS), ACR (Azure), GCR / Artifact Registry (GCP), OCIR (OCI), Docker Hub, GitHub Container Registry, and Quay. If your CI pipeline signs images at build, Onam verifies the signature is intact at deploy time and flags tampered images at runtime.

CIS Kubernetes Benchmark Coverage

Findings map to the CIS Kubernetes Benchmark v1.8 — 112 controls in six sections. New CIS versions are added within 60 days of publication; previous versions stay available for migration.

CIS coverage is a strict subset of the broader rule catalog — a finding usually carries CIS, NSA, and custom-rule mappings simultaneously.

Key Findings to Prioritize

Re-grade per finding type in Settings → Container Security → Severity Policy.

API

# List container security findings
GET /api/v1/container-security/findings?provider=aws&severity=CRITICAL

# Get findings for a specific cluster
GET /api/v1/container-security/findings?resource_uid=arn:aws:eks:us-east-1:123456789012:cluster/prod

Full schemas are in the API reference. Webhook delivery on new Critical findings can be configured under Settings → Notifications.

FAQ

Does Onam install anything on my nodes? No. Cluster state is read via the Kubernetes API with read-only credentials. No DaemonSets, no sidecars, no node agents.

How does Onam get image-CVE data without a scanner inside the cluster? Registries are scanned at the registry level; the cluster only tells Onam which images are deployed where, and the registry tells Onam what's inside them via SBOM generation and CVE matching.

Can I scan air-gapped clusters? Yes. A connector mode runs a small read-only collector in your network that forwards cluster state. Image scanning still requires registry access — typically your internal registry mirror.

Does Onam support Pod Security Admission (PSA)? Yes. PSA labels on namespaces are read and reflected in findings — namespaces enforcing restricted produce fewer findings than namespaces enforcing privileged.

What about service mesh (Istio / Linkerd)? VirtualServices, DestinationRules, and AuthorizationPolicies are read alongside core resources; mTLS posture and authorization-policy gaps surface as findings.

Can I export the cluster topology? Yes — namespaces, workloads, services, the RBAC graph, and network policies export as JSON for incident-response runbooks.

Next steps

• Onboard a Kubernetes cluster — connect EKS, AKS, GKE, or self-managed clusters
• Vulnerability Management — how image CVEs are prioritized
• IaC Scanning & SecOps — catch pod-spec and Helm issues before deploy
• Network Security — the cloud-network side of cluster exposure