![ApptioCareers-Employee[1]](data:image/svg+xml;base64,PHN2ZyB4bWxucz0iaHR0cDovL3d3dy53My5vcmcvMjAwMC9zdmciIHZpZXdCb3g9IjAgMCAyMjUgMjc1IiB3aWR0aD0iMjI1IiBoZWlnaHQ9IjI3NSIgZGF0YS11PSJodHRwcyUzQSUyRiUyRnd3dy5hcHB0aW8uY29tJTJGd3AtY29udGVudCUyRnVwbG9hZHMlMkZlbGVtZW50b3IlMkZ0aHVtYnMlMkZBcHB0aW9DYXJlZXJzLUVtcGxveWVlMS1xZzVuenB5MHdoaWJtbzZvdmJqNGM3MHh0aTUzdmo1OHM0endwajh0dHMucG5nIiBkYXRhLXc9IjIyNSIgZGF0YS1oPSIyNzUiIGRhdGEtYmlwPSIiPjwvc3ZnPg== "ApptioCareers-Employee[1]")
IBM ApptioKubernetes Best Practices
Chapter 3: RBAC
Like this article?
Subscribe to our LinkedIn newsletter to receive more educational content.
RBAC (Role-Based Access Control) is a key feature of Kubernetes that allows administrators to control access to cluster resources by defining Roles and assigning permissions to different users, groups, and service accounts. As the number of users and workloads in a Kubernetes cluster grows, managing access control becomes increasingly complex. Using RBAC, you can manage access control at a higher level using configuration management tools. You can define access control policies as code and version them with the rest of the infrastructure. Following Kubernetes RBAC best practices gives many security advantages, such as fine-grained access control and the ability to define Roles with minimal permissions.
This article covers the fundamental concepts of Kubernetes RBAC along with some practical use cases.
Summary of Kubernetes RBAC best practices
Here are some best practices for using Kubernetes RBAC.
| Best practice | Description |
|---|---|
| Grant Least Privilege | Grant the minimum permissions required for users to perform their duties. Limit permissions to only those resources and operations necessary for the user to perform their job. |
| Use Namespaces | Use namespaces to segment your cluster into logical units and apply RBAC to each namespace independently. This allows you to control access to resources in a more fine-grained manner. |
| Create Service accounts | Create dedicated service accounts for each application or workload and grant permissions to those accounts rather than to individual users. This way, you can control access to resources at a higher level and limit the impact of potential security incidents. |
| Update Policies | Regularly review and update RBAC policies to ensure they align with your security requirements and business needs. Remove unnecessary permissions or Roles, and update RBAC policies as your applications and workloads change. |
By following these best practices, you can ensure that your Kubernetes cluster is secure and that users only have access to the resources they need to do their jobs. Before implementing RBAC, you must understand its core components and possible actions.
Understanding Kubernetes RBAC components
RBAC consists of four key components: Roles, RoleBindings, ClusterRoles, and ClusterRoleBindings.
Roles
A Role is a set of rules defining permissions for accessing Kubernetes resources within a specific namespace. You can use a Role to grant a number of read or write actions to a specific set of resources, such as pods or services, within a namespace.
RoleBindings
A RoleBinding attaches a Role to a user, group, or service account. It grants the permissions defined in a Role to the specified user, group, or service account within the specified namespace.
ClusterRoles
ClusterRoles are similar to Roles but affect the entire Kubernetes cluster instead of a specific namespace. You can use a ClusterRole to grant a number of read or write actions to a set of resources outside a specific namespace, such as nodes or namespaces.
ClusterRoleBindings
ClusterRoleBindings are similar to RoleBindings, but you use them to attach a ClusterRole to a user, group, or service account. A ClusterRoleBinding grants permissions defined in a ClusterRole to the specified user, group, or service account across the Kubernetes cluster.
Available RBAC actions
Verbs define the actions you can perform on Kubernetes resources.
Kubernetes administrators use verbs in conjunction with Roles and RoleBindings (or ClusterRoles and ClusterRoleBindings) to grant or restrict access to specific actions on Kubernetes resources. The following are the possible verbs that you can use in RBAC. You can also use wildcards.
| Verb | Action |
| Get | Allows the user to retrieve the state of a Kubernetes resource. |
| List | Allows the user to retrieve a list of Kubernetes resources. |
| Watch | Allows the user to receive notifications when the state of a Kubernetes resource changes. |
| Create | Allows the user to create a new Kubernetes resource. |
| Update | Allows the user to update an existing Kubernetes resource. |
| Patch | Allows the user to make partial updates to an existing Kubernetes resource. |
| Delete | Allows the user to delete an existing Kubernetes resource. |
| Deletecollection | Allows the user to delete a collection of Kubernetes resources. |
| Proxy | Allows the user to access the Kubernetes API server through a proxy. |
| Connect | Allows the user to connect to the console of a Kubernetes container. |
| Redirect | Allows the user to redirect traffic to a Kubernetes service. |
| Portforward | Allows the user to forward network traffic to a Kubernetes pod. |
Now that you understand the basics of RBAC, let’s explore some key Kubernetes RBAC best practices!
RBAC Best Practice #1 Grant Least Privilege
The most important of all Kubernetes RBAC best practices involves granting users or service accounts only the permissions they need to perform their tasks. For example, let’s say you have a service account used by a specific pod in your Kubernetes cluster to access a database. In this case, you might create a custom Role that grants the service account read and write access to the specific database but no access to other resources in the cluster.
Default RBAC Roles
Cluster-admin and system:masters are built-in Kubernetes RBAC Roles that grant users or service accounts powerful permissions across the entire cluster. Both Roles are included in Kubernetes by default, but you should only use them when absolutely necessary.
Cluster-admin
The cluster-admin Role grants full control over all resources in the cluster, including the ability to create, modify, and delete resources in any namespace. This Role is for cluster administrators who need full control over the cluster and should be used cautiously as it grants unrestricted access.
System:masters
The system:masters Role grants read and write access to most resources in the cluster but does not grant full control over the cluster. Users or service accounts with this Role can create, modify, and delete resources in most namespaces. Still, they cannot perform certain privileged operations, such as modifying the cluster’s control plane components. This Role suits users or service accounts needing elevated permissions to perform specific administrative tasks.
More granular Roles
In general, it is preferable to create fine-grained Roles and permissions for users or service accounts that need to access specific resources or perform specific actions. Granting them the cluster-admin or system:masters Roles can increase security risks. Fine-grained access control reduces the risk of accidental modifications to critical resources in the cluster.
RBAC Best Practice #2 Use Namespaces
Namespaces are the Kubernetes way to section off resources in a multi-tenant environment. Each namespace will have its own set of resources and policies.
Using namespaces with RBAC, you can create more fine-grained access controls that apply only to specific resources within a particular namespace.
For example, multiple development teams use a Kubernetes cluster, each working on their own microservices. You could use namespaces to partition the cluster’s resources for each team and use RBAC to grant each one only the permissions needed to access their resources.
Namespaces manifest example
Here’s an example manifest for creating a custom RBAC Role that grants a user or service account access to resources in a specific namespace:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: mynamespace
name: myRole
rules:
- apiGroups: [""]
resources: ["pods", "services", "deployments"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
This manifest creates a custom Role called myRole in the namespace mynamespace. The Role grants the get, list, and watch verbs for the pods, services, and deployments resources, as well as the create, update, patch, and delete verbs for these resources. This allows the associated user or service account to view, create, modify, and delete resources in the specific namespace.
RBAC Best Practice #3 Create Service Accounts
You use a service account in Kubernetes to authenticate and authorize communication between different parts of the system, such as pods or controllers. When you create a pod in Kubernetes, it is automatically assigned a default service account, which you use to access the Kubernetes API and other resources.
How to create a service account
To define an RBAC service account in Kubernetes, you can create a ServiceAccount resource, like this:
apiVersion: v1
kind: ServiceAccount
metadata:
name: myserviceaccount
namespace: mynamespace
This manifest creates a new service account called myserviceaccount in the namespace mynamespace. Pods or controllers can use the service account to authenticate and authorize communication with other system parts.
Granting permissions to the service account
Once you create the service account, you can create RBAC policies that grant specific permissions to the service account. This is done using the Role and RoleBinding resources, which define the specific actions and resources the service account can access. For example, attach a Role to the service account using a RoleBinding:
apiVersion: v1
kind: ServiceAccount
metadata:
name: myserviceaccount
namespace: mynamespace
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: myRoleBinding
namespace: mynamespace
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: myRole
subjects:
- kind: ServiceAccount
name: myserviceaccount
namespace: mynamespace
The Rolebinding above requires a separate Role resource to be defined as follows:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: myRole
namespace: mynamespace
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["secrets"]
verbs: ["get", "watch", "list"]
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list"]
This manifest creates a Role called myRole in the namespace mynamespace. The Role grants the following permissions:
- Read access to all secrets in the namespace (get, list, and watch verbs).
- Read access to all pods and logs in the namespace (get and list verbs).
Using a ClusterRole with a ServiceAccount
Following on from the previous example, what if we needed Cluster-wide permissions for our service account? After creating the ServiceAccount we can attach a ClusterRole using a ClusterRoleBinding:
apiVersion: v1
kind: ServiceAccount
metadata:
name: myserviceaccount
namespace: mynamespace
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: myClusterRoleBinding
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: myserviceaccount
namespace: mynamespace
This manifest creates a ServiceAccount called “myserviceaccount” and assigns the default ClusterRole “cluster-admin” to the ServiceAccount.
It’s important to note that granting the “cluster-admin” ClusterRole to a ServiceAccount should be done with caution, as it provides full access to all resources in the cluster. It’s generally best to use more specific Roles and RoleBindings whenever possible to limit access to only the resources and actions that are necessary.
RBAC Best Practice #4 Update Policies
RBAC policies should be defined and managed as code in Kubernetes using YAML manifests, whether in versioned helm charts or source control. With that in mind, one of the most important Kubernetes RBAC best practices is regularly reviewing your RBAC policies and ensuring they meet your organization’s security requirements. You could also consider using a third-party policy enforcement agent like OPA Gatekeeper.
OPA Gatekeeper
Open Policy Agent (OPA) is an open-source, general-purpose policy engine. OPA Gatekeeper is a Kubernetes-based validating admission webhook that enforces OPA policies on interactions with Kubernetes resources. You can use it to ensure all applications deployed to your target Kubernetes cluster have defined custom service accounts.
Conclusion
To recap, using the principle of Least Privilege is vitally important as it reduces the blast radius in the event of unauthorized access, a data breach, and other security incidents. Likewise, using namespaces helps create fine-grained controls that limits vulnerability. The third principle follows from the least privilege, using service accounts where possible and keeping user permissions to an absolute minimum. Finally, all RBAC policies should be updated continually as your organization’s needs and security requirements change.
RBAC (Role-Based Access Control) is a powerful mechanism for controlling access to resources in a cluster. Following Kubernetes RBAC best practices, you ensure your Kubernetes cluster is secure and well-managed. At the same time, It is important to remember that RBAC policies are only one part of a comprehensive security strategy and should be used in conjunction with other security mechanisms such as network policies, encryption, and authentication.
