Join us
@squadcast ・ Jan 12,2023 ・ 7 min read ・ 1186 views ・ Originally posted on www.squadcast.com
The more prominent and complex Kubernetes deployments become, the more important it is to define strict access controls and tighter security. In this blog, Kasun has explained how RBAC can be implemented in Kubernetes clusters to restrict user permissions to relevant resources only.
The more prominent and complex Kubernetes deployments become, the more important it is to define strict access controls and tighter security. In this blog, Kasun has explained how RBAC can be implemented in Kubernetes clusters to restrict user permissions to relevant resources only.
With the inception of Kubernetes as an open-source project in 2015, it became the new standard of managing software in the cloud. Modern applications are moving from monolithic architecture to microservice architecture and containerization. When managing multiple microservice applications, managing the number of containers will be a challenging task. To overcome this, we can use Kubernetes for container orchestration. Kubernetes will manage the entire lifecycle of individual containers, spinning up and shutting down resources as needed. If a container shuts down unexpectedly, the orchestration platform will react by launching another container in its place.
To give you an idea, these are some of well known features of Kubernetes:
RBAC is a security measurement, designed to restrict access to valuable resources based on the roles assigned to the entity(user, group, or service account). We can see RBAC in modern applications and cloud providers. Let's identify why RBAC is important for us.
As an example, let's assume your application doesn't use any RBAC system. An administrator uses his username and password to log in to the system and has full access to the system. In this case, if we add regular users, they will also have full permission in the system.
With the expansion of the Kubernetes environment, complexity grows, and role-based security becomes essential. Therefore, we need to divide the cluster into multiple namespaces and limit access from service accounts and users for each resource.
Not every user needs unrestricted access to the cluster to create, modify or delete resources. As the users and cluster resources increase, you will need to limit access to resources and allow relevant permissions required.
Kubernetes have two kinds of roles for defining the action users can perform within the cluster. ClusterRole and Roles operate in Kubernetes within a cluster or namespace, respectively. In Kubernetes, you can use RBAC to assign roles to Kubernetes subjects(users, groups and service accounts) with RoleBindings and ClusterRoleBindings. Kubernetes allowed administrators to create custom roles including but not limited to built-in roles as follows:
Kubernetes Service Accounts are used for creating managed Kubernetes resources via Kubernetes API, meant to be used by Kubernetes entities such as Pods for authenticating Kubernetes API server or external services.
A Role always sets permissions within a particular namespace; when you create a Role, you have to specify the namespace it belongs to. Following is an example of a YAML manifest for Kubernetes Role.
Note: The below commands were tested in Kubernetes v1.17
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"]
A RoleBinding grants the permissions defined in a role to a user or set of users. It holds a list of subjects (users, groups, or service accounts) and references the role granted. A RoleBinding grants permissions within a specific namespace. Following is an example of a YAML manifest for Kubernetes RoleBinding.
apiVersion: rbac.authorization.k8s.io/v1
namespace.
kind: RoleBinding
metadata:
name: read-pods
namespace: default
subjects:
- kind: User
name: jane
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader you wish to bind to
apiGroup: rbac.authorization.k8s.io
ClusterRole is used to provide permissions to a non-namespaced resource. ClusterRoles have several uses. You can use a ClusterRole to:
To define a role within a namespace, use a Role; to define a cluster-wide role we 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"]
ClusterRoleBinding is used to grant cluster-wide access to a user or set of users, which we call as subjects (users, groups or service accounts). Following is an example for ClusterRoleBinding:
# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
apiVersion: rbac.authorization.k8s.io/v1
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
We can get started in simplest way by applying RBAC into Kubernetes using Role and RoleBinding.
Scenario - We have a service account name serviceAccount1 and need access to all the resources in the namespace app1.
apiVersion: v1
kind: ServiceAccount
metadata:
namespace: default
name: serviceAccount1
Note: We assume the serviceAccount1 has already been created.
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: app1
name: app1admin
rules:
- apiGroups: ["*"]
resources: ["*"]
verbs: ["*"]
In the above YAML role, we grant full access to all the resources within the namespace app1. As I mentioned previously, roles are namespaced, so we need to specify which namespace role is applied when creating a Role. Next, we look into RoleBinding.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: app1adminrolebinding
namespace: app1
subjects:
- kind: ServiceAccount
name: serviceAccount1
apiGroup: ""
roleRef:
kind: Role
name: app1admin
apiGroup: ""
From RoleBinding we bind the service account with the role we created previously. So now, the service account has only access to the resources inside the app1 namespace.
It's possible to bind a service account from a different namespace, so that the service account can access the resources in app1 namespace with the role attached to the RoleBinding.
ClusterRoles do not belong to any namespace. Therefore ClusterRoles does not scope to any single namespace. But if ClusterRole is linked with a service account via a RoleBinding, ClusterRole permissions are only applied to the namespace that RoleBinding has created.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: adminbinding
namespace: app1
subjects:
- kind: ServiceAccount
name: serviceAccount1
namespace: app1
apiGroup: ""
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: ""
ClusterRole is used to give permissions to cluster-wide resources. ClusterRole or ClusterRoleBinding does not belong to any namespace. Therefore the permissions assigned are cluster-wide. For example, a service account needs to access all the resources in the cluster. So we can use ClusterRoles and ClusterRoleBindings to grant him access to all persistent volumes in the cluster. Example of ClusterRole and ClusterRoleBinding are shown below:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: storageadminclusterrolebinding
subjects:
- kind: ServiceAccount
name: storageaccess
apiGroup: ""
namespace: app1
roleRef:
kind: ClusterRole
name: cluster-admin
apiGroup: ""
Summary
With the above examples, we can understand the benefits and use cases of Kubernetes RBAC. Below is the summary of what we discussed:
Squadcast is an incident management tool that’s purpose-built for SRE. Your team can get rid of unwanted alerts, receive relevant notifications, work in collaboration using the virtual incident war rooms, and use automated tools like runbooks to eliminate toil.
Join other developers and claim your FAUN account now!
Influence
Total Hits
Posts
Only registered users can post comments. Please, login or signup.