Authorization Mechanisms in K8s

Always Allow

Allow all the requests made to the KubeAPI Server.

Always Deny

Deny all the requests made to the KubeAPI Server.

Node Authorizer

Used to authorize Kubelet service to send information, about the pods running on the worker nodes, to the KubeAPI server. Kubelet should be part of system:nodes group and have name prefixed with system:node to be authorized by the node authorizer. Node authorizer performs access control within the cluster.

Attribute Based Access Control (ABAC)

Authorize users by specifying the allowed permissions for every user or group. This is done by creating a policy file (JSON) for each user or group and passing it to the KubeAPIServer.

Later, if we want to modify the permissions for a set of users, we need to edit the permissions for all those users and restart the KubeAPIServer. Therefore, ABAC is difficult to manage.

Untitled

Role Based Access Control (RBAC)

Instead of defining permissions for each user or group as with ABAC, we define roles with the right set of permissions and associate users and groups to these roles accordingly.

Later, if we want to modify the permissions of a role, we can do it once and it will reflect for all the users who are associated to that role.

Untitled

Webhook

We can outsource authorization to a 3rd party solution (eg. Open Policy Agent) outside the K8s cluster using webhooks. K8s will make a request to the the external authorization server with the information about the user and their access requirements and let the authorization server decide whether or not the user should be allowed.

Untitled