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
RoleBinding | ClusterRoleBinding | |
Role | Namespace | Cluster |
ClusterRole | 无法绑定 | Cluster |
创建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用户的权限。