Fork me on GitHub

在kubernetes 集群内访问k8s API服务

所有的 kubernetes 集群中账户分为两类,Kubernetes 管理的 serviceaccount(服务账户) 和 useraccount(用户账户)。基于角色的访问控制(“RBAC”)使用“rbac.authorization.k8s.io”API 组来实现授权控制,允许管理员通过Kubernetes API动态配置策略。

image

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 的实现

image

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

image

所以这里就是要给Service Account 授权,授权可以参考Kubernetes-基于RBAC的授权: https://www.kubernetes.org.cn/4062.html 



posted @ 2019-05-13 15:31  张善友  阅读(...)  评论(... 编辑 收藏