为Kubernetes集群添加用户认证

Kubernetes中的用户

K8S中有两种用户(User)——服务账号(ServiceAccount)和普通意义上的用户(User)
ServiceAccount是由K8S管理的，而User通常是在外部管理，K8S不存储用户列表——也就是说，添加/编辑/删除用户都是在外部进行，无需与K8S API交互，虽然K8S并不管理用户，但是在K8S接收API请求时，是可以认知到发出请求的用户的，实际上，所有对K8S的API请求都需要绑定身份信息(User或者ServiceAccount)，这意味着，可以为User配置K8S集群中的请求权限

有什么区别？

最主要的区别上面已经说过了，即ServiceAccount是K8S内部资源，而User是独立于K8S之外的。从它们的本质可以看出：

• User通常是人来使用，而ServiceAccount是某个服务/资源/程序使用的

• User独立在K8S之外，也就是说User是可以作用于全局的，在任何命名空间都可被认知，并且需要在全局唯一
  而ServiceAccount作为K8S内部的某种资源，是存在于某个命名空间之中的，在不同命名空间中的同名ServiceAccount被认为是不同的资源

• K8S不会管理User，所以User的创建/编辑/注销等，需要依赖外部的管理机制，K8S所能认知的只有一个用户名
  ServiceAccount是由K8S管理的，创建等操作，都通过K8S完成

这里说的添加用户指的是普通意义上的用户，即存在于集群外的用户，为k8s的使用者。
实际上叫做添加用户也不准确，用户早已存在，这里所做的只是使K8S能够试别此用户，并且控制此用户在集群内的权限

用户验证

尽管K8S认知用户靠的只是用户的名字，但是只需要一个名字就能请求K8S的API显然是不合理的，所以依然需要验证此用户的身份
在K8S中，主要有以下几种验证方式：

• X509客户端证书
  客户端证书验证通过为API Server指定--client-ca-file=xxx选项启用，API Server通过此ca文件来验证API请求携带的客户端证书的有效性，一旦验证成功，API Server就会将客户端证书Subject里的CN属性作为此次请求的用户名

• 静态token文件
  通过指定--token-auth-file=SOMEFILE 选项来启用bearer token验证方式，引用的文件是一个包含了 token,用户名,用户ID 的csv文件
  请求时，带