If you are new to using Kubernetes or haven’t spent a lot of time poking around under the hood, you might be surprised to learn that out of the box Kubernetes leaves you with a few significant security concerns to address.
Here are eight you’ll want to think about right away:
When you access a Kubernetes cluster, you assume a “context,” which establishes things like (a) what cluster you are connecting to (allowing you to switch if you work with more than one), (b) which namespace you are operating in, and (c) what permissions you have within that cluster/namespace. When a Kubernetes cluster is created, there is a default context, which is what you’ll be given access to in your KubeConfig if you connect to that cluster unless other contexts are declared. That default context, it can access everything, including the Control Plane, secrets, all namespaces, and therefore all workloads deployed on the cluster. That’s a lot, and it definitely does not follow the security Principle of Least Privilege. So you’ll want to create new contexts for users to connect under right away when you stand up a cluster in order to limit that access.
Similar in concept to context is a Kubernetes “namespace”: the segmented security boundary of the cluster that you perform operations within. Kubernetes automatically creates two namespaces for you when it is stood up: one for the control plane and one that is simply the “default.” This makes some sense: it prevents workloads being deployed into the same security boundary as the control plane elements. Unfortunately, though, it’s not a great idea to deploy all your workloads in the same namespace, either. You should be creating separate namespaces to map to your own internal security boundaries so that workloads that should not have access to one another’s resources are kept isolated from one another.
This default is a little more about where you deploy Kubernetes. If you use a cloud provider that defaults to creating public IPs or public load balancers for all hosts/nodes, you may discover that this means your control plane is available to the internet on a public IP. You don’t want this: you want all control plane resources “offline” and only accessible through tightly controlled access mechanisms.
Role Based Access Control (RBAC) has become the accepted standard for how you should configure user (including service account) permissions within your Kubernetes cluster. The only problem is, Kubernetes doesn’t enable RBAC by default. You have to turn it on and configure it. That’s a large undertaking that will require careful planning and overlaps with several other items on this list (ie, numbers 1 and 8), but it’s a necessary step for your cluster to follow the Principle of Least Privilege.
Kubernetes provides a layer of abstraction over cloud infrastructure concepts like “hosts” and “storage,” allowing your applications to be deployed across your cloud footprint without needing to be aware of the specifics of that infrastructure. To do that, Kubernetes has to handle a lot of networking, allowing pods to communicate with one another across your cluster. By default that internal (also known as “East-West” traffic) is not encrypted. We increasingly understand that this is not safe: while it may seem like that traffic is all internal to your network, in reality it is moving across a lot of infrastructure and cloud resources that you do not own or control, meaning you don’t know who else might be watching/listening to that traffic. There are a number of options for encrypting this traffic, including using a Service Mesh, a Container Networking Interface plugin, or establishing your own custom networking policies.
Many, if not most of your workloads are going to need access to “secrets”— things like API tokens or SSL/TLS Certificates that will be used to authenticate to other services or encrypt traffic. Kubernetes helpfully provides a mechanism for granting your pods access to these secrets, namely, Kubernetes “Secrets” objects, but by default the contents of these secrets aren’t encrypted, so anyone with access to the namespace they are located in can read them. You’ll want to change that and turn on secret encryption.
While we’re on the subject of secrets: you need a way to get those secrets into your cluster/namespace for your workloads to access them. You can do that one of two ways: via the CLI (using kubectl) or via a Kubernetes manifest (a secrets.yml file, for example) deployed alongside your other Kubernetes resources. Either case requires transmitting, and possibly storing, those secret values in clear text. Anyone with access to the git repository storing your manifests or to the bash history of your node is going to be able to see those contents. That doesn’t keep your secrets very secret. As a result, teams are increasingly turning to services like Hashicorp’s Vault to store their secret values in an encrypted form and dynamically inject those values without keeping them in the actual source code.
Your cluster needs a service account to perform administrative actions (like, deploying pods). By default Kubernetes creates a single “default” service account. That account has the ability to do just about everything in your cluster. If you use that account to deploy your pods (again, the default), you’ll be granting a massive amount of permission to everyone who can deploy pods in your cluster. You’re going to want to define additional service accounts with much narrower permissions (using RBAC) and use those for pod deployment in order to follow the Principle of Least Privilege.
KSOC, the Kubernetes Security Operations Center, was built by some of the world's leading Kubernetes experts to handle the security challenges teams face when adopting and running Kubernetes. Our cloud native platform allows users to easily identify and quickly remediate security vulnerabilities, misconfigurations, and RBAC issues. To learn more, get in touch with our team.