In this blog, we will be covering RBAC or Role-Based access control. It’s the way to outline which users can do what within a Kubernetes cluster. A Kubernetes cluster is a set of node machines for running containerized applications.
What Is RBAC In Kubernetes?
RBAC stands for Role-Based Access Control. It’s an approach that’s used for proscribing access to users and applications on the system/network. RBAC could be a security style that restricts access to valuable resources based on the role the user holds, hence the name role-based.
Role-based access control (RBAC) is a technique of regulating access to a computer or network resources based on the roles of individual users within an enterprise. In this context, access is the ability of a private user to perform a selected task, like read, create, or modify a file.
Why RBAC?
Why we tend to have an interest in Access Control. Well clearly, we’ve multiple users in our groups and they’re accessing our Kubernetes cluster. Each of them needs to have some level of security from each other. There can be cases, where a member of our team is interfering with the opposite members, work accidentally.
Find out about what is Kubernetes Label here.
Authentication and Authorization in RBAC
In Kubernetes, you must be authenticated (logged in) before your request can be authorized (granted permission to access).
Authentication
Once TLS is established, the HTTP request moves to the Authentication step.
This is shown as step 1 in the diagram. The cluster creation script or cluster admin configures the API server to run one or additional Authenticator Modules. Authentication modules include Client Certificates, Password, and Plain Tokens, Bootstrap Tokens, and JWT Tokens (used for service accounts).
Users in Kubernetes
All Kubernetes clusters have 2 categories of users: service accounts managed by Kubernetes, and normal users. It is assumed that a cluster-independent service manages normal users in the following ways:
- an administrator distributing private keys.
- a user store like Keystone or Google Accounts.
- a file with a list of usernames and passwords.
Authorization
After the request is authenticated as coming from a selected user, the request should be authorized. This is shown as step 2 in the above diagram.
A request should include the username of the requester, the requested action, and also the object affected by the action. The request is authorized if an existing policy declares that the user has permission to complete the requested action.
Admission Control
Admission Control Modules are software modules that can modify or reject requests. In addition to the attributes available to Authorization Modules, Admission Control Modules can access the contents of the object that is being created or modified. This is shown as step 3 in the above diagram.
Unlike Authentication and Authorization Modules, if any admission controller module rejects, then the request is instantly rejected.
Read about: Monolithic vs Microservices – Difference, Advantages & Disadvantages
Role In RBAC
A role in Kubernetes RBAC defines what you will do to a group of resources. It contains a group of rules which define a set of permission.
Here’s an example Role within the “default” namespace that can be used to grant read access to pods:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: default
name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods"]
verbs: ["get", "watch", "list"]
Also Check: Our previous blog post on helm Kubernetes
Cluster Role In RBAC
Roles in RBAC are used to assigning resources for a namespace, however, if you wish to assign resources on a cluster level, you need to use ClusterRole.
Here is an example of a ClusterRole which will be used to grant read access to secrets in any explicit namespace, or across all namespaces (depending on how it’s bound):
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
# "namespace" omitted since ClusterRoles are not namespaced
name: secret-reader
rules:
- apiGroups: [""]
#
# at the HTTP level, the name of the resource for accessing Secret
# objects is "secrets"
resources: ["secrets"]
verbs: ["get", "watch", "list"]
Also Read: Our previous blog post on how Kubernetes scheduler works
Role Binding In RBAC
Role Binding in Kubernetes Role Based Access Control is used for granting permission to a Subject in a Kubernetes cluster. Subjects are nothing but a group of users, services, or team making an attempt at Kubernetes API. It defines what operations a user, service, or a group can perform.
Also Read: Our blog post on Kubernetes pod. Click here
Here is an example of a Role Binding that grants the “pod-reader” Role to the user “jane” within the “default” namespace. This permits “jane” to read pods in the “default” namespace.
apiVersion: rbac.authorization.k8s.io/v1
# This role binding allows "jane" to read pods in the "default" namespace.
# You need to already have a Role named "pod-reader" in that namespace.
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
# You can specify more than one "subject"
- kind: User
name: jane # "name" is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
# "roleRef" specifies the binding to a Role / ClusterRole
kind: Role #this must be Role or ClusterRole
name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
apiGroup: rbac.authorization.k8s.ioRead More: About Kubernetes Multi Container Pod. Click here
Cluster Role Binding In RBAC
Cluster Role Binding in RBAC is used to grant permission to a subject on a cluster-level in all the namespaces. It will offer you permissions for cluster resources and it can even offer you with permissions for resources within any namespace within a cluster. Cluster role bindings are very powerful and you want to be careful with how you apply them because they apply not solely to any existing namespaces but to any future namespaces that you just might create yet.
apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
kind: ClusterRoleBinding
metadata:
name: read-secrets-global
subjects:
- kind: Group
name: manager # Name is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io
Also Read: Our blog post on Best Kubernetes Dashboard. Click here
What Is ABAC?
Also Check: Our blog post on Kubernetes Persistent Storage. Click here
Role-based access control (Kubernetes RBAC) and attribute-based access control (ABAC) are two ways of controlling the authentication process and authorizing users. Attribute-based access control is a model that evolved from RBAC. This model is based on establishing a set of attributes for any element of your system. A central policy defines which combinations of user and object attributes are required to perform any action. ABAC can control access based on three different attribute types: user attributes, attributes associated with the application or system to be accessed, and current environmental conditions.
Related / References:
- Certified Kubernetes Security Specialist (CKS): Everything You Must Know
- (CKS) Certification: Step By Step Activity Guides/Hands-On Lab Exercise & Learning Path
- (CKA) Certification: Step By Step Activity Guides/Hands-On Lab Exercise & Learning Path
- (CKAD) Certification: Step By Step Activity Guides/Hands-On Lab Exercise & Learning Path