首先从宏观的角度看下Kubernetes的请求链路是如何进行的。
可以大概了解到一个请求的链路是依次通过Authentication（认证，简称Authn）、Authorization（授权，简称Authz）、AdmissionControl（准入控制），从而获取到后端持久化的数据。
从图中可以看到Authn、Authz、AdmissionControl是由多个模块组成的，每个步骤都有多种方式构成的。
在进入认证模块之前会将HTTP的Request进行构建context，而context中就包含了用户的RequestInfo，userInfo、Verb、APIGroup、Version、Namespace、Resource、Path等。
带着这些信息，下面我们来一次看下准入过程中的每个步骤吧。
Kubernetes认证认证的过程的证明user身份的过程。
Kubernetes中有两类用户，一类是ServiceAccount，一类是集群真实的用户。
ServiceAccount账户是由Kubernetes提供API（资源）进行创建和管理的，ServiceAccount可以认为是特殊的Secret资源，可用户集群内资源访问APIServer的认证所用。通过可以通过mount的方式挂载到Pod内进行使用。
真实的用户通常是从外部发起请求访问APIServer，由管理员进行管理认证凭证，而Kubernetes本身不管理任何的用户和凭证信息的，即所有的用户都是逻辑上的用户，无法通过API调用Kubernetes API进行创建真实用户。
Kubernetes认证的方式众多，常见的有TLS客户端证书双向认证、BearerToken认证、BasicAuthorization或认证代理（WebHook）
所有的认证方式都是以插件的形式串联在认证链路中，只要有一种认证方式通过，即可通过认证模块，且后续的认证方式不会被执行。
在此处参考一点点Kubernetes APIServer Authentication模块的代码，可以发现，任何的认证方式都是一下Interface的实现方式都是接收http Request请求，然后会返回一个user.Info的结构体，一个bool，以及一个error
// Request attempts to extract authentication information from a request and returns // information about the current user and true if successful, false if not successful, // or an error if the request could not be checked. type Request interface { AuthenticateRequest(req *http.Request) (user.Info, bool, error) }user.Info中包含了用户的信息，包括UserName、UUID、Group、Extra。
bool返回了用户是否通过认证，false的话即返回无法通过认证，即返回401错误。
error则返回了当Request无法被检查的错误，如果遇到错误则会继续进行下一种注册的方式进行认证。
如果认证通过，则会把user.Info写入到到请求的context中，后续请求过程可以随时获取用户信息，比如授权时进行鉴权。
下面我会以Kubernetes代码中的认证方式顺序，挑选几项认证方式，并结合TKE开启的认证方式来向你介绍TKE创建的Kubernetes集群默认的认证策略。
Basic AuthenticationAPIServer启动参数--basic-auth-file=SOMEFILE指定basic认证的csv文件，在APIServer启动之后修改此文件都不会生效，需要重启APIServer来更新basic authentication的token。csv文件格式为：token,user,uid,"group1,group2,group3"。
请求时，需要指定HTTP Header中Authentication为Basic，并跟上Base64Encode(user:passward)值。
x509客户端证书APIServer启动参数--client-ca-file=SOMEFILE指定CA证书，而在TKE的K8s集群创建过程中，会对集群进行自签名CA密钥和证书用于管理，如果用户下发的客户端证书是由此CA证书的密钥签发的，那么就可以通过客户端证书认证，并使用客户端证书中的CommonName、Group字段分别作为Kubernetes的UserInfo中Username和Group信息。
目前TKE对接子账户都是通过自签名的CA凭证进行签发子账户Uin对应CN的客户端证书。
Bearer TokenBearer Token的认证方式包含很多，比如启动参数指定的、ServiceAccount（也是一种特殊的BeaerToken）、BootstrapToken、OIDCIssure、WebhookToken
1. 默认指定Token csv文件APIServer启动参数--token-auth-file=SOMEFILE指定Bearer Token认证的csv文件。和Basic Authentication方式相似，只不过请求APIServer时，指定的HTTP认证方式为Bearer方式。此Bearer后直接跟passward即可。csv文件格式为：password,user,uid,"group1,group2,group3"。
请求时，需要指定HTTP Header中Authentication为Bearer，并跟上Base64Encode(user:passward)值。
2. ServiceAccountServiceAccount也是一种特殊beaer token，ServiceAccount在Kubernetes中是一种资源，创建一个ServiceAccount资源之后默认会创建一个Secret资源，而Secret资源中就包含了一个JWT格式的Token字段，以Bearer Token的方式请求到Kube-APIServer，Kube-APIServer解析token中的部分user信息，以及validate以下ServiceAccount是否存在即可进行认证检查。这种方式即之前提到的“两种用户”中常见的集群内认证方式，ServiceAccount，主要用于集群内资源访问APIServer，但不限于集群内。
3. BootstrapToken此项开关在Kubernetes v1.18版本中才为stable版本，此类Token是专门用来引导集群安装使用的，需要配合controller-manager的TokenCleaner。
目前TKE默认开启此配置。
4. OpenID Connect TokensOIDCToken的认证方式是结合OAuth2向身份提供方获取ID Token来访问APIServer。