Kubernetes Authentication, Authorization & Audit. Part 1
Sooner or later, a security issue arises in any system's operation: ensuring authentication, separation of rights, auditing, and other tasks. Many solutions have already been created for Kubernetes that allow you to achieve compliance with standards even in a very demanding environment. This article is devoted to the basic aspects of security implemented within the framework of built-in K8s mechanisms. It will be useful for those just starting to get acquainted with Kubernetes — as a starting point for studying security-related issues.
Authentication
There are two types of users in Kubernetes:
- Service Accounts — accounts managed by the Kubernetes API;
- Users — normal users managed by external, independent services.
The main difference between these types is that there are special objects in the Kubernetes API for Service Accounts, which are tied to a namespace and a set of authorization data stored in the cluster in Secrets objects. Such users (Service Accounts) are intended to manage access rights to the Kubernetes API of processes running in the Kubernetes cluster. Regular Users do not have entries in the Kubernetes API: they must be managed by external mechanisms. They are intended for people or processes living outside the cluster.
Each API request is bound to either a Service Account or a User or is considered anonymous. User authentication data includes:
- Username — the case-sensitive username;
- UID — a machine-readable user identification string that is “more consistent and unique than the username”;
- Groups — a list of groups the user belongs to;
- Extra — additional fields that can be used by the authorization mechanism.
Kubernetes can use a large number of authentication mechanisms: X509 certificates, Bearer tokens, authenticating proxy and HTTP Basic Auth. Using these mechanisms, you can implement a large number of authorization schemes: from a static file with passwords to OpenID OAuth2. Moreover, it is possible to use several authorization schemes simultaneously. By default, the cluster uses:
- Service account tokens — for Service Accounts;
- X509 — for Users.
The question of managing ServiceAccounts is beyond the scope of this article, and for those who want to learn more about this issue, I recommend starting with the official documentation page. We will consider in more detail the issue of how X509 certificates work in the next part.
You can say Hi to us at Pharos Production — a software development company
Follow our product Ludo — the reputational system of the Web3 world
