RBAC

Kubernetes RBAC and security are inseparable, as weak access control can expose your cluster to security threats, making it vulnerable to unauthorized access and potential breaches. It is not a 'good to have' or an afterthought; it is a fundamental necessity.

Some of you may already know this. Let's quickly revise how RBAC works.

Step 1: Define Roles (Role or ClusterRole): What actions are allowed within a namespace (Role) or across the entire cluster (ClusterRole).

Step 2: Creating Service Accounts or Users/Groups: Set up service accounts within Kubernetes or manage external users/groups to take on these roles.

Step 3: Bind Roles to Accounts, Users, or Groups: Use RoleBindings to connect roles to service accounts or users within a namespace, or ClusterRoleBindings for cluster-wide permissions.

Here is the simplified visualization of Kubernetes RBAC:

To further understand how RBAC operates, let’s break down the key roles in Kubernetes:

Cluster-admin: Acts as a superuser with full control over all resources across the cluster and namespaces.

Admin: Grants complete read and write access within a specific namespace, including creating roles and bindings but not modifying the namespace itself.

Edit: Allows read and write permissions within a namespace, excluding the ability to view or modify roles or bindings.

View: Provides read-only access within a namespace, without permission to view or change roles or bindings.

Creating an RBAC role is straightforward, so let’s not go there. Instead, let’s talk about more crucial elements:

How to Check Defined Permissions:

Always verify what your service accounts can do—blind spots lead to security breaches.

Use kubectl auth can-i

These commands check if the app-sa service account in the prod-app namespace can get secrets, list pods, and create deployments.

• kubectl auth can-i get secrets --namespace=prod-app --as=system:serviceaccount:prod-app:app-sa

  
  

• kubectl auth can-i list pods --namespace=prod-app --as=system:serviceaccount:prod-app:app-sa

  
  

• kubectl auth can-i create deployments --all-namespaces --as=system:serviceaccount:prod-app:app-sa

Why Default service account shouldn’t be used ?

Default service accounts often have broad permissions that can be a security risk. Create and use custom service accounts to better control and limit access.

apiVersion: v1

kind: ServiceAccount

metadata:

name: frontend-sa

namespace: prod-app

Assign this service account to your frontend application pod:

apiVersion: v1

kind: Pod

metadata:

name: frontend-pod

namespace: prod-app

spec:

serviceAccountName: frontend-sa

Disabling auto mounting of service account token

Only mount tokens when absolutely necessary for the pod's operation. This way you reduce the significant risk of token exposures.

apiVersion: v1

kind: Pod

metadata:

name: backend-pod

namespace: prod-app

spec:

serviceAccountName: backend-sa

automountServiceAccountToken: false

Implementing Least Privilege access

Assign only the permissions that are absolutely necessary for a role to perform its tasks. This minimizes potential damage if a service account is compromised.

apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

namespace: prod-app

name: secret-reader

rules:

- apiGroups: [""]

resources: ["secrets"]

verbs: ["get", "list"]

Define roles for different permissions, not for different service accounts

This way, you avoid role duplication and can easily update permissions in one place without worrying about multiple service accounts having differing access levels.

apiVersion: rbac.authorization.k8s.io/v1

kind: Role

metadata:

namespace: prod-app

name: deployment-manager

rules:

- apiGroups: ["apps"]

resources: ["deployments"]

verbs: ["create", "update", "delete"]