By Julien Sobrier, Head of Product, Octarine
Date: May 6, 2020
Kubernetes adoption in the enterprise continues to soar. Enterprises have been eager to gain the flexibility and scalability it provides to streamline their DevOps processes, but with that comes new risks. “I have to know so many things about so many things” is a direct quote from an Octarine customer who has expressed worry about the Kubernetes security and compliance risks he’s now responsible for. We’ve heard the same refrain countless times.
Kubernetes security continues to be the top concern for users, but information on the risks has been lacking. That’s why we were pleased to see that the Azure Security team at Microsoft produced the first-ever Kubernetes attack matrix.
It includes the major techniques that are relevant to the security of container orchestration overall with a focus on Kubernetes:
Photo credit: Microsoft.com
Here is what Octarine takes care of for you, and we’ll dig into a few key areas to explain the attack vectors:
The first question in the security review of your Kubernetes cluster is: what is the initial access point to attack my cluster? It’s very common to deploy monitoring solutions such as the Kubernetes Web UI Dashboard or Prometheus. These applications have access to all Kubernetes workloads, often with the ability to create and delete pods, modify RBAC, etc. Accidental exposure of these applications would allow an attacker to run its own malicious container inside an organization cluster. Unfortunately, wrongly adding a Load Balancer or using a public Cluster IP instead of private is just one line away. Such mistakes are very hard to catch in time.
With Octarine, you can define which workloads can be exposed to internal or external workloads, and enforce it. Octarine allows users to define the acceptable configurations and behaviors of their Kubernetes resources, including which applications can be exposed to the Internet, and how. The policy can be monitored and enforced in the code repository, the CI/CD pipeline, and the running clusters.
Verizon’s 2019 Data Breach Report shows that 70% of breaches are actually done by internal actors, usually through compromised users. Organizations have to ensure that they have the proper Role-Based Authentication Controls (RBAC) in place, giving only the minimal required access to the workloads. For example: Very few employees, if any, should be able to access running containerized applications, especially those with privileged access to the nodes or to the Kubernetes API. With Octarine, you can monitor and block direct access to the containers (kubectl exec) through fine-grained policy. You can also ensure that access to internal services stays private by preventing users to poke holes in your Kuberentes network access with kubectl port-forward.
Kubernetes clusters are very dynamic environments: pods go up and down, containerized applications are updated often, new services are created, etc. How do you prevent rogue containers from being executed and persisting in your environment? How do you differentiate normal, scheduled changes from malicious ones?
Octarine offers several layers of control of your runtime environment. You can ensure that all images are pulled from an approved list of registries to prevent rogue images. You can go further and ensure that all containers have gone through the entire CI/CD process, as well as all the proper verifications and validations, by signing the workload definitions and validating them.
Finally, you can set boundaries around how workloads are configured. You can define what applications are allowed to make permanent changes to the host (hostPath mount, unsafe sysctls, etc), what services can be called (metadata API, cloud resources, Kubernetes API server, etc).
The Microsoft Kubernetes attack matrix is a good way to check if you are covering all attack vectors in Kubernetes. Image scanning covers just a couple of attacks: compromised image in a library, some application vulnerabilities. Code scanning and WAF are useful for catching application exploits.
But all the other attack vectors require deep integration with Kubernetes, with full visibility into the Kubernetes resource definitions and the network layer. The Octarine platform covers 33 of the 40 attack vectors identified by Microsoft with GuardRails policy for Kubernetes resources and our runtime network security. Deep integration with Kubernetes is the key to providing broad security coverage.
We applaud Microsoft for putting together this comprehensive document of the risks associated with Kubernetes, but knowing the risks is only half the battle. Meeting compliance and security obligations is not optional, but Octarine makes it easy. Find out how to secure your Kubernetes app lifecycle with Octarine.