> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Role Based Access Controls
> This article explains how to create and manage Role-Based Access Control in Kubernetes, including roles, role bindings, and verifying user permissions.
In this lesson, we dive into Kubernetes Role-Based Access Control (RBAC), providing step-by-step instructions on how to create and manage roles and role bindings within a namespace. You'll learn how to define specific permissions for users, bind these permissions to users, and verify their access using kubectl commands.
## Creating a Role
To start, you need to define a Role object. Create a YAML file (e.g., developer-role.yaml) and set the API version to `rbac.authorization.k8s.io/v1` and the kind to `Role`. In this example, we define a role named "developer" with permissions that allow developers to manage pods and create configmaps. Each permission rule contains three key sections: API groups, resources, and verbs. For resources in the core API group, leave the API group field blank.
```yaml theme={null}
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: developer
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["list", "get", "create", "update", "delete"]
- apiGroups: [""]
resources: ["configmaps"]
verbs: ["create"]
```
Create the role using the following command:
```bash theme={null}
kubectl create -f developer-role.yaml
```
Remember that roles in Kubernetes are namespace-specific. Ensure the YAML definition targets the correct namespace if needed.
## Binding a User to the Role
Once the role is defined, you need to link a user to this role by creating a RoleBinding. A RoleBinding associates a user with the specified role within a given namespace. In this example, we'll create a role binding named `devuser-developer-binding` that assigns the "developer" role to the user `dev-user` in the default namespace.
Below is the YAML definition for the role binding (e.g., devuser-developer-binding.yaml):
```yaml theme={null}
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: devuser-developer-binding
subjects:
- kind: User
name: dev-user
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: developer
apiGroup: rbac.authorization.k8s.io
```
Create the role binding with the command:
```bash theme={null}
kubectl create -f devuser-developer-binding.yaml
```
## Verifying Roles and Role Bindings
After creating the role and role binding, you can verify them using the following kubectl commands:
* To list roles:
```bash theme={null}
kubectl get roles
```
Example output:
```text theme={null}
NAME AGE
developer 4s
```
* To list role bindings:
```bash theme={null}
kubectl get rolebindings
```
Example output:
```text theme={null}
NAME AGE
devuser-developer-binding 24s
```
To get detailed information about the role, run:
```bash theme={null}
kubectl describe role developer
```
Sample output:
```text theme={null}
Name: developer
Labels:
Annotations:
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
-------- ------------------ --------------- ----
configmaps [] [] [create]
pods [] [] [get watch list create delete]
```
Similarly, to examine the role binding details, use:
```bash theme={null}
kubectl describe rolebinding devuser-developer-binding
```
Expected output:
```text theme={null}
Name: devuser-developer-binding
Labels:
Annotations:
Role:
Kind: Role
Name: developer
Subjects:
Kind Name Namespace
---- ---- ---------
User dev-user
```
## Testing Access Permissions
You can test whether a user has access to specific Kubernetes resources using the `kubectl auth can-i` command:
```bash theme={null}
kubectl auth can-i create deployments
```
Expected output:
```text theme={null}
yes
```
And if you test deleting nodes:
```bash theme={null}
kubectl auth can-i delete nodes
```
Expected output:
```text theme={null}
no
```
If you need to simulate actions as another user, use the `--as` flag. Even though the developer role does not have permission to create deployments, it can create pods:
```bash theme={null}
kubectl auth can-i create deployments --as dev-user
```
Expected output:
```text theme={null}
no
```
```bash theme={null}
kubectl auth can-i create pods --as dev-user
```
Expected output:
```text theme={null}
yes
```
You can also specify a particular namespace using the `--namespace` flag if the permissions are scoped accordingly.
## Granting Access to Specific Resources
In some cases, you might want to restrict a user's permissions to specific resources. For instance, if you need to allow a user to manage only two pods named "blue" and "orange" within a namespace, refine the role rule by including the `resourceNames` field:
```yaml theme={null}
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: developer
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "create", "update"]
resourceNames: ["blue", "orange"]
```
Be cautious when specifying resource names. Only include the exact resources you intend to allow access to, as this will restrict access to other resources of the same type.
## Conclusion
This lesson has demonstrated how to set up and manage RBAC in Kubernetes. By creating roles and role bindings, you can control user permissions precisely within a namespace. For further practice, refer to Kubernetes' official documentation and experiment with real RBAC configurations in your environment.
For additional resources, consider these links:
* [Kubernetes Documentation](https://kubernetes.io/docs/)
* [Kubernetes RBAC Concepts](https://kubernetes.io/docs/reference/access-authn-authz/rbac/)
Happy coding and secure your Kubernetes clusters with effective RBAC management!