3 Common Kubernetes Security Risks and How to Prevent Them
When it comes to the security of such a complex system such as Kubernetes, there are many important aspects to consider. In this blog, we describe the most common security risks that cause pain and potential vulnerabilities for operations, security, and development teams. We also share solutions for these risks and outline helpful security tools.
In the past, the insecure ports opened by default were the most common type of Kubernetes security problems. Now, when the Kubernetes community is more mature, occurrences of insecure ports are less frequent. Often, engineers assume that they’re not actively advertising their clusters’ presence. Still, they forget that with tools such as Shodan or Censys, it’s relatively easy to locate ports in their Kubernetes deployments.
For example, Kubernetes uses etcd as its key-value store for all cluster data. The etcd listens on TCP port 2379, and tools such as Shodan index this port when connected to the internet. Attackers can take advantage of the etcd port if it’s not configured for authentication. If the attackers can reach Kubernetes etcd data, they could compromise the entire Kubernetes environment.
To remediate this risk, operations, development, and security teams should try to list the ports that their Kubernetes infrastructure and their services potentially expose to untrusted networks. Practitioners should also check if these ports are properly secured. Devoting additional time to understanding the default security settings of ports in your cluster is time well spent.
It’s important to validate the application code by performing image vulnerability scanning and checking that only expected images are running.
Image vulnerability scanning is usually implemented as a part of CI/CD automation. This practice is becoming a matter of security hygiene when building container images. Alternatively, vulnerability scanning tools could look for new images when they become available in the image registry and then perform the vulnerability check. Examples of vulnerability scanning tools are Clair, Dagda, Harbor, and Qualys.
Check that only expected and up to date images are running, not the ones incorporated in the codebase by mistake. One example would be an image with a name similar but not the same as the desired image name. These images might be doing cryptocurrency mining or performing some other malicious activities while engineers think they have the right image running.
To avoid compromised images, developers and security teams should think about performing the following actions:
- Check that images come from the known registry
- Double-check that your security team approved the base image
- Perform admission control checks
- Do configuration checks in yaml files
Companies that need a high level of security should perform more checks, although every organization should have a culture where developers follow specific DevSecOps rules before committing their code. Organizations should demand that developers and security experts collaborate when defining good security practices to assure that the established processes are followed early in the code development. That collaboration should result in developers being more proactive when facing potential security issues.
A good example of a developers’ awareness is when a build system is routinely scanning dependencies and reporting vulnerable packages. The developers need to take action and upgrade the packages to secure versions. This kind of behavior establishes responsible development practices, which result in a more secure code.
It’s not prudent to expect that security teams can take care of the most security issues related to the ever-increasing code base. Automation addresses the issue of security teams handling rapidly growing applications. The security teams need automation to deal with issues such as port selection for newly developed code.
A combination of developers’ awareness and security automation establishes the right culture to deal with constant security challenges. Enterprises should be aware that when they move to Kubernetes environments, a cultural change that includes a lot of learning and acquiring new skills is needed. Eventually, it results in more secure and productive organizations.
Avoid User Certificates
Another Kubernetes security topic to think about is related to user certificates. Try to avoid assigning certificates to actual Kubernetes users and use enterprise identity management instead. One can never entirely revoke the certificates, and users may leave the organization, which creates a security concern. Administrators can limit what certificates can do but can’t entirely remove them. Managing Kubernetes security is a complex and demanding effort that may result in some certificates being forgotten and left to be potentially exploited in the future.
Kubernetes Security Tools
Operations teams managing Kubernetes infrastructure should expect security issues with new Kubernetes deployments. Every Kubernetes deployment usually comes with some level of security compliance to CIS benchmarks. Some organizations use managed services for Kubernetes security, which simplifies security tasks. Open-source tools for running Kubernetes benchmark tests, such as Kube-Bench, could be of great help to improve the security of Kubernetes deployments.
Improving the security of applications running in Kubernetes environments can be achieved by seccomp profiles. The profiles reduce the actions applications can perform, which results in more secure applications. Managing seccomp profiles can be complicated and difficult, and it’s not always on the top of the list to implement by development teams. For some developers, it could be quite a powerful way to secure applications.
It’s interesting to note that using only the default Docker seccomp profile would make applications much more secure. But Kubernetes doesn’t automatically use that default Docker seccomp profile. That’s when one needs a way to manage seccomp profiles. In the past, applying seccomp profiles were possible through adding annotations to a pod.
The seccomp-operator project is much of an improvement compared to adding annotations and allows managing seccomp profiles in Kubernetes. This tool can learn system calls the application performs and then use the calls to build them into appropriate seccomp profiles. Seccomp-operator makes Kubernetes deployments more secure, but at the time of writing this blog, it’s still not promoted to GA.
In this blog, we reviewed common Kubernetes security problems such as insecure ports, compromised images, and user certificates’ issues. We also described how Kubernetes security could be improved through a change of culture and more open communication between development and security teams practicing DevSecOps. Finally, we outlined several useful Kubernetes security approaches and tools.
We hope you enjoyed this article. To read more, check out the other Novaima technical blogs.