Using Role-Based Access Control (RBAC) in Kubernetes: A Practical Example

Role-Based Access Control (RBAC) in Kubernetes is a robust method for managing permissions and access to resources within your cluster. By defining roles and associating them with users or groups, RBAC helps maintain a secure and organized environment. In this blog, we’ll dive into a practical example of using RBAC in Kubernetes.

What is RBAC?

RBAC in Kubernetes involves four main components:

  1. Roles: Define what actions can be performed on which resources within a namespace.
  2. RoleBindings: Associate roles with users or groups within a namespace.
  3. ClusterRoles: Define what actions can be performed on which resources across the entire cluster.
  4. ClusterRoleBindings: Associate cluster roles with users or groups cluster-wide.

Step-by-Step Guide to Using RBAC

1. Define a Role

Let’s create a Role that grants read-only access to pods within the development namespace. Here’s the YAML configuration for the Role:

# role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: development
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

Apply the Role using kubectl:

kubectl apply -f role.yaml
2. Create a RoleBinding

Next, create a RoleBinding to bind the pod-reader Role to a user named jane:

# rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: development
subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Apply the RoleBinding:

kubectl apply -f rolebinding.yaml
3. Verify the RBAC Setup

To verify that jane has the correct permissions, use the kubectl auth can-i command:

kubectl auth can-i get pods --namespace=development --as=jane

This command should return yes, indicating that jane can get pod information in the development namespace.

Providing Credentials to Jane

To provide jane with the necessary credentials, you can use a service account. Here’s how:

1. Create a Service Account for Jane
kubectl create serviceaccount jane --namespace=development
2. Bind the Role to the Service Account

Update the RoleBinding to refer to the service account:

# rolebinding.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: development
subjects:
- kind: ServiceAccount
  name: jane
  namespace: development
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Apply the updated RoleBinding:

kubectl apply -f rolebinding.yaml
3. Retrieve the Token for the Service Account

Get the name of the secret associated with the service account:

kubectl get serviceaccount jane --namespace=development -o yaml

Find the token from the secret:

kubectl get secret jane-token-abcde --namespace=development -o jsonpath='{.data.token}' | base64 --decode
4. Create a Kubeconfig File for Jane

Create a kubeconfig file using the token:

# jane-kubeconfig.yaml
apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority-data: <CA_DATA>
    server: https://<KUBERNETES_API_SERVER>
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    namespace: development
    user: jane
  name: jane-context
current-context: jane-context
users:
- name: jane
  user:
    token: <TOKEN>

Replace <CA_DATA> with the base64-encoded certificate authority data, <KUBERNETES_API_SERVER> with your Kubernetes API server endpoint, and <TOKEN> with the token you retrieved.

Conclusion

Using RBAC in Kubernetes allows you to control access to resources effectively, ensuring a secure and organized cluster environment. By following the steps outlined in this blog, you can create roles, bind them to users or service accounts, and verify permissions, providing a robust framework for managing access in your Kubernetes cluster.

One thought on “Using Role-Based Access Control (RBAC) in Kubernetes: A Practical Example

Leave a Reply

Your email address will not be published. Required fields are marked *