Authentication, how someone can gain access to a cluster.
Once they gain access, what can they do? That is what authorization defines.
Why Authorization?
An administrator of the cluster, we were able to perform all sorts of operations in it, such as viewing various objects like pods, nodes, and deployments, also, creating or deleting objects such as adding or deleting pods or even nodes in the cluster. How about the other administrators, developers, testers, or other applications like monitoring applications or continuous delivery applications like Jenkins. So we need to create accounts for them to access the cluster by creating usernames and passwords or tokens or assigned certificates or service accounts.
What if the user is a developer? we can allow them to view, but not modify, but they could have access to deploy applications.
When we share our cluster between different organizations or teams by logically partitioning it using namespaces, we want to restrict access to the users, to their namespaces alone. That is what authorization can help you within the cluster.
Authorization Mechanisms
There are different authorization mechanisms supported by communities such as Node Authorization, Attribute Base Authorization, Role Base Authorization, and Webhook.
Node Authorization
Kube-apiserver is accessed by users like us for management purpose as well as the Kubelet on a node within the cluster for management purpose, within the cluster, the Kubelet that accesses the Kube-apiserver to read information about services, endpoints, nodes, and pods.
The Kubelet also reports to the Kube-apiserver with information about the node such as its status. These requests are handled by a special authorizer known as the node authorizer.
Attribute Base Authorization
External access to the API, for instance a user attribute based authorization is where you associate a user or a group of users with a set of permissions.
Developer can view pods, create pods, and delete pods.
https://kubernetes.io/docs/reference/access-authn-authz/abac/
- dev-1, dev-2, dev-3 can do anything to all resources:
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "dev-1", "namespace": "*", "resource": "*", "apiGroup": "*"}}
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "dev-2", "namespace": "*", "resource": "*", "apiGroup": "*"}}
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "dev-3", "namespace": "*", "resource": "*", "apiGroup": "*"}}Every time you need to add or make a change in the security you must edit the policy file manually and restart the kube-apiserver.
Role Base Authorization
Role-Based Authorization, instead of directly associating a user or a group with a set of permissions, we define a role in the cases for developers. We create a role with the set of permissions required for developers. Similarly, create a role for security users with the right set of permissions required for them, then associate the user to that role going forward whenever a change needs to be made to the users’ access.
Role-Based Authorization to provide a more standard approach to managing access within the Kubernetes cluster.
Webhook
What if you want to outsource all the authorization mechanisms, say you want to manage authorization externally and not through the built-in mechanisms. For instance, an open policy agent is a third-party tool that helps with admission control and authorization.
AlwaysAllow and AlwaysDeny
AlwaysAllow: always allow all requests.
AlwaysDeny: always deny all requests.
When you have multiple modes configured, your request is authorized using each one in the order it is specified. every time a module denies the request, it goes to the next one in the chain, and as soon as a module approves the request, no more checks are done and the user is granted permission.
https://kubernetes.io/docs/reference/access-authn-authz/authorization/