2.3.2 认证
1. 认证中使用的用户
Kubernetes集群中有两种用户：一种是由 Kubernetes管理的 ServiceAccount；另一种是普通用户。普通用户是由集群之外的服务管理的，比如存储在Keystone中的用户、存储在文件中的用户和存储在 ldap中的用户等。 所有的 API请求中都绑定了一个ServiceAccount或普通用户，如果都未绑定，就是一个使用匿名用户的请求。
ServiceAccount与它关联的请求中的用户是什么样的呢？ServiceAccoount在Kuberentes中关联着一个 Secret，这个 Secret中包括一个 JWT格式的 Token，它会使用 Token中的 Payload中的 Sub 字段作为请求用户的名称。下面是对 Secret中的 Token解析的一个示例，请求所使用的用户名是 system:serviceaccount:default:default，见代码清单 2-60。
{
"iss":"kubernetes/serviceaccount","kubernetes.io/serviceaccount/namespace":"default","kubernetes.io/serviceaccount/secret.name":"default-token-bxzg6","kubernetes.io/serviceaccount/service-account.name":"default","kubernetes.io/serviceaccount/service-account.uid":"a96a30e3-3ee0-44cf-
99b2-1ad4bdbc7632",
"sub":"system:serviceaccount:default:default"
}
普通用户有多种方式携带认证信息去访问 APIServer。以客户端证书的方式为例，请求中如果携带了客户端证书，并且证书是由集群的 CA证书（Certification Authority）签发的，那么这个请求的认证会通过，它会使用证书中的 Subject字段作为用户的名称。代码清单 2-61是一个证书的示例，示例中携带的用户名是kcp（Subject:O=system:kcp，CN=kcp）。
Certificate:
Data:
Version:3(0x2)SerialNumber:
08:e2:5b:3a:2c:8c:6c:06:80:f8:aa:1b:81:76:93:4f
SignatureAlgorithm:sha256WithRSAEncryptionIssuer:CN=kubernetes
Validity
NotBefore:Mar305:59:422021GMT
NotAfter:Jul1109:37:382030GMT
Subject:O=system:kcp,CN=kcp
......
2. 认证策略
（1） X509 客户端证书认证
客户端证书认证是双向认证，服务器端需要验证客户端证书的正确性，客户端需要验证服务器端证书的正确性。客户端证书认证方式可以通过Kube-Apiserver的--client- ca-file参数启用，它指向的文件用来验证提供给API服务器的客户端证书。当请求中携带的客户端证书通过了认证时，请求关联的用户名就是证书中的Subject字段的内容。我们可以使用代码清单 2-62查看证书内容
opensslx509-in< 证书> -text-noout
（2） 静态 Token文件
静态 Token文件认证方式可以通过 --token-auth-file 参数启用，在这个文件中存放着没有时间限制的 BearerToken，如果想变更 Token，则必须要重启 APIServer。代码清单 2-63是一个 Token文件的示例，每一行包括 Token、用户名和用户ID。JGaOWpJuyBL8NXmeA9V341JOCkHJbOTf,system:kubectl-kcpm1,system:kubectl-kcpm1
访问 APIServer时在HTTP请求头上加入 Authorization的请求头， 值的格式是Bearer<Token>，上面的Token见代码清单 2-64。
curl-H"Authorization:BearerJGaOWpJuyBL8NXmeA9V341JOCkHJbOTf"-khttps://127.0.0.1:6443/
（3） 引导 Token
我们在创建集群或是将新节点加入集群时，新节点上的组件要与APIServer进行通信（如Kubelet），但通信需要证书，手动签发证书比较麻烦。为了简化这个过程，Kubernetes1.4之后的版本会通过新节点发送请求的方式为新节点签发证书。而发送请求获取证书的请求时使用的BearerToken叫作BootstrapToken，这种Token在Kube-SystemNamespace下有一个对应的Secret。Controller-Manager中有一个TokenCleaner的Controller，它会将那些已经过期的 BootstrapToken掉。
Token的格式是 [a-z0-9]{6}.[a-z0-9]{16}，Token的前半部分是 TokenID，通过前半部分能找到 UI应的 Secret；第二部分是 TokenSecret，保存在 Secret中。以Kubeadm创建的 tokencwb0ly.cqdj5l0k2qa19evv为例，在 Kube-System的 Namespace下会有一个名字为 bootstrap-token-cwb0ly的 Secret，内容见代码清单2-65。
apiVersion:v1data:
auth-extra-groups:system:bootstrappers:kubeadm:default-node-tokenexpiration:2021-03-13T13:44:23+08:00
token-id:cwb0ly
token-secret:cqdj5l0k2qa19evvusage-bootstrap-authentication:trueusage-bootstrap-signing:true
kind:Secretmetadata:
manager:kubeadm
operation:Update
name:bootstrap-token-cwb0lynamespace:kube-system
使用该 Token作为 Authorization请求头访问 APIServer，请求认证通过后关联到的用户名的格式是 bootstrap-token-<token-id>，即 system:bootstrap:cwb0ly，请求示例见代码清单 2-66。
curl-H"Authorization:Bearercwb0ly.cqdj5l0k2qa19evv"-khttps://127.0.0.1:6443/
要想使用引导 Token 认证，需要在 APIServer 启动的时候添加 --enable-bootstrap-token-auth启动参数，如果想使用 TokenClearController，需要在 Controller-Manager的启动参数中添加 --controllers=*，tokencleaner。
