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) and Kubernetes authorization, why they are important, and how you can get started with RBAC.
What Is Kubernetes 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: mikeuserNext, 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:
- Get
- Watch
- List
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.ioYou 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.
What is Kubernetes authorization?
Authorization for Kubernetes can be thought of at multiple levels. For example, Kubernetes RBAC (role-based access control) authorization and Kubernetes ABAC authorization can be used to confirm users are only able to gain access to resources for which they have permission. Kubelet authorization provides additional protection by only allowing specific operations on the node, such as launching new containers or modifying existing ones. And Kubernetes node authorization is an important part of Kubelet authorization, authorizing API requests made to kubelets.
Kubernetes authentication and authorization
Kubernetes authorization governs access control and permissions within a Kubernetes cluster, determining what actions various users, applications, or services are allowed to perform on resources like pods, services, and/or deployments.
Kubernetes uses RBAC as its primary authorization mechanism, which involves defining “roles” and “clusterroles” with specific permissions, and then binding these roles to users or groups through “rolebindings” or “clusterrolebindings.” This way, administrators can grant access rights to multiple entities based on their roles and responsibilities. The kubectlcommand is what you will use to describe or change an RBAC object.
Authentication, on the other hand, is performed by Cloud IAM. The difference between RBAC and Cloud IAM is that Cloud IAM is a much broader framework provided by cloud service providers. It governs access to various cloud resources beyond Kubernetes, such as virtual machines, databases, and storage. While Kubernetes authorization specifically focuses on controlling interactions within the cluster, IAM operates at the cloud infrastructure level, allowing administrators to manage access across multiple services and resources within the entire cloud environment.
Keep up to date with the latest Kubernetes authentication and authorization methods, including kubectl commands, Cloud IAM roles, and node monitoring to keep your security as tight as possible. Gaining a comprehensive understanding of the different available tools and their specific purposes can empower you to maintain an inherently secure cluster at all times.
How KSOC helps with RBAC and Kubernetes authorization
With KSOC, you can gain visibility into who has access to which resources using our RBAC Explorer:
Another view shows all the access for a particular resource, in this case a ServiceAccount, with full visibility into rolebindings that might otherwise be invisible in the absence of the associated role:
