Kubernetes Authentication, Authorization & Audit. Part 3

Part 1 is here

Part 2 is here

Authorization

An authenticated account by default has no rights to act in the cluster. Kubernetes implements an authorization mechanism to grant permissions. Before version 1.6, Kubernetes used an authorization type called ABAC (Attribute-based access control). Details about it can be found in the official documentation. This approach is now considered legacy, but you can still use it with other authorization types.

The current (and more flexible) way of separating access rights to the cluster is called RBAC (Role-based access control). It was declared stable with Kubernetes 1.8. RBAC implements a rights model in which everything that is not explicitly allowed is prohibited. To enable RBAC, you must run the Kubernetes API-server with the “ — authorization-mode=RBAC” parameter. The parameters are set in the manifest with the api-server configuration, which by default is located at /etc/kubernetes/manifests/kube-apiserver.yaml, in the command section. However, RBAC is already enabled by default, so most likely you don’t need to worry about it. You can verify this by the authorization-mode value (in the already mentioned kube-apiserver.yaml). By the way, other authorization types may be among its values ​​(node, webhook, always allow).

The following API entities are used to manage access to Kubernetes via RBAC:

• Role and ClusterRole — roles that are used to describe access rights.
  Role allows you to describe rights within a namespace;
• ClusterRole — within a cluster, including cluster-specific objects such as nodes, and non-resource URLs (i.e. not related to Kubernetes resources — for example, /version, /logs, /api*);
• RoleBinding and ClusterRoleBinding — are used to bind a Role and ClusterRole to a user, user group, or ServiceAccount.

Role and RoleBinding entities are namespace-bound, meaning they must be within the same namespace. However, a RoleBinding can reference a ClusterRole, allowing you to create a set of generic permissions and manage access using them.

Roles describe permissions using rule sets containing:

• API groups — see the official documentation on apiGroups and the output of kubectl api-resources;
• resources (pod, namespace, deployment, etc.);
• verbs (set, update, etc.);
• resource names (resourceNames) — for when you need to grant access to a specific resource, rather than all resources of this type.

Examples of RBAC entities

A simple Role that allows you to get the list and status of pods and monitor them in the target-namespace

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: target-namespace
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

An example of a ClusterRole that allows you to get a list and status of pods and monitor them across the entire cluster

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

An example of a RoleBinding that allows the user mynewuser to “read” pods in the my-namespace namespace

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: target-namespace
subjects:
- kind: User
  name: mynewuser
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

You can say Hi to us at Pharos Production — a software development company

https://pharosproduction.com

Follow our product Ludo — the reputational system of the Web3 world

https://ludo.com