Securing container platforms
Kubernetes gives your team a lot of power — and with that comes a lot of ways to get security wrong. Default configurations are rarely secure enough for production, and as clusters grow, the gap between “it works” and “it’s hardened” tends to widen quietly.
During a container platform check I review your platform setup against security best-practices. The review covers:
- Container Capabilities
- Pod Specification Files & Configs
- Master Node Settings (API-Server, Controller Manager, Scheduler)
- Control Plane Configuration
- Worker Node & Kubelet Settings
- Encryption (data-in-transit & data-at-rest)
- Key Management
- Etcd Settings & Secret Management
- Pod Isolation (Namespace Isolation Policies)
- Ingress/Egress Routing
- RBAC Policies & Service Accounts
- Seccomp Profiles
- Logging & Monitoring
- DFIR-Readiness (Digital Forensics & Incident Response)
- Component & API Versions
I combine the latest CIS benchmark tests with my pentesting experience in container-based environments. This means findings are prioritized by real-world exploitability, not just compliance checkboxes.
Review of container images
Optionally, this platform check can also cover the container images themselves. I analyze them against containerization security best-practices — checking for security misconfiguration, vulnerable components inside the images, and how these images are built and distributed. Base image selection, layer hygiene, and whether secrets accidentally ended up baked into an image layer are all part of this analysis.
Review of cloud environments
Container orchestration platforms rarely exist in isolation — they typically run inside cloud environments like AWS, Azure, GCP, or OTC. The cloud layer brings its own set of security concerns (IAM, networking, storage visibility) that interact with the container platform configuration. For reviewing the security of the surrounding cloud environment, I offer a separate Cloud Security Check that pairs well with this container review.
Detailed reporting
The resulting report of the found security issues includes detailed descriptions of the findings (along with all evidence collected) and mitigation advice to remediate each issue and tips to further harden your application. To better distribute the individual findings towards the relevant parties, I categorize all findings by function (business, architecture, development, operations) to which the finding applies.
After sending the report, an on-site or remote debriefing meeting will be arranged to further discuss the report and any potential questions along with the team members assigned to remediate the findings.
This process can optionally be followed by a second check of remediated findings, which leads to an updated report.
Prerequisites
This kind of security check requires access on high-privileged level to the container platform environment in order to review its security. Also access to the container build and manifest files is required to check the container design from a security perspective.
It is helpful to get some information upfront about your architecture and desired container setup in order to let the review be as targeted as possible. This also includes some high-level information about your architecture, as what components are used and what kind of data (in terms of sensitivity) is handled on which component.
This information is usually provided and discussed in a kick-off workshop (remote or on-site) at latest a few days before the review begins.