Most security breaches start with a faulty service account, password breach, or overlook of permissions given to a user or a service account. It could be any type of security breach from a fishing scam to a brute force attack. This occurs because there’s a major oversight to how permissions, authentication, and authorization should be set up.
In Kubernetes, it’s an especially large problem that many organizations have to deal with when a security concern is already occurring.
In this blog post, you’ll learn about Role Based Access Control (RBAC) from a Kubernetes perspective, why it’s important, and how you can get started with RBAC.
What Is RBAC
RBAC is a method used to restrict system access to specific users or service accounts.
It’s one of the most important, and most overlooked pieces of Kubernetes.
Within Kubernetes, and almost every other platform that has nothing to do with Kubernetes, RBAC is the golden key to your environment. Anyone or anything that has full-blown access to an environment, like a root user, is wearing the crown.
For example, let’s take a user into consideration. When you create a service account for a user, you’re defining:
- What Kubernetes resources the user has access to
- What Namespaces the user has access to
- What nodes the user has access to
- What the user can do across your entire environment
You’re essentially creating multi-tenancy for users across an environment.
Can you think about what would happen if this isn’t done correctly?
When a user is assigned permissions, those permissions are embedded into the users Kubeconfig, which is essentially the “authenticate me to this Kubernetes cluster” file that sits on your local computer. The Kubeconfig is not encrypted and it sits in a “hidden” (emphasis on how it’s not actually hidden) directory on your computer.
If you have full-blown admin/root access, what happens when a bad entity gets ahold of that Kubeconfig?
RBAC, in short, is the secret sauce to mitigating one of the largest ways that an attack can occur in your Kubernetes environment. Without proper RBAC, you’re open to almost every and any security attack.
Steps To Take With RBAC
Understanding what RBAC is and why it’s important in Kubernetes is step one. Step two is figuring out how to mitigate as much risk as possible in your Kubernetes cluster with proper RBAC configured. The reality is that you cannot mitigate every single security breach that could occur. It’s simply not possible. However, you can take the proper steps and precautions to mitigate as much as possible.
First, you want to set a standard for your team and organization. Very rarely does technology solve people problems, and it never solves security issues across teams. The first step is to ensure that the team you’re on, the teams you’re working with, and management understand why RBAC is important, why it should be a key focus, and set a standard for everyone across the teams.
Second, you want to ensure that you unify RBAC across all clusters. In the Getting Started section coming up next, you’ll see a few Kubernetes Manifests. The Kubernetes Manifests use “Cluster” resources, which allow you to create the RBAC standards across your entire cluster vs on just one node. Ensure that when you set up RBAC, the standard is across the entire cluster.
Third, you want to ensure that the least privilege is always the first thing that comes to mind when configuring RBAC. Much like every other sector of tech, you don’t want to start by giving everyone full-blown access and take away the access as needed. Instead, you want to give everyone (and every service account) the bare minimum that’s needed. Then, as issues arise, give more permission to suit the needs of whatever is occurring.
Fourth, ensure you understand what you’re installing. Many Kubernetes platforms and tools have to interact with your Kubernetes cluster. For them to interact with your Kubernetes cluster, 9.999999 times out of 10, the tool/platform is giving you a Kubernetes Manifest or Helm Chart to run on your cluster. This Manifest contains a whole bunch of goodies, including (usually) a service account creation and RBAC bindings. If you look deep enough in the, what feels like one million lines of YAML, you’ll notice that a lot of these tools/platforms are giving FULL root/admin access to the service accounts. You have to ask yourself “is this actually needed?” and if it is, figure out why and how to remove the need. Sometimes it’s possible, sometimes it’s not. Again, you can’t mitigate all risks, but you can certainly ensure you understand the risk.
Getting Started With RBAC
Now that you understand what RBAC is, why it’s important, and how it should be thought about, let’s learn how to create a service account with specific RBAC permissions.
This is a simple example, but it should help you get started in the direction that you want to go in when thinking about proper security for RBAC, and for service accounts as a whole.
First, you’ll want to create a service account. A service account allows access to specific resources. For example, you can set up a user (like yourself) as a service account or you can set up a service account that’s used for Pod creation.
The service account Manifest below creates a new service account called “mikeuser”.
apiVersion: v1 kind: ServiceAccount metadata: name: mikeuser
Next, you have to set up some permissions for the service account. Although the service account isn’t defined in the below Manifest, the below Manifest is creating the permissions that the “mikeuser” service account should have. In this case, you’re giving “mikeuser” authentication to the Pods Kubernetes resource. Then, you’re giving it authorization to Pods to do the following:
This means you’re giving “mikeuser” authentication access to Pods and authorization to perform read-only actions.
kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: reader rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "watch", "list"]
After you define the ClusterRole and the permissions that you want the “mikeuser” service account to have, you can bind the service account and the Role together with a ClusterRoleBinding.
apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: read-pod-global subjects: - kind: ServiceAccount name: mikeuser apiGroup: "" namespace: default roleRef: kind: ClusterRole name: reader apiGroup: rbac.authorization.k8s.io
You may see other configurations that show “Role” instead of “ClusterRole” and “RoleBinding” instead of “ClusterRoleBinding”. The difference is whenever you see “Cluster” in the Kubernetes resource, the permissions/authentication/authorization you’re giving a service account is cluster-wide, not node specific.
Congrats! You have successfully set up a service account with RBAC permissions in Kubernetes.
Learn more about KSOC at www.ksoc.com.