Rancher certification and Authentication (1)

Many of the details of authentication and authentication were omitted in the previous article, which covered cluster registration and cluster management. This part of the concept is really rather convoluted.

For a straightforward example, the tunnel auth in the previous section vaguely states that the agent submits a JWT and Rancher approves the request through this JWT on the server side. So is this authentication or authentication? Sounds like you’re listening to one of them. For another example, does OAuth do authentication or authorization?

I’ve met a lot of people in the interview, and people often say that they know that the last thing is to give users access to business resources through the permission control system. Even have classmate query me: za also not kong yi ji, buckle what word? If it works, it’s done.

That’s true from a usage point of view, but we’re engineers after all, so let’s talk a little bit more thoroughly about authentication and authentication.

In this article, I won’t

1. Describe the technical details of k8S and Rancher’s various certifications, such as what commands are used to issue a KubeconFig; For example, what are the meanings of the various fields of THE RBAC of K8S
2. Give some background details, such as SSL, JWT

To learn about the usage, go to the official documentation. In this article, I will

1. Introduce the meanings of the various nouns we encounter, and what are their differences and connections?
2. Introduces k8S and Rancher’s authentication and authentication gameplay, as well as their advantages and disadvantages

Therefore, this article is not an introduction to authn & AuthZ. It belongs to students who have a certain understanding of Authn & AuthZ and are interested in a little in-depth study.

How do we learn?

Certification and authentication is a complete set of knowledge system and methodology. Reading this article is certainly not enough. I would like to record here how we can understand the knowledge system of certification and authentication. Triggered by my experience, I am willing to find new knowledge points from the explanation of nouns and establish connections with existing knowledge.

For example, wikipedia on Authentication says:

Authentication is the act of proving an assertion, such as the identity of a computer system user. In contrast with identification, the act of indicating a person or thing’s identity, authentication is the process of verifying that identity.

Authentication is the process of proving that a user is who he claims to be. After reading the whole article, we introduced some new terms: user, identity, account.

From the Authorization wikipedia:

Authorization is the function of specifying access rights/privileges to resources, which is related to general information security and computer security, and to access control in particular.

Authentication is the process of verifying access to a particular resource. So we introduced new terms: authorize, Access Control, RBAC, etc…

By looking for explanations for each of these terms and recognizing their nuances, we can step by step build our own knowledge of authentication and authentication.

1. Let’s start with the basics

1.1 I am not Kong Yiji, but I still want to tell you three ways of writing Hui Character

Let’s list some of the basic, key concepts that I feel I have to identify carefully.

The above definition may be more obscure for novices, in fact, take an example in life, it is easy to understand a lot.

Let’s say Xiao Ming takes his ID card to do high-speed rail.

Xiao Ming is a user, and the back-end system is a high-speed train. What Xiao Ming wants to do is to take a certain train to a certain station at a certain time.

Ming placed his ID card on the gate at the security checkpoint and went through the gate through face recognition to enter the high-speed train station.

Ming’s identity is defined by his id card, which is kept unique by his id number. The country’s identity website, Identity Provider, provides identity information to HSR.

When Ming wanted to pass through the gate, he first held an id card and declared that I was Ming’s counterpart, and this ID card could be regarded as a certificate. At its simplest, the system can only recognize Ming’s ID card and assume that the person holding this ID card is Ming. But obviously, if xiaoming ID card is lost, there are lawbreakers with xiaoming ID card how to do? So the authentication process here also includes face recognition.

Id cards and face recognition can be analogous to tokens and passwords. The ID card is similar to a token, which is the identity certificate of the state after Ming comes of age. It is not controlled by Ming independently and actively. Xiaoming’s face is a kind of biological code, which xiaoming was born with and input actively, and its initiative is in xiaoming’s hands.

After passing all the tests, Xiao Ming passed the system’s authentication and proved his identity.

Xiaoming on the car before the ID card on the brake machine, through the platform, smooth by the car.

The gate has done both authentication and authentication (authentication steps are the same as before, through the ID card to complete the authentication). The person who swipes his card at this gate is taking the XXX train. The gate checked the back end system. Since Xiao Ming had bought a ticket on 12306, the gate found the ticket purchase record of the user account corresponding to Xiao Ming and believed that the identity corresponding to this account could take the train, so it passed the authentication.

Here are four very important points:

1. There is a one-to-one correspondence between user and identity
2. Each account has a unique identity
3. Authentication is account-oriented and requires proof of identity
4. Authentication is identity-oriented, and you need to prove that the identity has sufficient permissions

I wonder if you have a better understanding of authentication and authentication through this example? If so, in the next section we will take K8S as an example to see how k8S does authentication and authentication.

1.2k8s Authn & Authz

You can refer to the official user authentication section. The entire document can be summarized in the following key points:

1. The K8S does not manage users but only service accounts
2. K8s supports public and private keys, tokens, and Authentication proxy
3. K8s support for OIDC is rather limited (more on that in a moment)
4. K8s Supports impersonation

Reference for authentication

1.2.1 What is service Account

An account can be classified into user Account and service Account. The user account corresponds to a terminal user, while the service account refers to an internal service account and does not correspond to a real identity. In microservices, for example, a service Account might be an account for an instance of a microservice.

Service account is usually managed by K8S itself. The management logic is compiled into the source code of Apiserver as a kind of Admission Controller. See Using an Access Controller.

A POD can declare the use of a service account, and then make a request from a POD to apiserver. Apiserver will assume that the service account originated it. It doesn’t matter if a program is running in a POD or if anyone exec a request into the POD.

Typically, a service account is associated with a Secret, which holds the public CA certificate, namespace, and token:

• CA certificate: used as the server to verify this request, because we generally use a self-signed certificate for K8S, so the request needs to carry a “public key”. This knowledge, which involves cryptography, is beyond the scope of this article. For those interested, please refer to protocol Forest 17 (SSL/TLS protocol).
• Token: is a standard JWT.

JWT is not mentioned here, but should be used as a credential for unfamiliar readers. You can see Tokens via Kubectl, base64 decode, and then decrypt this website at JSON Web Tokens (JWT) to see the decoded content. These are trivial and will not be covered here.

1.2.2 impersonation is what

Impersonation just sounds scary, and it always feels like impersonation. Impersonation allows user A to execute commands as user B by adding specific headers. The advance condition is that user A has sufficient permissions to masquerade as user B.

Impersonation is typically associated with hosting accounts. When different systems are interconnected, system A has A management account in system B that has sufficient permissions to perform operations from system A to system B.

Let’s say I built a management system based on K8S. Users can log in to my system and create tasks on K8S. At this time, IN terms of account, I can do the following:

1. Full sync: My account is k8S account. For a new user, I issue an X509 certificate on K8S using OpenSSL and give the certificate to the user. The user’s request carries this certificate, and I directly forward it to K8S.
2. Agent account: I deploy an agent on K8S, and agent uses an administrator account like cluster-admin. When a user requests me, I control the permissions in my management system and use this administrator account for all operations, bypassing k8S authentication and authentication.

The first scheme is obviously not feasible, in case I bottom K8S reinstalled, that two eyes a black, all users can not pass the authentication.

The disadvantage of the second scheme is that I lost all the user information on the K8S side at this time, and could not audit, log and track it at all.

Impersonation can help us mitigate the shortcomings mentioned above. The escrow account can declare its identity as a normal user. In this case, apiserver still uses the escrow account’s credentials for authentication, but the authentication part (permission control) is based on the user’s identity.

We can use kubectl –as XXX to perform identity disguise once, and these usage instructions are not expanded.

1.2.3? K8s doesn’t have a user account?

K8s does not save user Accounts, which has the advantage of being extensible… I can’t make anything else up, so I’ll start making fun of flaws.

1. Platforms built on top of K8S need to build their own account systems. K8s is a feature of platform for platform
2. Obstructive Service Account: Take Rancher for example. Rancher manages its own account, but there is also a Service Account on K8S that is separate from the upper-layer application. Its authority control is out of Rancher’s control. This makes operations people have to be careful with services that need to access Apiserver from within the container, because their behavior never crosses Rancher’s control plane.

This is a bit of a joke, but we’ll talk about it when we introduce Rancher’s authentication and authentication.

1. Authz: RBAC

Before introducing authentication, the reader needs to repeat a sentence: authentication is account oriented, authentication is identity oriented. This point is well demonstrated in the K8S.

K8s uses Role Based Access Control (RBAC) for permission Control by default. In the implementation of K8S, it is implemented through Role and RoleBinding. Of course, there are clusterRoles and ClusterRoleBinding, but the scope is different (whether it is limited to a namespace). The core idea is to grant an identity a set of roles, and each role defines a set of permissions.

Recall that K8S does not manage user accounts. When issuing an account, we can specify -subj “/CN=jbeda/O=app1/O=app2”, see X509 client certificate.

Here we specify the user name and user group for this account. After k8S authentication, the account will be processed as username: jbeda; Groups: [app1, app2] and treats it as an identity. For example, look at a role Binding field:

To authorize an identity:

subjects:
- kind: User
  name: jane
  apiGroup: rbac.authorization.k8s.io
Copy the code

Or to authorize a group of users (a group of identities) :

subjects:
- kind: Group
  name: manager
  apiGroup: rbac.authorization.k8s.io
Copy the code

The kind: User that the reader sees here may raise a lot of questions about this article. In fact, there are only some conceptual differences in the definition of words.

In the context of this article, users refer to end users, and accounts are divided into user accounts and service accounts. Therefore, the concept of identity is used here to encapsulate user name + User group, which is more conducive to readers’ understanding of authentication. Here’s why:

1. According to K8S, RBAC authorizes users, but K8S does not manage users, so where do users come from? This, on the contrary, is the most contradictory point.
2. User can also be specifiedsystem:serviceaccount:xxx:xxxIf a service account is also considered a user, what is a real end user?
3. As mentioned earlier, one account corresponds to one identity, and the “user” is authenticated to prove his or her identity. In authentication, you don’t really need to care about the concept of the user, as long as you care about the identity. If end user A exec uses A service account token to access apiserver, can you say that the authentication is for user A? The apiserver sees a service account, not the end user.

For the above reasons, I still want to use the word identity to refer to the description of k8S User in the authentication context.

1.2.5 Weakness of RBAC: slightly rigid rules

The advantage of RBAC is that it is simple and direct. Once roles and binding are defined, the most basic permission control can be carried out.

Unfortunately, in many real life scenarios, RBAC alone is not enough. Suppose the school introduced a access management system with a rule that students were not allowed to leave school after 10 p.m. every night. Obviously, simple RBAC cannot handle such a scenario.

The solution is context-aware authorization, such as ABAC. Each authentication can carry a context that defines additional information, such as time, place, and so on. In the definition of ABAC, the attribute itself can carry additional conditional information.

Unfortunately, K8S does not support ABAC enough. When using ABAC authentication, the definition of its policy can be seamlessly converted with RBAC, and the advantages of ABAC cannot be really played.

1.2.6 Source of extensibility: Authn/Authz/Admission Webhook

K8s supports custom authentication and authentication policies, and modularizes them well:

• Authentication: Webhook token authentication can be used to achieve customized authentication logic
• Authentication: The Webhook mode can also be used
• Dynamic Admission Strategy: You can use Dynamic Admission Control, such as Admission Webhook, to implement a fully customized Admission strategy

Basically k8S uses webhook form to do these things, define the interface, everyone to do the implementation. If you want to enable Webhook, there are two things you should pay attention to:

1. If webhook exists, k8S will concurrently access Webhook regardless of authentication or authentication. As long as either of the built-in and Webhook parties pass, the request will pass
2. Pay attention to traffic control, after all, every request must go through webhook

1.2.7k8s Authn & AuthZ summary

Starting from the definitions of the various basic nouns, it is a tedious task to sort out the nuances of the many little dots that are involved in this small essay.

After sorting out how authentication and authentication are done in K8S, sorting out their modes and characteristics, including it does not manage user accounts, but manages service accounts, supports user disguise, uses RBAC for authentication, can expand strong…… Through some interpretation of these patterns, we can actually get a rough idea of the advantages and disadvantages of K8S in authentication and authentication.

Of course, there are a lot of points that are half-baked by not talking directly about Rancher. Therefore, the next chapter will start from Rancher. From these advantages and disadvantages, we can feel what capabilities Rancher’s design complements, and why it is designed in this way, so as to have a deeper understanding of Rancher.