认证
开启 TLS时，所有的请求都需要首先认证。Kubernetes支持多种认证机制，并支持同时开启多个认证插件（只要有一个认证通过即可）。如果认证成功，则用户的 username 会传入授权模块做进一步授权验证;而对于认证失败的请求则返回 HTTP 401。
当apiserver启动的时候，其实有两个和安全相关的配置，一个叫insecure-port，一个叫secure-port，早期大家很习惯的将insecure-port打开，经过insecure-port端口所有的请求其实是没有做任何的安全校验的，也就是认证，鉴权这些逻辑是不走的，这样就面临着一个危险，所有的request是没有认证的，不管是谁发的，它有没有权限，它都会被接受，这很可能就会有一些恶意的请求。
所以现在在非生产环境也会将insecure端口关掉。
另外一个是secure port，secure-port设置之后所有的认证，鉴权这些逻辑都要走。
认证插件
针对开放式的框架，它一定会支持很多很多的认证方式。
X509 证书
- 使用X509客户端证书只需要 API Server启动时配置--client-ca-file=SOMEFILE。在证书认证时，其CN 域用作用户名，而组织机构域则用作 group 名。
证书一般会有key和cert，cert在签发的时候是发给什么机构，哪个人的。这样你带着一个证书来访问apiserver的时候，它有签发你证书的ca文件，它就能够解析出来你的certificates，它就能够知道你是谁。
静态Token 文件
- 使用静态 Token 文件认证只需要 API Server启动时配置--token-auth-file=SOMEFILE。
- 该文件为 csv格式，每行至少包括三列 token，username，user id，token,user,uid,"group1,group2,group3"
apiserver启动的时候要配置一个token-auth-file，在这个csv文件里面配置用户名，用户id，以及对应的token，和用户属于哪些组配置在这个scv文件里面，它有点像简化的数据库，其实也即是将用户名和对应的token发到这里面，然后在apiserver启动的时候加载这个文件，那apiserver就知道我这个集群可以接受哪些用户请求，你带着用户token过来，它就能够判断这个token是不是合法的，如果合法就知道对应的user是谁，它就可以将这个请求接受掉了。
引导 Token
- 为了支持平滑地启动引导新的集群，Kubernetes 包含了一种动态管理的持有者令牌类型，称作启动引导令牌（Bootstrap Token）。
- 这些令牌以 Secret 的形式保存在kube-system名字空间中，可以被动态管理和创建。
- 控制器管理器包含的 TokenCleaner控制器能够在启动引导令牌过期时将其删除。
- 在使用kubeadm 部署Kubernetes 时，可通过 kubeadm token list 命令查询。
在k8s启动的时候有bootstrap token，它也是可以做认证的。
静态密码文件
- 需要API Server 启动时配置--basic-auth-file=SOMEFILE，文件格式为cSV，每行至少三列 password，user，uid，后面是可选的group名 password，user，uid，"group1，group2，group3"。(和静态token类似，只不过文件里面存放着密码)
OpenID
OAuth 2.0的认证机制
ServiceAccount
ServiceAccount是 Kubernetes 自动生成的，并会自动挂载到容器的/run/secrets/kubernetes.io/serviceaccount 目录中。
当你去建立任何的namespace的时候，k8s就有一个控制器，它看见namespace创建了，它就会去建立sa，它会生成token，这个token签发的内容其实就是代表了这个token签发给哪个namespace的，哪个serviceaccount的，这个token是apiserver签发的，所以你带着token去访问apiserver的时候，它就知道这个token合法还是非法，代表的是哪个namespace，哪个serviceaccount。
静态token 示例
在这个scv文件里面创建了用户，token叫做cncamp-token，这个是用户的token。用户名是cncamp，它的uid是1000，然后它发到3个group里面，这就是简单的token文件。
如果我们要去启用静态的token，那么我要去修改apiserver的配置文件，这个就是告诉apiserver说，这个文件里面的内容我是承认的。也即是将主机的文件mount到apiserver的pod里面。
在这个pod的volumes里面定义了一个hostpath的volume
更新完apiserver的yaml文件会去做个重启，如果get pod成功那么说明api-server重启成功。
这里面加了header，这个header加了token，这个token代表了cncamp这个用户，直接发rest
api调用通过curl命令。
可以看到由于权限的问题，它的code是403是鉴权不过的，其实认证是通过的，因为它知道你的token对应的用户是cncamp。
也就是说带着cncamp的token去访问apiserver，它已经去本地的static token file里面去校验token代表哪个用户了，它查找到了这个用户并且说这个用户没有权限，其实整个的认证就已经过了。
x509证书
kubeadm搭建的集群，本身就使用了x509证书
serviceaccount
当创建任何的serviceaccount的时候，在这个namespace里面，其实k8s会自动的在这个namspace里面创建一个叫default的serviceaccount，所谓的serviceaccount就是系统账号。
每个系统账号会有对应的secret，可以看到有ca文件，还有namespace，这个是base64加密了的，还有一个token，这个其实就是apiserver签发的jwt token，和之前静态token是类似的。
可以看到只要带着这个token去访问apiserver，apiserver就能够认出我是谁，配合权限控制那么就可以根据这个token去访问apiserver里面的任何对象。
如果基于内置的认证方式还不能满足你需求，公司有自己的认证系统，认证方式都在集群之外，那么怎么使得k8s集群和这些认证平台去集成，那么就需要通过webhook，k8s认证也支持webhook。
你可以基于webhook来配置来指向外部的认证服务器，有了这种认证集成的方式之后，那么k8s就可以和任何平台去做集成。
Webhook 令牌身份认证
- --authentication-token-webhook-config-file 指向一个配置文件，其中描述如何访问远程的Webhook服务。
- --authentication-token-webhook-cache-ttl用来设定身份认证决定的缓存时间。默认时长为2分钟。
匿名请求
- 如果使用AlwaysAllow 以外的认证模式，则匿名请求默认开启，但可用--anonymouSs-auth=false禁止匿名请求。