Kubernetes is a powerful system, but power must be controlled. Authorization ensures that only the right people and systems can perform actions within a cluster. Without it, chaos would reign.
In this post, we’ll review the concept of authorization in K8s and the different mechanisms we can use to secure the actions of our users in the K8s cluster.
Authentication vs. Authorization
First, let's clarify a common point of confusion: authentication versus authorization. They sound similar, but they serve different purposes.Authentication answers the question: Who are you? It verifies identity using certificates, passwords, or tokens. This is like showing your ID at a club. It verifies who you are. Kubernetes checks your credentials. Are you a valid user? Are you a valid service account? But knowing who someone is doesn’t mean they should be allowed to do anything they want.
That’s where authorization comes in. It answers: What are you allowed to do? Once Kubernetes verifies identity, it checks permissions before granting access to resources. This is like the bouncer checking your VIP list. It determines what you can do. Even if you're a valid user, can you create pods? Can you delete namespaces?
Why Authorization Matters
Without authorization, anyone with access could delete deployments, change configurations, or expose sensitive data. This is a massive security risk. We must control who can do what. Kubernetes authorization protects the cluster by defining clear rules on who can perform what actions and where.Kubernetes Authorization Mechanisms
1. Role-Based Access Control (RBAC)
RBAC is the most common authorization method. It uses roles and bindings to define what users and applications can do.- Roles define allowed actions (e.g., reading pods, creating services).
- RoleBindings link users, groups, or service accounts to a role.
- ClusterRoles and ClusterRoleBindings work across the entire cluster.
2. Attribute-Based Access Control (ABAC)
ABAC allows authorization based on attributes, like username, groups, or request metadata. Policies are defined in JSON files. Rules can consider multiple factors, making ABAC highly flexible. We normally use ABAC when we need complex policies that go beyond roles and permissions.3. Node Authorization
Worker Nodes also need permission to perform actions, such as reading pod specs or updating statuses. The Node Authorizer is a special purpose authorizer. It grants permissions to kubelets. This way, the Node authorizer allows kubelets to access only the resources they manage. This prevents a compromised node from affecting others.4. Webhook Authorization
This method delegates decisions to an external service. Kubernetes sends authorization requests to a remote webhook. The webhook checks permissions and responds with “allow” or “deny.”We would normally use Webhook Authorization when we need custom authorization logic, such as integrating with external security policies.