Security Best Practices for Kubernetes Pods

Nowadays I came across many articles, blogs, and wikis where peers talk about Kubernetes configuration best practices, Kubernetes production best practices, Your guide to Kubernetes best practices, and many more. So, here I am with this blog which will bring an add-on or icing to the cake which is baked already.
Precisely, if you follow me here, I am gonna guide you and help you with quick tips, so that one can bring security best practices for Kubernetes clusters pods and containers.

Kubernetes provides many controls that can greatly improve your application security. Configuring them requires practical knowledge of Kubernetes and the deployment’s security requirements. The best practices highlighted here are aligned to the container lifecycle: build, ship, and run, and are specifically tailored to Kubernetes deployments or containers. Just to mention, these practices are predominantly adopted in our own SaaS deployment.

Here, we are going to see the foremost security best practices and learn how these can be embedded in deployment.YAML file. So, without any further adieu lets quickly bring icing to the cake ;-)

#1 Apply Security Context to Pods and Containers

The security context defines privilege and access control settings for your Pod or Container. SecurityContext holds a security configuration that will be applied to a container.

Well-defined privilege and access control settings will enhance assurance your pod is running strictly with the properties it requires to function.

#2 Containers should not run with allowPrivilegeEscalation

The AllowPrivilegeEscalation Pod Security Policy controls whether or not a user is allowed to set the security context of a container to allowPrivilegeEscalation=true. Setting it to false ensures that no child process of a container can gain more privileges than its parent, Setting allowPrivilegeEscalation=false ensures RunAsUser commands cannot bypass their existing sets of permissions.

#3 Containers should run as a high UID to avoid host conflict

To prevent privilege-escalation attacks from within a container configure your container’s applications to run as unprivileged users. The mapped user is assigned a range of UIDs that function within the namespace as normal UIDs from 0 to 65536 but have no privileges on the host machine itself.

#4 CPU requests and limits should be set

CPU quotas are used to ensure adequate utilization of shared resources. A system without managed quotas could eventually collapse due to inadequate resources for the tasks it bares. Kubernetes allows administrators to set CPU quotas, in namespaces, as hard limits for resource usage.

#5 Ensure that Service Account Tokens are only mounted where necessary

ServiceAccount is an object managed by Kubernetes and used to provide an identity for processes that run in a pod, With this token one can prevent an attacker to easily impersonate the service account and use REST APIs.

#6 Ensure that the seccomp profile is set to docker/default or runtime/default

Secure computing mode (seccomp) is a Linux kernel feature. It can be used to restrict the actions available within the container. The seccomp() system call operates on the seccomp state of the calling process.

#7 Liveness and Readiness Probe Should be Configured

Readiness Probe is a Kubernetes capability that enables teams to make their applications more reliable and robust. Using the Readiness Probe ensures teams define what actions need to be taken to prevent failure and ensure recovery in case of unexpected errors.

The kubelet uses liveness probes to know when to schedule restarts for containers. Restarting a container in a deadlock state can help to make the application more available, despite bugs.

#8 Memory requests and limits should be set

When specifying the resource request for Containers in a Pod, the scheduler uses this information to decide which node to place the Pod on. Without this limit, kubectl will attempt to allocate more memory to this container until it runs out. Additionally, setting memory requests enforces a memory limit to a Container. A Container is guaranteed to have as much memory as it requests but is not allowed to use more memory than its limit

#9 Minimize the admission of root containers with NET_RAW and customized assigned capability

Containers rely on the traditional Unix security model granting explicit and implicit permissions to resources, through permissions granted to users and groups. Containers that run as root have far more permissions than their workload requires. In case of compromise, an attacker can use these permissions to further an attack on the network

By default with Docker as the container runtime, the NET_RAW capability is enabled which may be misused by malicious containers. Thus, it is recommended that at least one PodSecurityPolicy (PSP) defined which prevents containers with the NET_RAW capability from launching

Limiting the admission of containers with capabilities ensures that only a small number of containers have extended capabilities outside the default range. This helps ensure that if a container becomes compromised it is unable to provide a productive path for an attacker to move laterally to other containers in the pod

#10 Use read-only filesystem for containers where possible

Enabling read-only filesystem for containers option forces containers at runtime to explicitly define their data writing strategy to persist or not persist their data. This also reduces security attack vectors since the container instance’s filesystem cannot be tampered with or written to unless it has explicit read-write permissions on its filesystem folder and directories

P.S- Kubernetes supplies many options to create a secured deployment. There is no one-size-fits-all solution that can be used everywhere, so a certain degree of familiarity with these options is required, as well as an understanding of how they can enhance your application’s security at each & every place we can make our k8 cluster secure implicitly or explicitly such as implementing network segmentation, log analytics, integrating with server monitoring tools and many more and lastly, Always to keep in mind with YAML scripting keen focus needs to be made on indentation aspects as per YAML scripting guidelines and file must be validated before the execution of it.

Summary

Implementing these best practices that were highlighted in this blog, and using these Kubernetes flexible configuration capabilities to incorporate security processes into the continuous integration pipeline, automating the entire process with security seamlessly “baked in” makes your deployment system anti-vulnerable.

Last but not least, If this article was helpful for you, please share it with your friends and colleagues!

Happy learning folks! :-)