How to avoid Kubernetes security incidents
The State of Kubernetes Security report was released at the end of 2021, but it seems nothing has seemed to change concerning the security of containers and Kubernetes. It even looks like organizations are losing faith. Compared to 44% in 2020, 55% of the survey respondents now say they have delayed or slowed down the deployment of an application into production for one security issue or the other.
Containerization, Kubernetes, and various other cloud-native technologies promise agility and speed in developing and deploying applications. But it looks like organizations are not genuinely harnessing the most authentic benefit of it.
Among the major causes of these security issues are security incidents during runtime (32%) and misconfiguration being the leading cause, 59%.
Let's dive a little deeper and see how these incidents can be avoided.
Misconfiguration
Note that Kubernetes is only a multi-node cluster kernel and the only thing it offers to prevent misconfiguration is enforcing RBAC. There are no policies that limit what the user can actually do.
One way of limiting what a user is allowed to do is by enforcing policies. Open Policy Agent (OPA) can do just that. It acts as a Kubernetes Admission Controller and can therefore ensure that policies cannot be violated. Otomi offers OPA/Gatekeeper and a complete set of policies out-of-the-box. Policies can be customized and activated.
But enforcing policies alone is not enough to prevent misconfigurations. For instance: it can not enforce the way an ingress is configured or if network policies are configured correctly. Creating configuration is still done by people and therefore is error-prone.
The only way to avoid misconfigurations is by defining what configuration is accepted and validating the configuration before it is applied.
In Otomi, we solved this problem by defining a values schema. Users can add or change configuration through a custom API that validates the input and then generates the configuration automatically. The API is applying guardrails so to say. An example: a user can create an ingress for a deployed application using the Web UI and specify network policies:
The API will then generate the configuration for ingress, Istio, network policies, certificates, and DNS:
This way even developers or engineers can safely create configurations without having to be Kubernetes experts and without the risk of creating any misconfiguration that can result in security incidents.
Vulnerabilities in deployed images
Using containers is great because you can create an immutable package for a piece of software and all its dependencies and run it everywhere. But the downside is that a container image is like a time capsule. It does not automatically get updates as new vulnerabilities are discovered.
Scanning container images for known vulnerabilities is a security best practice (although only done by only 44% of developers), but in most cases only done when images are initially pushed to a registry. And this is a problem. The less frequently an image is updated, the bigger the change it can contain a newly identified vulnerability.
Scanning an image upon Pod deployment using a Kubernetes Admission Controller is also not going to mitigate this risk because it will not protect long-running applications.
The only way to make sure all deployed applications are scanned regularly, is by scheduling a scan like once a day and also initially scanning the container images in the registry.
Otomi offers both. You can enable Harbor as a container registry and scan all images using Trivy.
You can also enable KubeClarity and schedule security scans for all deployed images periodically.
Using multiple vulnerability scanners also improves security posture. Second-opinion checkups are just as applicable to cybersecurity as they are in healthcare. One scanner's judgment can never be foolproof right?
Wrapping up
With attacks and vulnerabilities trailing, misconfiguration remains the top security threat for organizations. But organizations are also continuously afraid of the runtime phase of their container lifecycle.
With Kubernetes only being a multi-node cluster kernel without any additional functionality to avoid misconfigurations and runtime container lifecycle, you are on your own to implement mitigating measures, going through the Day-0 and Day-1 effort of selecting, implementing, integrating additional tools, and creating guardrails.
To help organizations avoid reinventing the wheel, we created Otomi. In this post, I showed and explained how Otomi can help to avoid Kubernetes security incidents by providing an API to create validated configurations and offer all the required tools to improve security at runtime.
Join us in our effort or visit our project on Github to get started:
