API Server作为Kubernetes网关，是用户访问和管理资源对象的入口。每一次的访问请求都需要对访问者进行合法性的检验，包括身份验证、资源操作权限验证验证等，通过一系列验证通过之后才能返回访问结果。
用户可以通过kubectl命令, SDK，或者发送REST请求来访问API 。User和Service Account是两种不同用于访问API的方式。
User：
1，Kubernetes不直接管理用户信息
2，有外部独立服务（LDAP，AD）进行管理的用户，用户不能通过集群内部的 API 来进行管理
3， 用户访问API通过证书的方式进行认证
4， k8s管理员和运维人员通过用户的形式access kebernetes
ServiceAccount
1，服务账号是通过Kubernetes API 来管理
2，服务账号适用于集群内部运行的应用程序（pod），需要通过 API 来完成的操作
3，服务账户通过bearer token认证方式访问API
RBAC授权
RBAC可以对user，group和serviceaccount进行API访问权限控制。Role和ClusterRole定义了权限集合，RoleBinding和ClusterRoleBinding用于将Role和ClusterRole上的许可权限绑定到一个，一组用户或者一个服务账号上。
Role- 只能用于授予对某一单一命名空间中资源的访问权限（rule是通过设定不同API group里的资源读，写，订阅的权限）
ClusterRole- 可以授予与Role对象相同的权限，但由于它们属于集群范围对象， 也可以使用它们授予对以下几种资源的访问权限：
集群范围资源（例如节点，即node）
非资源类型endpoint（例如”/healthz”）
跨所有命名空间的命名空间范围资源（例如pod，需要运行命令kubectl get pods --all-namespaces来查询集群中所有的pod）
RoleBinding- 可以引用在同一命名空间内定义的Role对象，在RoleBinding所在的命名空间内授予用户，组，服务账户对所引用的Role中 定义的命名空间资源的访问权限
ClusterRoleBinding- 在集群级别和所有命名空间中授予用户，组，服务账户所绑定的ClusterRole资源权限。
实例1：添加一个新用户并授予只读权限
添加一个含有只读权限的用户通过kubectl访问API server，首先需要创建一个X509的证书作为访问API server的认证凭证，设置这个用户的credentials和context，绑定此用户到只读权限的ClusterRole。利用这个用户的context调用kubectl去操作k8s集群。
1，利用cfssl这个工具生成证书，具体详情搜索相关tool适用方法，这里只列出我个人生成的cert的命令和两个配置文件sunfuqi.json，ca-config.json
执行命令，这里用到了kubernetes集群的CA证书来生成新用户sunfuqi的客户端证书。
/usr/local/bin/cfssl gencert --ca /etc/kubernetes/pki/ca.crt --ca-key /etc/kubernetes/pki/ca.key --config ca-config.json --profile=kubernetes sunfuqi.json | /usr/local/bin/cfssljson --bare readonly
命令执行后会在所在目录生成三个文件
利用文件2,3为kubectl添加crendential
kubectl config set-credentials sunfuqi --certificate-authority=/etc/kubernetes/pki/ca.crt --embed-certs=true --client-key=/root/users/sunfuqi/sunfuqi-key.pem --client-certificate=/root/users/sunfuqi/sunfuqi.pem
这条命令会在kubectl的配置文件里面添加一个sunfuqi的用户，并写入证书的内容
为这个用户sunfuqi创建context，名字叫sunfuqi-context
kubectl config set-context sunfuqi-context --user=sunfuqi --cluster=kubernetes
创建好后，通过kubectl命令查看，新用户的context，你也可以通过查看文件的形式去检查配置文件($HOME/.kube/config)
kubectl config view
cat /root/.kube/config
kubernetes系统自带一个readonly的cluster role名字叫做view，这里我就不再创建新的role，直接引用View ClusterRole和user sunfuqi绑定起来， 创建一个ClusterRoleBinding的配置文件, 并执行
用户和ClusterRole绑定后，我们就可以使用这个用户去访问API server来操作集群了。
切换到sunfuqi-contxt这个上下文环境, 对集群做操作
可以看到通过sunfuqi这个用户是可以list说有pod的，但是不能删除，正好符合我们的预期。创建一个新用户并赋予只读权限的例子就完成了。
实例2：创建一个service account实例
添加一个service account的用户，并授权这个用户对services，pod，PV， ingress等resource有增删改查的权限， 创建一个deployment，pod利用这个service account去监控service，如果有有新的service生成，把这个service加入到ingress的rules里面去，客户可以通过ingress controller + 服务名 访问服务。
创建一个Service Account，取名resource-operator
创建好后，我们查看一下他的信息
可以看到有个Mountable secrets和Tokens的key，后面是引用的secret名字， 这个secret是生成service account的时候自动生成的， 当一个create一个pod时指定resource-operator这个service account， k8s就会把这个secret mount到pod上的文件系统，pod里面的程序可以通过这个secret作为token访问API server。 具体查看一下这个secret内容
创建新的ClusterRole和ClusterRoleBinding
目前为止Service Account创建成功并和相应的Role绑定起来了。下面就是自己写个程序放到容器里去验证这个service account是否能正常访问API server去操作集群。
我这个例子是用python写的，安装了kubernetes的python 包，用来监控集群的服务， 如果有新增的服务就会修改ingress配置， 为这个service配置一个rules。要实现这个目的， 我的集群上装了一个ingress-controller（基于nginx），并配置了相应的ingress。
程序写好打成docker image， 具体程序内容和打包过程，不再这里讲述。
编写deployment文件，并部署
这里设置了容器的serviceAccount 指向上面创建的服务账户，pod部署在指定的node上。
部署完成后查单pod的内容，正如前面所说这里我们可以看到service account的token被mount到pod指定目录
去pod上查看一下指定目录，发现里面有3个文件和上面secret的内容一样，pod里面的程序可以通过这个token去访问API server。继续查看pod的环境变量， 可以看到一些集群的信息以变量的形式提供给pod使用。
删除一个service来验证service account能够准确操作集群。
删除service httpd-svc前， 有两条paths在rule里面， 删除httpd-svc 相应的path也被删掉。至此以后不能通过/httpd-svc访问服务。这里也验证了service account可以通过pod准确操作集群。