Cloud, Network & Identity Security
Kubernetes and container security
Assessment of Kubernetes clusters, container images and registries: RBAC, network policies, workload hardening, secrets and supply chain.
- Platforms
- Amazon EKS, Azure AKS, Google GKE, OpenShift and self-managed Kubernetes; Docker
- Approach
- Configuration review with read-only access, plus optional in-cluster attack testing
- Reference standards
- CIS Kubernetes Benchmark, NSA/CISA Kubernetes Hardening Guidance, OWASP Kubernetes Top 10
- You receive
- Prioritised findings report, benchmark results, debrief and optional re-assessment
Overview
About kubernetes and container security
Kubernetes makes it easy to run software at scale, and just as easy to run it insecurely. Over-privileged service accounts, containers running as root, no network policies, exposed dashboards and vulnerable base images are some of the most common findings in modern infrastructure.
Our Kubernetes and container security assessment reviews the cluster, the workloads running in it and the images and pipeline that produce them. It extends our cloud security assessment into the container layer, and can be combined with it in a single engagement.
A typical starting point
You run workloads on Kubernetes (EKS, AKS, GKE or self-managed) or Docker and want the cluster and images reviewed independently.
What’s covered
What we review in your clusters and images
Area 01
Cluster configuration
- API server exposure and authentication
- Control plane and node settings against the CIS Kubernetes Benchmark
- Audit logging and its retention
- Exposed dashboards and management interfaces
Area 02
Access control
- RBAC roles and bindings, checked against least privilege
- Service account permissions and token handling
- Integration with cloud IAM (IRSA, Workload Identity)
- Paths for privilege escalation within the cluster
Area 03
Workloads and runtime
- Privileged containers, root users and host access
- Pod Security Standards and admission control
- Resource limits and namespace isolation
- Network policies and east-west traffic controls
Area 04
Images and supply chain
- Vulnerable packages in container images
- Base image choice and update practices
- Registry access and image signing
- Secrets in images, environment variables and manifests
- Helm charts and Kubernetes manifests in your repositories
The security problem
Kubernetes and container risks
Over-permissive RBAC
Service accounts and users with cluster-wide rights can be used to take over the whole cluster.
Privileged and unrestricted workloads
Containers running as root, with host access or without security policies, make escaping the container easier.
No network policies
Without network policies, any compromised pod can talk to every other service in the cluster.
Vulnerable images and supply chain
Images with known vulnerabilities, or pulled from untrusted sources, bring risk into production.
Our approach
How a Kubernetes security assessment is carried out
Step 1: Scoping
We agree the clusters, namespaces, registries and pipelines in scope, and your priorities.
Step 2: Read-only access
You provide a read-only role for the cluster and access to the relevant registries and repositories.
Step 3: Automated benchmark checks
We run established open-source tools such as kube-bench, Trivy and kubescape to check configuration and images at scale.
Step 4: Manual review
We review RBAC, network design, workload configurations and pipeline steps that tools cannot judge on their own.
Step 5: Attack-path testing (optional)
Starting from a compromised pod, we test how far an attacker could move within the cluster and into the cloud account.
Step 6: Reporting and debrief
Findings are ranked by real exposure and walked through with your platform team.
Standards and references we work to
- CIS Kubernetes Benchmark
- Consensus configuration baseline for Kubernetes components.
- NSA/CISA Kubernetes Hardening Guidance
- Government guidance on hardening Kubernetes clusters.
- OWASP Kubernetes Top 10
- The most common Kubernetes security risks.
- CIS Docker Benchmark
- Baseline for Docker hosts and container configuration.
- MITRE ATT&CK for Containers
- Used to describe attacker techniques demonstrated during testing.
Good to know
Image scanning alone is not container security
Scanning images for vulnerable packages is valuable, but most serious Kubernetes compromises come from configuration: excessive permissions, privileged pods and missing network policies. Our assessment covers both.
What you receive
What you receive from a Kubernetes review
Executive summary
Overall platform posture and the most significant exposures.
Prioritised findings
Each issue with affected resources, risk rating, benchmark reference and remediation, with example manifests where helpful.
Benchmark results
Pass and fail results against the CIS Kubernetes Benchmark, useful as audit evidence.
Debrief
A working session with your platform and DevOps teams.
Re-assessment summary
If in scope, confirmation that fixes are effective.
Sample finding
A workload can take over its worker node
Cluster prod-eks, namespace reporting, deployment pdf-renderer
Kubernetes Pod Security Standards (Restricted); MITRE ATT&CK T1611 Escape to Host
- What we found
- The pdf-renderer workload runs as a privileged container with the host file system mounted.
- Evidence
- From a shell in the pod (granted for testing), we read files on the underlying node, including kubelet credentials. Manifests and command output attached.
- Business impact
- A vulnerability in this one service would let an attacker escape to the node and move across the cluster.
- Fix
- Remove privileged mode and the host mount, run as non-root with a read-only root file system, and enforce the Restricted Pod Security Standard on the namespace.
- Status
- OpenFix in progress
Before we start
What we need to review your clusters
- A read-only Kubernetes role (for example, a ClusterRole with get, list and watch) for each cluster in scope.
- Read access to the container registries and the repositories holding manifests or Helm charts.
- A platform or DevOps contact who knows the architecture.
- For optional attack-path testing, an agreed test namespace and written authorisation.
Not sure you have everything?
We confirm exactly what Kubernetes and container security needs from your side during the scoping call, before any work is agreed.
Book a scoping callFAQ
Questions about Kubernetes and container security
Still have a question?
Ask about scope, timing or cost for Kubernetes and container security, even if you are not ready to commission work yet.
Contact our teamWill the assessment affect running workloads?
No. The core assessment only reads configuration. Optional attack-path testing runs in an agreed test namespace under written rules of engagement.
Do you support managed Kubernetes services?
Yes: Amazon EKS, Azure AKS and Google GKE, as well as OpenShift and self-managed clusters. For managed services we focus on the parts you control, as the provider manages the control plane.
Can you help us fix what you find?
Yes. Findings include example configuration, and we can advise your team as they apply fixes and verify them afterwards.
Should this be combined with a cloud security assessment?
Often, yes. Kubernetes permissions are frequently linked to cloud IAM, and the most serious attack paths move between the two. A combined engagement covers both.
Related services
Often combined with Kubernetes and container security
Talk to us about kubernetes and containers
Tell us what has prompted the conversation. We will reply to arrange a short, no-obligation scoping call for Kubernetes and container security.