> ## 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.
# RBAC
> Learn about role-based access control in Kubernetes, including creating roles, binding them to users, and managing permissions for secure cluster access.
In this lesson, you'll learn about role-based access control (RBAC) in Kubernetes. RBAC enables you to define roles with specific permissions and bind those roles to users or groups, ensuring secure and controlled access within your cluster. We'll walk through creating a role, binding it to a user, verifying configurations, and restricting access to specific resources.
## Creating a Role
A role in Kubernetes is defined in a YAML file that outlines the permitted actions under the following key elements:
* **apiVersion:** Must be set to `rbac.authorization.k8s.io/v1`.
* **kind:** Should be `Role`.
* **metadata.name:** The name of your role (e.g., "developer").
* **rules:** A list describing the API groups, resources, and verbs (actions) that are allowed.
For example, to create a role that allows developers to manage pods and create ConfigMaps, use the following YAML:
```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: ["ConfigMap"]
verbs: ["create"]
```
After saving the YAML file (for instance, as `developer-role.yaml`), create the role with:
```bash theme={null}
kubectl create -f developer-role.yaml
```
Roles and role bindings are namespaced. In the example above, the role is created in the default namespace unless you specify otherwise within the metadata.
## Binding the Role to a User
To grant the permissions defined in the role to a user, you need to create a role binding. A role binding links a user (or group) to a role. The YAML for a role binding includes:
* **metadata.name:** A unique name for the role binding (e.g., "devuser-developer-binding").
* **subjects:** The user, group, or service account to which permissions are granted.
* **roleRef:** A reference to the role created previously.
Below is an example that binds the "developer" role to the user "dev-user":
```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 by running:
```bash theme={null}
kubectl create -f devuser-developer-binding.yaml
```
## Verifying Roles and Bindings
To confirm that the role and its binding have been created successfully, you can list them using the following commands:
List all roles in the current namespace:
```bash theme={null}
kubectl get roles
```
Example output:
```bash theme={null}
NAME AGE
developer 4s
```
List all role bindings:
```bash theme={null}
kubectl get rolebindings
```
Example output:
```bash theme={null}
NAME AGE
devuser-developer-binding 24s
```
To view detailed information about a specific role, use:
```bash theme={null}
kubectl describe role developer
```
This command displays details such as allowed resources and permissions, for example:
```bash theme={null}
Name: developer
Labels:
Annotations:
PolicyRule:
Resources Non-Resource URLs Resource Names Verbs
-------- ------------------ -------------- -----
ConfigMap [] [] [create]
pods [] [] [list, get, create, update, delete]
```
Similarly, inspect the details of the role binding with:
```bash theme={null}
kubectl describe rolebinding devuser-developer-binding
```
The output might look like this:
```bash theme={null}
Name: devuser-developer-binding
Labels:
Annotations:
Role:
Kind: Role
Name: developer
Subjects:
Kind Name Namespace
---- ---- ---------
User dev-user
```
## Checking Permissions
You can verify if you or another user have access to particular resources using the `kubectl auth can-i` command. For example:
To check if you can create deployments:
```bash theme={null}
kubectl auth can-i create deployments
```
Example output:
```bash theme={null}
yes
```
To check if you have permissions to delete nodes:
```bash theme={null}
kubectl auth can-i delete nodes
```
Example output:
```bash theme={null}
no
```
If you want to check permissions for a different user (like "dev-user") without switching accounts, use the `--as` flag. For example, if the dev user has permission to create pods but not deployments, these commands will reflect that:
```bash theme={null}
kubectl auth can-i create deployments
yes
kubectl auth can-i delete nodes
no
kubectl auth can-i create deployments --as=dev-user
no
kubectl auth can-i create pods --as=dev-user
yes
```
Remember, you can also specify the namespace with the `--namespace` flag if needed.
## Restricting Access to Specific Resources
RBAC in Kubernetes allows you to fine-tune permissions at a granular level. Instead of granting permissions universally to a resource type, you can restrict them to specific resources using the `resourceNames` field. For example, to allow a user to interact only with pods named "blue" and "orange", define the role as follows:
```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"]
```
This configuration limits actions strictly to the specified pods.
## Conclusion
In this lesson, we covered how to configure RBAC in Kubernetes by:
* Creating a role with defined permissions.
* Binding a user to that role using a role binding.
* Verifying roles and permissions through `kubectl` commands.
* Checking and testing user permissions.
* Restricting access to specific resources for enhanced security.
For additional information on Kubernetes RBAC, consider reviewing the [Kubernetes Documentation](https://kubernetes.io/docs/reference/access-authn-authz/rbac/). Continue practicing by applying these concepts to secure your cluster effectively.