在kubernetes 集群内接见k8s API效劳

2019年7月2日11:01:47在kubernetes 集群内接见k8s API效劳已关闭评论 223

一切的 kubernetes 集群中账户分为两类,Kubernetes 治理的 serviceaccount(效劳账户) 和 useraccount(用户账户)。基于脚色的接见掌握(“RBAC”)运用“rbac.authorization.k8s.io”API 组来完成受权掌握,许可治理员经由过程Kubernetes API动态设置装备摆设战略。

在kubernetes 集群内接见k8s 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 的完成

在kubernetes 集群内接见k8s API效劳

从k8s 带给pod的情况变量、token以及证书去接见k8s API Server。

在kubernetes 集群内接见k8s API效劳

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



avatar