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

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

命令执行后会在所在目录生成三个文件

result

利用文件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的配置文件, 并执行

cluster-role-binding.yaml

用户和ClusterRole绑定后，我们就可以使用这个用户去访问API server来操作集群了。

切换到sunfuqi-contxt这个上下文环境, 对集群做操作

result

可以看到通过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

SA

创建好后，我们查看一下他的信息

detail

可以看到有个Mountable secrets和Tokens的key，后面是引用的secret名字， 这个secret是生成service account的时候自动生成的， 当一个create一个pod时指定resource-operator这个service account， k8s就会把这个secret mount到pod上的文件系统，pod里面的程序可以通过这个secret作为token访问API server。 具体查看一下这个secret内容

secret

创建新的ClusterRole和ClusterRoleBinding

ClustorRole

目前为止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

去pod上查看一下指定目录，发现里面有3个文件和上面secret的内容一样，pod里面的程序可以通过这个token去访问API server。继续查看pod的环境变量， 可以看到一些集群的信息以变量的形式提供给pod使用。

pod env

删除一个service来验证service account能够准确操作集群。

ingress

删除service httpd-svc前， 有两条paths在rule里面， 删除httpd-svc 相应的path也被删掉。至此以后不能通过/httpd-svc访问服务。这里也验证了service account可以通过pod准确操作集群。