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.
In this blog, we will be covering:
- What is RBAC in Kubernetes?
- Why RBAC?
- Authentication and Authorization in RBAC
- Role in RBAC
- Cluster Role in RBAC
- Role Binding in RBAC
- Cluster Role Binding in RBAC
- What is ABAC?
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 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.
Authentication and Authorization in RBAC
In Kubernetes, you must be authenticated (logged in) before your request can be authorized (granted permission to access).
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.
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 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.
Role In RBAC
A role in RBAC defines what you will do to a group of resources. It contains a group of rules which define a set of permission.
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"]
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.
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"]
Role Binding In RBAC
Role Binding in RBAC 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.
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.io
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
What Is ABAC?
Role-based access control (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:
- Visit our YouTube channel on “Docker & Kubernetes”
- 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
Next Task For You
Begin your journey towards becoming a Certified Kubernetes Security Specialist (CKS) and earning a lot more in 2020 by joining our Free Class Waitlist.