Our best practices to secure Kubernetes execution units

Why do we need to secure Kubernetes execution units?

As the most famous container orchestrator, Kubernetes must be well-secured because it is a target choice for hackers. They could escape from a container to gain more access and full access to your cluster. As a cybersecurity engineer, you must protect your pods and nodes from these threats. Whether you're a SecOps professional, a CTO, or a manager, these recommendations are crucial to safeguard your containerized applications.

What are the best practices to securely deploy execution units?

One of the first steps in securing your cluster is configuring resource usage limitations to prevent denial-of-service attacks and crypto jacking. You must apply a placement policy to prevent a hacker from placing pods wherever he wants. Also, the resources deployed in your cluster must be reduced to only what is necessary.

Finally, you must use RBAC policies for nodes and pods. To protect against container escape, you should add capabilities and run them as unpriviledged.

I configure resources limitation

Recommendation: Limiting resource usage on a cluster.

Kubernetes allows for fine-grained control over resource utilization, which is essential for maintaining system stability and preventing resource exhaustion. Ensure that memory limits are set for workloads, with limits equal to or less than the requested resources. For sensitive workloads, consider setting CPU limits as well.

Risks Addressed: This practice mitigates the risk of resource contention, which could lead to performance degradation or denial of service attacks and cryptojacking on the cluster.

I have kernel protection for my containers

Recommendation: Prevent containers from loading unwanted kernel modules.

Kubernetes nodes should be shielded from unauthorized kernel module loading. Enable Seccomp with appropriate syscalls profiles for programs, and when available, deploy OS-hardening frameworks like AppArmor or SELinux on nodes. Regularly collect and analyze OS logs to detect possible breaches.

Risks Addressed: These measures fortify the node's defense against privilege escalation attacks and malicious kernel module loading, enhancing overall system security.

I apply a placement control policy

Recommendation: Controlling which nodes pods may access.

Effective pod placement is crucial for security. Ensure that pod placement aligns with your applications' sensitivity tiers. Sensitive applications should run in isolation on dedicated nodes using taints and tolerations.

Risks Addressed: Proper pod placement mitigates the risk of sensitive workloads coexisting with less secure ones, reducing the likelihood of data leakage or unauthorized access.

I configure RBAC for my execution units

Recommendation: RBAC rights for workload management.

Restrict RBAC (Role-Based Access Control) rights to create, update, patch, and delete workloads only for those who need them. Utilize RBAC policies to manage users' and services' access to pods within the cluster. Additionally, leverage admission controllers to enforce additional rules based on RBAC.

Risks Addressed: Proper RBAC configuration prevents unauthorized access and modification of workloads, enhancing overall cluster security.

I minimize my resources to only what is necessary

Recommendation: Minimize unnecessary content in container images.

Trim container images to eliminate extraneous applications, libraries, and OS components, reducing the attack surface. Consider provisioning nodes with minimalist Linux distributions, such as Alpine Linux. Eliminate unnecessary user accounts.

Risks Addressed: Reducing the attack surface limits the potential entry point for attackers, making it harder for them to compromise your system.

I run my containers as unprivileged

Recommendation: Controlling what privileges containers run with.

Containers should run with minimal privileges to reduce the attack surface. Configure container images to run as unprivileged users and avoid running anything as root unless strictly necessary. Security contexts can define the privilege level at which pods run.

Risks Addressed: Limiting privileges decreases the likelihood of a compromised container gaining unauthorized access to the host system.

Conclusion

By following the best practices presented in this article, you can significantly reduce the risk of compromising Kubernetes pods and nodes and improve the overall security of your infrastructure.