k8s基于RBAC的权限控制，赋予pod访问k8s API的权限

部署在k8s集群中的应用，有些需要拥有访问k8s API服务器的权限，比如说获取当前命名空间下的pod，svc等资源。k8s通过RBAC规则来赋予用户、pod、组相应的权限。其中pod使用一种称为service accounts的机制，下面我们来实践如何为pod中的应用添加权限。

首先需要在命名空间中创建serviceaccount资
yaml详细内容如下：

接着创建role（角色），role中包含角色所具有的功能，yaml内容如下：

yaml中定义了角色有获取default命名空间中pods的权限。
然后定义rolebinding（角色绑定），将角色绑定到上面创建的serviceaccount，

yaml文件内容如下：

创建一个pod进行测试，yaml文件如下

文件中serviceaccountname的值为上述绑定了角色的serviceaccount。

serviceaccount关联了一个configmap，绑定到pod之后，configmap被挂载到pod中，/var/run/secrets/kubernetes.io/serviceaccount/目录下包含三个文件，分别是

pod可以通过使用ca.crt和token来访问API服务器。
进入容器中，使用curl命令来获取default命名空间下pod，在get请求中带上ca.crt和token，如下

返回结果的部分如下：

API服务器返回了pod的详细信息。
除了pod,svc等属于某个命名空间的资源外，还可以获取非命名空间级别的k8s集群，包括pv等，需要使用到clusterrole（集群角色）资源，采用clusterrolebinding（集群角色绑定）将集群角色绑定到serviceaccount上。
serviceaccount，role和rolebinding必须属于某个命名空间下。假如A命名空间下的应用想要访问到B命名空间下的资源，可以将A命名空间下的serviceaccount绑定到B命名空间下的role。也可以将A命名空间下的serviceaccount绑定到clusterrole，让其可以获取所有命名空间下的资源。
clusterrole还可以允许访问非资源型的URL，如下图所示：

为了方便使用，k8s提供了一些clusterrole，部分如下图所示：
用户可以直接使用k8s提供的集群角色，从命名中可以看出，这些集群角色包括pod,pv,pvc,job,namespace等k8s本身提供的资源，可以根据不同的需求选择不同的集群角色，还可以将多个角色绑定到一个serviceaccount上。