KubeCon is the Cloud Native Computing Foundation’s flagship conference, dedicated to the education and advancement of cloud native computing. This week, we’ll be attending the sold out KubeCon 2018 in Seattle, so make sure to drop by to say hi if you’re also in attendance! We’re delighted to be joining both adopters and technologists from leading open source and cloud native communities, such as Kubernetes, Prometheus, Envoy, OpenTracing, Fluentd, gRPC, containerd and more.
In celebration, our post today highlights the key security concerns for a Kubernetes deployment, and how to overcome them.
Kubernetes has become more and more popular over the course of the past year, and deservedly so. Here at Aporeto, we have observed the industry moving from single cluster deployments to multiple cluster deployments. This is progress, yet presents the industry with some critical security challenges.
First of all, let’s take a look inside a single cluster. By default, all your pods inside a single cluster will be able to communicate to each other. This means there are no network policies enabled. Luckily, at the network level, Kubernetes brings you a network policy API which allows you to define security rules that discern which pods should be able to communicate to which other pods.
To ensure the security of your application, pods should always be blocked from communicating with other pods unless they are explicitly authorized to do so. This is what is referred to as the Zero Trust model, in which only the explicitly allowed connections will pass through the security network model.
The second thing that you can do inside a cluster is to use identity to enable RBAC (role-based access control), an administrative function. The Kubernetes RBAC capability factors into the workload deployment on the the control plane level, and allows you to define which users can administer the cluster. It allows you to granularly define which users can list, get or create pods. You can assign different capabilities to each user.
You can describe your Kubernetes network policy by creating a definition file in YAML format, to document metadata about the policy. By default, every representation of an object is done using YAML.
Using this method, you define a specific pod with a selector on these labels, that is then able to communicate with the final pod that has those same labels. This works well; yet creates the issue of having vast amounts of YAML files, and a lot of manual editing of the files themselves, which can lead to human error.
In order to overcome this, you can use another control plane (such as Aporeto’s control plane), to directly define those network policies, and in such a way, avoid the use of the YAML files.
One of the key things Aporeto does inside Kubernetes is enable network policies and fully automated single-cluster and multi-cluster deployments. As soon as you deploy your Kubernetes cluster, Aporeto springs into action to deploy what we refer to as the Enforcer.
The Enforcer will be able to automatically access the network policy rules from a central control plane (which is the Aporeto backend) and seamlessly apply a set of security rules, which are applied to a Zero Trust networking model. This means that only the pods that should communicate with each other will be allowed to communicate with each other.
For more information, read our whitepaper Defining Security for a Kubernetes Deployment.