Kubernetes is a portable, extensible, open-source platform for managing containerized workloads and services that facilitates both declarative configuration and automation.
In the past months, multiple critical security flaws have been found and patched on this Google open-source project. However, the most dangerous threat against this platform is the users themselves.
Researchers from Unit 42 (A global threat intelligence team at Palo Alto Networks®) have periodically scanned and analyzed unsecured Kubernetes clusters on the internet. Between October 2020 and February 2021, they identified 2100 unsecured Kubernetes clusters that can be accessed anonymously by anyone.
The following are best practices and recommendations to guarantee greater security in such a critical part of the computer infrastructure.
Use Minimal Base Images
Consider using minimal images such as distroless, which contain only your application and its runtime dependencies. They don’t have package managers, shells, or any other programs that could contain unknown vulnerabilities.
Don’t add unnecessary components.
Make sure to remove debugging tools and components that may be useful to attackers. For example, Curl (a library and command-line tool for transferring data using various network protocols)
Integrate security in your workflow
Create a security plan covering alerts, backups, and strategies in case CI deployments fail or being victims of direct attacks. Identify vulnerabilities in OS packages and third-party libraries using image scanners.
Implement policies and protocols to follow before, during, and after attacks or when finding a vulnerability.
Enable Role-Based Access Control (RBAC)
Kubernetes use RBAC for authorization to control who can access the Kubernetes API and what permissions they have—for example, giving access to a user, adding or removing permissions, and setting up rules. Please Double-check your settings as they may be enabled by default.
Avoid giving anyone clutter admin privileges; it is more secure if privileges are granted on a case-by-case basis.
Separate sensitive workloads
Due to the power of Kubernetes, we want to put everything in the same machine. Bad Idea! To limit the potential impact of a security breach, we have to separate workloads on dedicated machines. This way, we ensure that less-secure applications become gateways to applications with sensitive information.