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:
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.
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!
Aneesh Bhargav is the Head of Content Strategy at AppSecEngineer. He has experience in creating long-form written content, copywriting, producing Youtube videos and promotional content. Aneesh has experience working in Application Security industry both as a writer and a marketer, and has hosted booths at globally recognized conferences like Black Hat. He has also assisted the lead trainer at a sold-out DevSecOps training at Black Hat. An avid reader and learner, Aneesh spends much of his time learning not just about the security industry, but the global economy, which directly informs his content strategy at AppSecEngineer. When he's not creating AppSec-related content, he's probably playing video games.
Joshua Jebaraj is the Creator of GCP-Goat. He works as Security Researcher at we45 focusing on cloud and cloud-native security. He has 3+ years of experience working related to containers and Kubernetes. He has also spoken at conferences like Defcon, Owasp-Seasides, Bsides-Delhi, and Eko-party. When AFK, he can be found watching movies and making memes.
Contact Support
help@appsecengineer.com
1603 Capitol Avenue,
Suite 413A #2898,
Cheyenne, Wyoming 82001,
United States
.svg)
.png)
.png)
.png)
.png)
