Kubernetes Security: The Ultimate Guide to Penetration Testing and Best Practices for Securing Your Cluster

Kubernetes Security: The Ultimate Guide to Penetration Testing and Best Practices for Securing Your Cluster

Protect Your Kubernetes Environment from Hackers with Expert Tips on Restricting Pod Communication, Seccomp Profiles, and Linux Capabilities Whitelist

Play this article

When it comes to securing your Kubernetes cluster, there are several best practices that you should implement to protect your applications and data from potential threats. In this blog post, we will discuss three key areas to focus on when securing your cluster: pod-to-pod communication, Seccomp profiles, and Linux capabilities.

Kubernetes penetration testing

Kubernetes penetration testing is the process of intentionally attacking a Kubernetes cluster to identify vulnerabilities and weaknesses in its security posture. This type of testing is done to help organizations understand the security risks of their Kubernetes deployments and take proactive steps to address them before they can be exploited by malicious actors.

As the use of Kubernetes for container orchestration continues to grow, the need for robust security measures becomes increasingly important. A successful penetration test can uncover potential vulnerabilities in a Kubernetes cluster, and the recommendations provided in the test report can serve as a roadmap for improving the overall security posture of the system. In this blog post, we will focus on three specific recommendations from a recent Kubernetes penetration test and provide practical guidance on how to implement these security best practices.

Restrict Pod-to-Pod Communication

The first recommendation from the penetration test is to only allow pod-to-pod communication as needed by the application. By default, Kubernetes allows pods to communicate with each other, which can lead to unauthorized access or data leakage. To restrict this communication, network policies should be defined to limit the traffic between pods.

One way to achieve this is to use the Kubernetes NetworkPolicy resource, which allows the cluster administrator to specify the desired network rules for pods. For example, a network policy can be created to only allow traffic between specific pods or namespaces. This can be achieved by setting the "podSelector" and "namespaceSelector" fields in the NetworkPolicy manifest file.

Use Seccomp Profiles

The second recommendation is to make Seccomp profiles required for any pod that needs to run in the cluster. Seccomp (Secure Computing Mode) is a Linux kernel feature that allows the administrator to restrict the system calls that can be made by a process. This can help to limit the impact of any potential vulnerabilities in the running pod.

To implement this recommendation, a Seccomp profile should be defined for each pod. The Seccomp profile can be included in the pod specification file using the "securityContext" field. It is recommended to use a default profile or create a custom profile based on the specific needs of the application.

Enable Linux Capabilities Whitelisting

The third recommendation is to disable all Linux capabilities and enable only the ones that are needed by the application. Linux capabilities are special privileges that allow processes to perform certain privileged operations. By default, Kubernetes blacklists some capabilities, but this can still leave the system vulnerable to privilege escalation attacks.

To implement this recommendation, a whitelist of capabilities should be defined for each pod. This can be achieved by setting the "capabilities" field in the pod specification file. It is recommended to use the minimum set of capabilities required by the application to limit the attack surface.


In conclusion, implementing the above three recommendations from the Kubernetes penetration test report can significantly improve the security of a Kubernetes cluster. By restricting pod-to-pod communication, using Seccomp profiles, and enabling Linux capabilities whitelisting, the cluster can be better protected against potential threats. As always, it is important to stay vigilant and keep up-to-date with the latest security best practices to maintain a secure and resilient Kubernetes environment.

Bonus: Hands-On/How To

Download the source code from here.

How to restrict pod-to-pod communication in Kubernetes

  1. First, create two pods using the Busybox image. The first pod (client) will be used to send a curl request, and the second pod (server) will run an httpd server to serve HTML files.

  1. Next, create a Kubernetes service for the server that exposes the httpd server on port 80.

  1. Now, create a network policy that only allows the client to communicate with the server on port 80.

  1. Finally, log in to the client pod and send a curl request to the httpd server running on the server pod.
kubectl exec -it pod1 sh
curl http://<pod2-ip-address>

Note that the curl request will fail if the network policy is working correctly because it only allows communication between the client pod and the server pod on port 80. By restricting pod-to-pod communication in this way, you can significantly improve the security of your Kubernetes cluster.

How to specify a custom Seccomp profile

To specify a Seccomp profile and enable Linux capabilities whitelisting in a pod include a specification like the following example:

In this example, we're creating a pod named "my-rebel-pod" with a container named "my-rebel-container" using a busybox image.

To specify a custom Seccomp profile, we've included a securityContext section with a seccompProfile sub-section. The type is set to "Localhost", which means that the profile will be loaded from the local host machine. The localhostProfile field specifies the name of the Seccomp profile we want to use, which in this case is my-rebel-seccomp-profile.json.

Next, we've added a "command" section to specify the command that will be run in the container. In this case, the command is simply to print "Hello, World!".

Finally, we've enabled Linux capabilities whitelisting by including another securityContext section with a "capabilities" sub-section. We've dropped all capabilities using the "drop" field and then whitelisted the "NET_ADMIN" and "SYS_TIME" capabilities using the "add" field. This means that the container will only have access to the whitelisted capabilities and all other capabilities will be dropped.

By specifying a custom Seccomp profile and enabling Linux capabilities whitelisting, you can further secure your pods in Kubernetes and limit the capabilities that containers have access to.

Don't be a container without protection - join the conversation! Leave a comment, share your thoughts, and subscribe to our mailing list to stay up-to-date on the latest Kubernetes best practices, hands-on labs, recommendations, and examples.

Download the source code examples from here.

Did you find this article valuable?

Support La Rebelion Labs by becoming a sponsor. Any amount is appreciated!