Access Control

Kubernetes Role-Based Access Control (RBAC) is a critical mechanism for enforcing security and compliance by defining granular permissions for users, service accounts, and system components. By restricting access to only what is necessary, RBAC helps prevent accidental or malicious modifications to cluster resources. This section covers how to configure RBAC to manage permissions effectively.

---

Understanding RBAC Components

Kubernetes RBAC revolves around four core objects: - Role: Defines permissions within a single namespace. - ClusterRole: Defines permissions across the entire cluster. - RoleBinding: Binds a Role to a subject (user, group, or service account) within a namespace. - ClusterRoleBinding: Binds a ClusterRole to a subject across the entire cluster.

Permissions are specified using verbs (e.g., get, list, create) and resources (e.g., pods, services). For example, a Role might allow a user to get and list pods in a namespace.

Example: A Role that allows reading pods:

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

---

Creating Roles and RoleBindings

To enforce access control, create Roles and bind them to users or service accounts. Here’s how to define a Role and assign it to a user:

1. Define a Role (as shown above).
2. Create a RoleBinding to associate the Role with a user:

   apiVersion: rbac.authorization.k8s.io/v1
   kind: RoleBinding
   metadata:
     name: read-pods
     namespace: default
   subjects:
   - kind: User
     name: alice
     apiGroup: rbac.authorization.k8s.io
   roleRef:
     kind: Role
     name: pod-reader
     apiGroup: rbac.authorization.k8s
   

Apply these configurations using kubectl apply -f <filename>.yaml.

Verification: Check permissions with:

kubectl auth can-i get pods --as alice

---

ServiceAccount Integration

Service accounts are automatically created for pods and can be granted permissions via RoleBindings. For example, to allow a pod’s service account to access a specific resource:

1. Create a ServiceAccount (optional, as one is created by default):

   apiVersion: v1
   kind: ServiceAccount
   metadata:
     name: my-sa
     namespace: default
   

2. Bind a Role to the ServiceAccount:

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

This grants the service account access to the defined resources.

---

Best Practices

• Principle of Least Privilege: Assign only the permissions necessary for a task.
• Audit Regularly: Use kubectl get rolebindings and kubectl get clusterrolebindings to review access.
• Use ClusterRoles for Cluster-Wide Access: For resources like nodes or clusters, use ClusterRole and ClusterRoleBinding.
• Separate Duties: Avoid granting broad permissions to a single user or service account.

Example: A ClusterRole for cluster-admin access:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-admin
rules:
- apiGroups: [""]
  resources: ["*"]
  verbs: ["*"]

---

Key takeaways

• RBAC components (Roles, ClusterRoles, RoleBindings, ClusterRoleBindings) define and enforce access control in Kubernetes.
• Granular permissions using verbs and resources ensure users and service accounts have only necessary access.
• Service accounts can be securely integrated with RBAC to manage pod-level permissions.
• Best practices like least privilege and regular audits help maintain cluster security and compliance.