Implementing Role-Based Access Control (RBAC) in Minikube

Article by Noble Mutuwa Mulaudzi: DevOps Engineer Role-Based Access Control (RBAC) allows you to define permissions for users in a Kubernetes cluster. This guide walks through setting up RBAC in Minikube using a ServiceAccount. ## Understanding Key RBAC Terms Before implementing RBAC, it's important to understand the main concepts: Role: Defines a set of permissions within a namespace. ClusterRole: Similar to a Role but applies across the entire cluster. RoleBinding: Associates a Role with a user, group, or ServiceAccount within a specific namespace. ClusterRoleBinding: Similar to RoleBinding but applies cluster-wide. ServiceAccount: An account used by applications running inside the cluster to interact with Kubernetes resources. ## Why Implement RBAC? RBAC is crucial for securing your Kubernetes environment by: Restricting Access: Prevents unauthorized users from making changes. Least Privilege Principle: Users and services only get the minimum permissions needed. Enhanced Security: Reduces the risk of accidental or malicious actions. Compliance and Auditability: Helps meet security policies and regulatory requirements. ## Step 1: Create a ServiceAccount First, create a ServiceAccount named dev-user in the default namespace. apiVersion: v1 kind: ServiceAccount metadata: name: dev-user namespace: default Apply the configuration: kubectl apply -f sa.yaml ## Step 2: Create a Role Define a Role that grants limited permissions. The following configuration allows listing and getting pods. apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: pod-reader namespace: default rules: - apiGroups: [""] resources: ["pods"] verbs: ["get", "list"] Apply the role: kubectl apply -f role.yaml Step 3: Bind the Role to the ServiceAccount Create a RoleBinding to associate the pod-reader role with the dev-user ServiceAccount. apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: pod-reader-binding namespace: default subjects: - kind: ServiceAccount name: dev-user namespace: default roleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io Apply the binding: kubectl apply -f rolebinding.yaml ## Step 4: Get a Token for the ServiceAccount Run the following command to generate a token: kubectl create token dev-user --namespace default This token is required for authentication. Step 5: Use the Token to Authenticate 1. Extract the token: TOKEN=$(kubectl create token dev-user --namespace default) 2. Set up a new context: kubectl config set-credentials dev-user --token=$TOKEN kubectl config set-context dev-user-context --cluster=minikube --user=dev-user kubectl config use-context dev-user-context 3. Verify access: kubectl get pods You should be able to list pods but not create, delete, or modify them. Step 6: Test Restricted Access Try running: kubectl delete pod It should fail due to insufficient permissions. ## Conclusion This setup ensures that dev-user has restricted access based on RBAC rules. You can extend this setup to include permissions for additional resources like services and deployments if needed.

Mar 21, 2025 - 08:00

Implementing Role-Based Access Control (RBAC) in Minikube

Article by Noble Mutuwa Mulaudzi: DevOps Engineer

Role-Based Access Control (RBAC) allows you to define permissions for users in a Kubernetes cluster. This guide walks through setting up RBAC in Minikube using a ServiceAccount.

## Understanding Key RBAC Terms

Before implementing RBAC, it's important to understand the main concepts:

Role: Defines a set of permissions within a namespace.
ClusterRole: Similar to a Role but applies across the entire cluster.
RoleBinding: Associates a Role with a user, group, or ServiceAccount within a specific namespace.
ClusterRoleBinding: Similar to RoleBinding but applies cluster-wide.
ServiceAccount: An account used by applications running inside the cluster to interact with Kubernetes resources.

## Why Implement RBAC?

RBAC is crucial for securing your Kubernetes environment by:

Restricting Access: Prevents unauthorized users from making changes.
Least Privilege Principle: Users and services only get the minimum permissions needed.
Enhanced Security: Reduces the risk of accidental or malicious actions.
Compliance and Auditability: Helps meet security policies and regulatory requirements.

## Step 1: Create a ServiceAccount

First, create a ServiceAccount named dev-user in the default namespace.

apiVersion: v1
kind: ServiceAccount
metadata:
  name: dev-user
  namespace: default

Apply the configuration:

kubectl apply -f sa.yaml

## Step 2: Create a Role

Define a Role that grants limited permissions. The following configuration allows listing and getting pods.

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

Apply the role:

kubectl apply -f role.yaml

Step 3: Bind the Role to the ServiceAccount

Create a RoleBinding to associate the pod-reader role with the dev-user ServiceAccount.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader-binding
  namespace: default
subjects:
  - kind: ServiceAccount
    name: dev-user
    namespace: default
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Apply the binding:

kubectl apply -f rolebinding.yaml

## Step 4: Get a Token for the ServiceAccount

Run the following command to generate a token:

kubectl create token dev-user --namespace default

This token is required for authentication.

Step 5: Use the Token to Authenticate

1. Extract the token:

TOKEN=$(kubectl create token dev-user --namespace default)

2. Set up a new context:

kubectl config set-credentials dev-user --token=$TOKEN
kubectl config set-context dev-user-context --cluster=minikube --user=dev-user
kubectl config use-context dev-user-context

3. Verify access:

kubectl get pods

You should be able to list pods but not create, delete, or modify them.

Step 6: Test Restricted Access

Try running:

kubectl delete pod

It should fail due to insufficient permissions.

## Conclusion

This setup ensures that dev-user has restricted access based on RBAC rules. You can extend this setup to include permissions for additional resources like services and deployments if needed.