16-07-2025
Container Security Testing: QA Strategies For Kubernetes And Beyond
Margarita Simonova is the founder of
It should come as no surprise that container orchestration platforms like Kubernetes now dominate production environments. Their ability to offer scalability, high availability, standardization, efficiency and automation makes them essential. But with this popularity comes the responsibility of quality assurance (QA) teams to enforce robust security solutions to safeguard these platforms.
Securing container platforms involves such activities as scanning images, validating configurations and simulating attacks. In this article, we will take a close look at these practices so we can ensure that our container security is rock solid.
Image Scanning
The first activity that QA teams can perform is scanning container images for known vulnerabilities. Containers can include a number of weaknesses such as hardcoded credentials, outdated software libraries and packages with known vulnerabilities. Scanning can help weed out these issues before and after the deployment of containers.
Image scanning works by first unpacking the images by layers. Then it can inspect files, OS packages and libraries to make matches against the common vulnerabilities and exposures (CVE) database. If vulnerabilities are found, containers can be flagged as not meeting security thresholds. Some popular image-scanning tools include Trivy, Clair and Anchore. With these tools in your CI/CD pipeline, you can automatically detect vulnerabilities.
It's important to start scanning as early as possible in the CI/CD process. Integrating security early on in the process is referred to as 'shifting left' and involves starting to scan from base images and any included dependencies. It's also critical to keep scanning even after deployment because new vulnerabilities are always being added to the CVE. With a regular image-scanning schedule and a tool that is continually updated, your container security testing habits will be off to a great start.
Validating Configurations
In addition to scanning container images for known vulnerabilities, it is also crucial to check for proper configurations. Improperly configured containers can open an organization up to a wide range of issues. First of all, misconfigurations can lead to security risks, which may result in data leaks. Misconfiguration can also lead to stability issues, such as resource exhaustion that slows or halts a system. One more issue is noncompliance, which can result in failing to comply with standards such as NIST benchmarks.
There are several common areas to check for misconfigurations in a containerized environment. First are container-level configurations, such as the use of privileged mode, missing definitions for resource limits, read-only root file systems and hardcoded secrets in ENV variables. At the image level, some configurations to check include whether trusted base images are signed, whether the OS layer is minimal and whether there are no multistage builds or latest tags. Orchestration-level configurations that need to be checked include network policies, namespace isolation and whether audit logging is enabled. One more issue relates to configuring security controls, including whether containers are running as root, whether SSL has been enabled and whether secrets are being properly managed.
A good way to address configuration errors is to adopt a declarative policy-as-code (PaC) framework. This means turning policies into a machine-readable format that can be applied during development, deployment and runtime. PaC can enforce consistency, transparency and the auditability of policies. Two popular PaC tools are Open Policy Agent and Kyverno. These tools help enforce best practices, such as using non-root containers, following the principle of least privilege, checking for network segmentation and failing builds that violate policies.
Simulating Attacks
Penetration testing (pentesting) for container orchestration goes beyond just scanning for vulnerabilities; it actually simulates an attack by exploiting found vulnerabilities. This type of invasive test is useful because it uncovers critical weaknesses that may have slipped through an organization's other controls. It also lets a container administrator see how their entire ecosystem is viewed externally from the viewpoint of an attacker. That includes any reconnaissance an attacker would perform through open-source intelligence or direct social engineering simulations on employees.
When pentesting container orchestration, some Kubernetes-specific issues need to be looked out for. To start, misconfigured role-based access control (RBAC) and authentication can be a big issue. Pentesting can try to enumerate service accounts and roles, check for over-privileged cluster-admin access, exploit the impersonate verb on roles and attempt token theft. Another issue is API server exposure. To address this, pentesting can check for open authentication endpoints or try to bypass namespace boundaries. One more big threat is insecure etcd access because the entire Kubernetes cluster state is stored there, including secrets. Pentesting can try such actions as getting into etcd without authentication, attempting to extract secrets and trying to perform write operations.
A pentest will further attempt to gain persistent access to a network once it has found a vulnerability to exploit. When performed by a professional third-party organization, a comprehensive report will be given at the end that offers advice on patching the container orchestration and often includes follow-up tests that can be performed once recommended actions have been taken.
Why It's Timely
With 90% of organizations running containerized workloads by 2025 and supply-chain attacks on the rise, QA teams need specialized container security testing to prevent breaches and ensure compliance. The threat landscape is only growing larger as attackers use more sophisticated tools and artificial intelligence (AI) to become even more dangerous.
Organizations will need to step up their game to always stay one move ahead of threat actors. This will involve thorough testing and using even more sophisticated tools than attackers have access to. This will be especially important for organizations that operate in industries with strict regulatory and compliance pressures.
Conclusion
By paying attention to the aspects of container security covered here (image scanning, validating configurations, simulating attacks), QA teams can be assured that they are following best practices to keep container orchestration as secure as possible. So, let's take a proactive approach to security and follow these guidelines to keep our container orchestration operating smoothly and without interference from threats.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
