Subash Neupane's Blog
Kubernetes RBAC

Kubernetes RBAC

Subash Neupane's photo
Subash Neupane
·

4 min read

In this blog, we will learn about the Kubernetes RBAC concept. RBAC is a simple yet complex feature of Kubernetes because it is directly related to security. It is more important to understand the RBAC concepts than the roles, service account, and role binding.

RBAC is abbreviated as "Role Based Access Control". It can be broadly devided into two groups:

  • Users Management
    While acting as a root user in local development, such as when using Minikube, security considerations may not be as crucial. However, in organizational settings where multiple users have access to the cluster, there is a potential risk of users inadvertently or maliciously modifying sensitive resources. To avoid this risk, the cluster administrator or DevOps engineer must define user access, specifying who can access the cluster and edit resources. Role-Based Access Control (RBAC) is employed for this purpose, enabling DevOps engineers to define access based on roles..

  • Service Accounts

    Similar to User management, we can manage access to the services or the applications that are running on the Kubernetes cluster.

Here are some key concepts in RBAC:

  1. Service Accounts/Roles

  2. Role/ cluster role Bindings

    1. Role Binding/ClusterRoleBindings
      Kubernetes does not manage the users. Kubernetes offloads the user management to the Identity providers. For example, if we try to log into any application, we don't need to create a user account, we can simply use multiple options such as signing in with Google, Facebook, Twitter, GitHub, Instagram, and so on. This is exactly what Kubernetes does. It does not create the user but will pass it to the Identity providers. So the Kubernetes API server acts as an OAuth server which passes it to the identity providers.

If our cluster is in Amazon EKS, then we can use the AWS IAM users to log into the Kubernetes Cluster for which we need to create the IAM OAuth provider.

To grant access to users, we will first create the roles and assign these roles to the developers. The role is a YAML file where we mention the grants to be provided to the users. If the role is created within a specific namespace,then it is a role, but if the role is created across the cluster then it is called a cluster role.

To attach these roles to the users/developers, we will use the role-binding.

To create the service account in the required namespace.

kubectl -n kube-system create serviceaccount subash

From Kubernetes Version 1.24, the secret for the service account has to be created separately with annotation

subash-secret.yaml

apiVersion: v1
kind: Secret
metadata:
  name: subash
  namespace: kube-system
  annotations:
    kubernetes.io/service-account.name: subash
type: kubernetes.io/service-account-token

Create the cluster Role

subash-cluster-role.yaml

This YAML file creates only ready access to all namespaces

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: subash
rules:
  #Allow read access to Pods and related resources in all namespaces.
  - apiGroups:
      - ""
    resources:
      - pods
      - pods/log
      - pods/status
      - pods/portforward
      - namespaces
      - services
      - cronjobs
    verbs:
      - get
      - list
      - watch
      - create
      - update

Cluster Role Binding

subash-cluster-role-binding.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: subash-binding
subjects:
  - kind: ServiceAccount
    name: subash
    namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: subash

We've successfully created a Service Account named "subash" in the "kube-system" namespace, along with a corresponding secret. Additionally, we've created a ClusterRole named "subash" that provides read access to specific resources across all namespaces. We've also created a ClusterRoleBinding that associates the "subash" ServiceAccount with the "subash" ClusterRole in the "kube-system" namespace.

Now, if we want to use this Service Account in a Pod within the "kube-system" namespace or another namespace, we need to reference the Service Account in our Pod specification.

spec.yml

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
  namespace: kube-system
spec:
  serviceAccountName: subash  # Reference the Service Account here
  containers:
  - name: my-container
    image: nginx:latest

Apply the pod

kubectl apply -f pod-spec.yaml

After applying the Pod specification, the Pod will run with the specified Service Account, and it will have the permissions defined in the "subash" ClusterRole. Adjust the Pod specification based on your application's requirements and the level of access needed for the Service Account.

I hope you liked this blog. If any mistake, do comment down below 🚀.

Do like and share this blog♥️

cluster roleKubernetesrbacclusterrolebindingssecrets