Authorization

Authorization

Once a request is authenticated, it needs to be authorized to be able to proceed through the Kubernetes system and perform its intended action.

There are three main authorization modes and two global Deny/Allow settings. The three main modes are:

• ABAC
• RBAC
• Webhook.

They can be configured as kube-apiserver startup options:

• --authorization-mode=ABAC

• --authorization-mode=RBAC

• --authorization-mode=Webhook

• --authorization-mode=AlwaysDeny

• --authorization-mode=AlwaysAllow

The authorization modes implement policies to allow requests. Attributes of the requests are checked against the policies (e.g. user, group, namespace, verb).

Attribute Based Access Control (ABAC)

It was the first authorization model in Kubernetes that allowed administrators to implement the right policies. Today, RBAC is becoming the default authorization mode.

Policies are defined in a JSON file and referenced to by a kube-apiserver startup option:

• --authorization-policy-file=my_policy.json

For example, the policy file shown below authorizes user Bob to read pods in the namespace foobar:

{
    "apiVersion": "abac.authorization.kubernetes.io/v1beta1",
    "kind": "Policy",
    "spec": {
        "user": "bob",
        "namespace": "foobar",
        "resource": "pods",
        "readonly": true     
    }
}

You can check other policy examples in the Kubernetes Documentation.

Role Based Access Control (RBAC)

All resources are modeled API objects in Kubernetes, from Pods to Namespaces. They also belong to API Groups, such as core and apps. These resources allow operations such as Create, Read, Update, and Delete (CRUD), which we have been working with so far. Operations are called verbs inside YAML files. Adding to these basic components, we will add more elements of the API, which can then be managed via RBAC.

Rules are operations which can act upon an API group. Roles are a group of rules which affect, or scope, a single namespace, whereas ClusterRoles have a scope of the entire cluster.

Each operation can act upon one of three subjects, which are User Accounts which don't exist as API objects, Service Accounts, and Groups which are known as clusterrolebinding when using kubectl.

RBAC is then writing rules to allow or deny operations by users, roles or groups upon resources.

While RBAC can be complex, the basic flow is to create a certificate for a user. As a user is not an API object of Kubernetes, we are requiring outside authentication, such as OpenSSL certificates. After generating the certificate against the cluster certificate authority, we can set that credential for the user using a context.

Roles can then be used to configure an association of apiGroups, resources, and the verbs allowed to them. The user can then be bound to a role limiting what and where they can work in the cluster.

Here is a summary of the RBAC process:

1. Determine or create namespace

2. Create certificate credentials for user

3. Set the credentials for the user to the namespace using a context

4. Create a role for the expected task set

5. Bind the user to the role

6. Verify the user has limited access.

Webhook

A Webhook is an HTTP callback, an HTTP POST that occurs when something happens; a simple event-notification via HTTP POST. A web application implementing Webhooks will POST a message to a URL when certain things happen.

To learn more about using the Webhook mode, see the Webhook Mode section of the Kubernetes Documentation.