在kubernetes 集群内访问k8s API服务

全部的 kubernetes 集群中帐户分为两类，Kubernetes 管理的 serviceaccount(服务帐户) 和 useraccount（用户帐户）。基于角色的访问控制（“RBAC”）使用“rbac.authorization.k8s.io”API 组来实现受权控制，容许管理员经过Kubernetes API动态配置策略。

API Server 内部经过用户认证后，而后进入受权流程。对合法用户进行受权而且随后在用户访问时进行鉴权，是权限管理的重要环节。
在 kubernetes 集群中，各类操做权限是赋予角色(Role 或者 ClusterRole）的。经过建立 RoleBinding 或者 ClusterBinding 把 用户(User),用户组（Group）或服务帐号（Service Account）绑定在 Role 或 ClusterRole 上。这样用户，用户组或者服务帐号就有了相对应的操做权限。
这里有个须要注意的地方
ClusterRoleBinding 只能绑定 ClusterRole,而 RoleBinding 能够绑定 Role 或者 ClusterRole。
根据上图：
1.User1 经过 RoleBinding 把 Role 绑定，能够在 Namespace A 得到 Role 中的权限；
2.User2 和 User3 经过 RoleBinding 把 ClusterRole 绑定，这两个用户便可以在 Namespace B 空间中得到 ClusterRole 权限；
3.若是 User1 经过 ClusterRoleBinding 把 ClusterRole 绑定，这个用户便可在全部的 Namespace 空间中得到 ClusterRole 权限；

Service account是为了方便Pod里面的进程调用Kubernetes API或其余外部服务而设计的。它与User account不一样，具体参看 https://www.kubernetes.org.cn/service-account 。

须要访问 apiserver 须要通过 认证，受权，准入控制 三关。首先须要进行认证，认证经过后再进行受权检查，因有些增删等某些操做须要级联到其余资源或者环境，这时候就须要准入控制来检查级联环境是否有受权权限了。默认状况下，RBAC策略授予控制板组件、Node和控制器做用域的权限，可是未授予“kube-system”命名空间外服务账户的访问权限。这就容许管理员按照须要将特定角色授予服务账户。具体受权能够参看 Kubernetes-基于RBAC的受权： https://www.kubernetes.org.cn/4062.html 。

在k8s集群的Pod 访问API Server，就是须要使用Servive account 的RBAC的受权。下面的代码就是Kubernetes 客户端KubeClient 的实现

从k8s 带给pod的环境变量、token以及证书去访问k8s API Server。

因此这里就是要给Service Account 受权，受权能够参考Kubernetes-基于RBAC的受权： https://www.kubernetes.org.cn/4062.html