Assessing Kubernetes RBAC: Methodology and Tradeoffs // DaemonCore Field Notes

// Understanding RBAC in Kubernetes

Role-Based Access Control (RBAC) in Kubernetes governs how permissions are granted to users and service accounts. Misconfigurations can create significant security vulnerabilities, making a systematic review of RBAC configurations paramount.

// Methodology for RBAC Assessment

Conducting an RBAC assessment involves several steps: 1. Inventory Existing Roles: List out all roles, role bindings, cluster roles, and cluster role bindings. 2. Map Permissions: Understand what resources each role has access to, and what actions they can perform on those resources. 3. Identify Users and Service Accounts: Determine who (users or service accounts) has been assigned roles and cluster roles. 4. Evaluate Least Privilege: Ensure roles adhere to the principle of least privilege, providing only the necessary permissions. 5. Review Role Bindings: Confirm that role bindings are assigned to the correct subjects. 6. Check for Overlapping Permissions: Analyze if roles overlap in permissions, which could lead to privilege escalation.

// Practical Steps

1. Inventory Existing Roles

Use the following commands to retrieve the current RBAC configurations:

kubectl get roles --all-namespaces
kubectl get rolebindings --all-namespaces
kubectl get clusterroles
kubectl get clusterrolebindings

2. Map Permissions

To examine the permissions of each role, you can describe them:

kubectl describe role <role-name> -n <namespace>
kubectl describe clusterrole <cluster-role-name>

This will provide details such as verbs (actions) and resources (what you can act upon).

3. Identify Users and Service Accounts

To see which users and service accounts are linked to roles, you’ll want to check role bindings:

kubectl get rolebindings -n <namespace> -o yaml
kubectl get clusterrolebindings -o yaml

4. Evaluate Least Privilege

A common mistake is granting too many permissions. For instance, if a role contains:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: admin-role
  namespace: default
rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["*"]

This role grants unrestricted access across all resources, violating the least privilege principle.

Common Pitfalls

Overly Broad Role Definitions: Avoid roles with `resources: [