kuberneters RBAC角色授权

授权插件： Node  RBAC ABAC Webhook

　　RBAC:  Role-based AC  基于角色环境控制，受限于Namespace

　　角色： {Role}

　　授权： {permissions} 

　　subject：user/group/serviceaccount

　　object：resource group/resource/non-resource url

　　action：list/get/wathc/patch/delete......

♦  Obuject_Url:

    /apis/<GROUP>/<VERSION>/namespaces/<NAMESPACE_NAME>/<KIND>[/OBJECT_ID]/

Role：只对当前namespace生效

• Operations
• Objects

RoleBinding：

• user account OR service account
• role

 ♦  ClusterRole/ClusterRoleBinding     会获得集群级别的资源

RoleBinding 绑定user，只能获取用户所在名称空间的资源

k8s资源分属两种级别：

• 集群  ClusterRole/ClusterRoleBinding
• 名称空间   Role/RoleBing

创建Role： kubectl create role --help
# kubectl create role pod-reader --verb=get,list,watch --resource=pods -n develop         #  --dry-run 参数可以指定试用，并不会真正创建; 也可以通过这个导出模板文件

创建RoleBinding: kubectl create rolebinding --help
# kubectl create rolebinding zear-read-pods --role=pod-reader --user=zear -n develop      # --user user不存在也可以被创建 

切换用户上下文到zear
# kubectl config use-context zear@kubernetes　　#如果要测试需要保证zear上下文已经被创建
由于我们创建的rolebinding是在develop的namespace下，所以无法获取到default下的pods信息，但是可以真长获取develop下的pods

创建ClusterRole： kubectl create clusterrole --help
# kubectl create clusterrole  cluster-pod-user --verb=get,list,watch --resource=pod -n develop 

创建ClusterRoleBinding:  kubectl create clusterrole --help
# kubectl create clusterrolebinding zear-cluster-read-pods --clusterrole=cluster-pod-user --user=zear -n develop  # --user 也可以使用--group --serviceaccount

切换上下文之后获取系统资源，由于我们只给了pod的权限，所以无法获取namespace信息，但是可以拿到system的pods信息


使用Rolebinding 绑定 clusterrole，则只能获取rolebinding所在namespace的资源
# kubectl create rolebinding zear-read-pod --clusterrole=cluster-pod-user --user=zear -n develop

切换上下文之后，只能develop namespace下面的pod资源，无法获取system资源

  ♦ 另外我们在创建pod的时候可以指定serviceAccountName（kubectl explain pod.spec.serviceAccountName），然后通过rolebinding绑定指定的serviceaccount Role，这样这个pod就拥有了这个serviceaccount用户的权限。

转载于:https://www.cnblogs.com/alamisu/p/11250684.html