Shulou(Shulou.com)05/31 Report--

This article will explain in detail how to analyze identity authentication and authorization in K8S and Rancher 2.0. the content of the article is of high quality, so the editor shares it for you to do a reference. I hope you will have a certain understanding of the relevant knowledge after reading this article.

The official version of Rancher 2.0 has been fully released. Rancher 2.0 is an open source Kubernetes management platform that provides Kubernetes-as-a-Service (Kubernetes as a service) for enterprise users and enables unified management of multiple Kubernetes clusters. This creative unified nanomanagement function will solve the different infrastructure dilemmas that enterprise users may face in a production environment. Rancher 2.0 is the industry's first platform to unify Kubernetes services hosted on public clouds such as Google (GKE), Amazon (EKS), and Azure (AKS).

In Rancher 2.0, one of the areas we focus on is authentication and authorization. In addition to the powerful basic features of Kubernetes, Rancher 2.0 is particularly focused on simplicity and ease of use, which is a powerful and easy-to-use system. Rancher 2.0 enables administrators to manage multi-cluster environments, while also helping users get up and running the environment quickly. The following describes what benefits Rancher can bring to organizations, administrators, and users from the perspective of authentication and authorization.

Identity authentication

To understand Kubernetes authentication and how Rancher extends and enhances this functionality, you must first understand the following key concepts: authentication policies, users and groups, and user impersonation.

Authentication Policy (Authentication Strategies)

Kubernetes provides a variety of authentication strategies, including: client certificate, OpenID Connect token, Webhook token authentication, authentication agent, service account token, and so on. Each strategy has its advantages and disadvantages, but ultimately they are responsible for determining the identity of the user applying for the API call, so that the Kubernetes RBAC framework can decide whether to authorize the caller to perform the requested operation.

Although there are a large number of available policies that can address most situations, it is important to note that configuring them requires precise control over the configuration and deployment of the Kubernetes control platform. Cloud service providers like Google usually lock it down to prevent users from configuring it according to their preferences. Rancher 2. 0 solves this problem, which we will discuss later.

Users and groups (Users and Groups)

Kubernetes has two types of users: service accounts and regular users. The service account is completely managed by Kubernetes, while "ordinary" users are not managed by Kubernetes at all. In fact, Kubernetes has no API resources for users or groups. So in the end, ordinary users and groups behave as obscure objects in the user binding, which are used to check permissions.

User simulation (User Impersonation)

User impersonation in Kubernetes is the ability of one user (or service account) to act as another. A subject must explicitly have the "impersonation" privilege to perform impersonation to other users. While this may seem like a rather vague and subtle feature, it is critical to how Rancher implements authentication.

Delegation of authority

To understand authorization in Kubernetes and how Rancher builds it, you must also understand these concepts: roles (role), clusterRoles (cluster role), roleBindings (role binding), and clusterRoleBindings (cluster role binding). As can be seen from the naming, these concepts are very similar, but apply to different ranges.

Roles is a scope of a namespace, which means that it is created in the namespace and can only be referenced by roleBinding within that namespace. RoleBinding creates associations between users, groups, or service accounts (called subject in Kubernetes) and role in the namespace. It effectively illustrates that user X has a Y role in namespace Z, or we give a specific example: Sarah can create, update, and delete deployments in the namespace "dev".

ClusterRole is very similar to role in appearance and function. The only difference is that it has no namespace. ClusterRole is defined at the cluster level. Similarly, clusterRoleBinding is a namespace-free version of roleBinding. When you create a clusterRoleBinding, it means that you give permissions to a particular subject that can be used for each namespace of the entire cluster.

It is important to note that roleBinding can refer to role or clusterRole. Regardless of the type of role it references, permissions apply only to the namespace in which rolebinding resides.

With an understanding of the basic concepts of Kubernetes, we can then begin to discuss how Rancher uses and enhances them to create a powerful and easy-to-use authentication and authorization system.

Authentication and Authorization of Rancher

One of the main goals of Rancher 2.0 is to help system administrators run multiple heterogeneous Kubernetes clusters. These clusters can be any combination of cloud providers or local solutions, which creates many interesting authentication and authorization challenges. The key issues that we have identified and solved are:

How to have a unified authentication experience in different types of clusters?

How to manage users and permissions across clusters?

How to enable "automatic service" to use clusters while maintaining an appropriate level of control?

How to prevent users from getting too much access to underlying infrastructure resources in a low-trust environment?

We will discuss each challenge next.

Unified authentication

In order to achieve a unified authentication experience across clusters, we designed the Rancher server as the central point of all authentication. The administrator only needs to configure the authentication tool in Rancher once, and it can be applied anywhere. After that, Rancher acts as an authentication agent in the face of all requests to access the Kubernetes cluster.

Because most cloud providers do not expose the various authentication policies necessary for hooks to insert Kubernetes, the authentication agent for Rancher is external and exists independently of the cluster. It performs the necessary authentication work, collects the user's identity and any groups, and then forwards the request to the appropriate cluster through user impersonation to act as the user. Because the authentication method is standard Kubernetes unnumbered tokens, Rancher agents can be seamlessly plugged into existing Kubernetes tools such as kubectl.

User management

As mentioned before, Kubernetes doesn't have a first-class user philosophy, while Rancher does. Users can be created manually by an administrator or on demand with authentication tools such as GitHub (Github requires a user login the first time it is opened). We learned from Rancher 1.x that by default, local authentication is on and always on. As a result, Rancher is secure by default and provides a backup mechanism to access Rancher in the event of an authentication tool failure.

Creating a first-class user resource that resides on a central Rancher server can bring many benefits. For example, administrators can now view and manipulate the access rights of any particular user to all clusters. It also enables Rancher to manage resources specific to each user, such as system preferences, API tokens, and node templates. Finally, it makes it easier to manage user permissions, which we will discuss below.

RBAC authorization

Before going any further into authorization, we must introduce and discuss a key Rancher concept: projects. A project is a collection of namespaces that can be applied to various policies. These policies (not all of which are in our initial GA version) include RBAC, network access, pod security, and quota management. The project "owns" namespace, and any RBAC bindings made for the project apply to all namespaces in the project. This key concept allows clusters to be effectively divided and organized into smaller, more manageable blocks (chunks).

Rancher effectively provides users with three layers of roles or permissions: global, cluster, and project levels. Globally defines the operations that you can perform outside a single cluster. For most people, this can be thought of as marking a subset of users or groups as "administrators" and the rest as "normal" users. In addition to having full access to all clusters, administrators can also perform operations such as configuring authentication providers and managing users. Ordinary users can only access clusters or projects that they own or have been invited.

Rancher RBAC builds directly on top of Kubernetes RBAC (the concepts of role and binding discussed earlier). If you understand the concept of Kubernetes, Rancher RBAC is easy to understand. In fact, we create roles and bindings templates in the Rancher server and propagate them to the appropriate clusters. Therefore, we have the following custom resources in Rancher API: roleTemplates,clusterRoleTemplateBindings and projectRoleTemplateBindings. Administrators can manage roleTemplates and clusters, and project owners can use them to grant varying degrees of access to their clusters or projects.

Self-service access

Rancher supports self-service access mode by default to help organizations authorize users to obtain more information from Kubernetes. Ordinary users can create their own clusters and become their owners. They are administrators of the cluster and can set other users and groups as cluster members and grant them access. Once the user becomes a member of the cluster, it can create projects in the cluster and become the owner of those projects. As a project owner, you can invite others to be called project members or owners. Project members can create namespaces and deploy workloads in the projects to which they belong. You can see how this self-service system is created and allows users to start and run quickly and easily.

In this way, there is also a common question: "what if I don't want users to create clusters or projects?"

There are several answers to this question. First, if they do not have access to infrastructure resources (meaning they cannot create virtual machines or do not have the key to organize cloud providers), they cannot create functional clusters. Second, our RBAC system is configurable so that administrators can clearly choose what users can do by default. Finally, users can be added directly to the project without creating explicit cluster members. This means that they will not be able to create new projects, but can only use those projects to which they have been explicitly added. In this way, Rancher enables organizations to authorize their users while giving administrators the control they need.

Control access at the infrastructure level

Many use cases require users to limit the types of containers they can deploy and what these containers are allowed to execute. To solve this problem, Kubernetes moved out of podSecurityPolicies. This is a very important feature, but its original form is difficult to use correctly. These discussions about how it works and what it can do are outside the scope of this article, but we can sum it up like this: podSecurityPolicies allows administrators to limit the types of pod that can be deployed in a cluster. To use a simple and easy-to-understand example, it prevents users from deploying privileged containers, which solves large security vulnerabilities for many use cases.

Rancher not only supports podSecurityPolicies, but also enhances this feature, greatly improving usability. With Rancher, administrators can globally define a set of podSecurityPolicy templates for all clusters. The cluster owner can then assign the default policy to the cluster and manage exceptions on a per-project basis. In other words, the cluster owner can say, "except for a few special projects, all projects have a restriction policy that prevents them from deploying privileged containers." This feature can be used for secure multi-tenant clusters.

On how to analyze K8S and Rancher 2.0 identity authentication and authorization to share here, I hope the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.