How to: Kubernetes Authorization

September 14, 2022

Let’s talk about Kubernetes Authorization!

Kubernetes or K8s is an open-source container orchestration principle that streamlines many of the manual operations convoluted to manage, scale and deploy containerized applications.

With Kubernetes being known for being impenetrably complicated, authorization or being granted access is required first to perform any actions.

Authorization in Kubernetes defines whether a user or an application has permission to perform a particular action, like get, create, update, delete, etc.

The scope of Kubernetes authorization is divided into two:

Namespace and Clusters

Namespaces are individual groups of organized and unique resources with the ability to communicate with each other.

If you’re working with multiple users, namespaces are a great way to divide your resources between them.

On the other hand, Clusters are the accumulation of namespaces with containerized applications within nodes.

The condition of a Kubernetes cluster interprets many functional elements such as running applications and workloads, quantities of replicas, and more!

Restricting access to a Namespace where resources are isolated is generally better than doing it in a Cluster where access restriction will affect multiple namespaces at the same time.

Namespaces and Clusters have their own set of access control objects

  • Namespace - Roles & RoleBinding
  • Clusters - ClusterRoles & ClusterRoleBindings

Roles define what permissions and policies somebody has in their scope.

For example, the Developer role can access Secrets, Pods, Create Resources, and more!

On the other hand, RoleBindings will 'bind' a role to an individual or group of users, service accounts, etc.

Most privilege escalation attacks happen because of excessive permissions given to users!

The biggest culprits are ClusterRoles & ClusterRoleBindings, which give permissions across the whole cluster instead of a particular namespace.

Be VERY careful when managing these!

Role-Based Access Control or RBAC asks one question:

Can [subject]→[action]→[object]?

RBAC limits a subject to stay within their roles.

The 'subject' is the user, the group of users, or the role, while 'action' can be the type of access like get, create, update, delete, etc.

For example, user 'Bob' wants to get access to a certain pod.

RBAC asks: 'Can [Bob]→[get]→[pod]?

If Bob's permissions allow it, he can access the pod in question.

One important thing to remember about RBAC is that it’s Allow-Only. There is no such rule as ‘Deny’ for implementing restrictions on subjects.

Set your RBAC policy to explicitly allow access to a resource while making sure that no conflict is present between roles.

That way, every other permission is denied by default across the entire cluster.

Continue exploring the BASICS of Kubernetes Security with AppSecEngineer’s courses! 

Click here to start learning!

Aneesh Bhargav

Aneesh Bhargav

When Aneesh is not creating career-focused security content, he’s probably playing video games.