Kubernetes中的RBAC

Kubernetes中，受权有ABAC（基于属性的访问控制）、RBAC（基于角色的访问控制）、Webhook、Node、AlwaysDeny（一直拒绝）和AlwaysAllow（一直容许）这6种模式。须要在kube-apiserver设置–authorization-mode=RBAC参数，启用RABC模式，下面的操做版本为v1.10.1；
　　当应用没有指定serviceAccountName，它将使用default服务账户。

　　在RABC API中，经过以下的步骤进行受权：
　　1）定义角色：定义角色时会指定此角色对于资源的访问控制的规则；
　　2）定义主体：用户、组和服务账户
　　3）绑定角色：将主体与角色进行绑定，对主体进行访问受权。

　　　　　　　　　　　　　　　　　　　　RBAC API中的对象关系图

　　Kubernetes中角色包含表明权限集合的规则，权限只有被授予，没有被拒绝的设置。
　　在Kubernetes中有两类角色：普通角色和集群角色。
能够经过Role定义在一个命名空间中的角色，或是使用ClusterRole定义集群范围的角色。

普通角色只能被授予访问单一命令空间中的资源。
集群角色(ClusterRole)可以被授予资源权限有：集群范围资源（Node、NameSpace）、非资源端点（/healthz）、集群全部命名空间资源（跨名称空间）；

角色绑定和集群角色绑定
　　角色绑定用于将角色与一个主体进行绑定，从而实现将对主体受权的目的，主体分为用户、组和服务账户。
角色绑定分为：普通角色绑定和集群角色绑定

角色绑定中不一样主体定义有：
名称为 demo 用户：

subjects:
 - kind:User
   name:"demo"
   apiGroup:rbac.authorization.k8s.io

名称为 demo 组：

subjects:
 - kind:Group
   name:"demo-group"
   apiGroup:rbac.authorization.k8s.io

kube-system命名空间中，名称为default的服务账户

subjects:
 - kind:ServiceAccount
   name:default
   namespace:kube-system

so命名空间中，全部的服务账户：

subjects:
 - kind:Group
   name:system:serviceaccounts:so
   apiGroup:rbac.authorization.k8s.io

全部的服务账户：

subjects:
 - kind:Group
   name:system:serviceaccounts
   apiGroup:rbac.authorization.k8s.io

全部用户:

subjects:
 - kind:Group
   name:system:authenticated    #受权用户
   apiGroup:rbac.authorization.k8s.io
 - kind:Group
   name:system:unauthenticated  #未受权用户
   apiGroup:rbac.authorization.k8s.io

授予cluster-admin集群角色给admin用户：

kubectl create clusterrolebinding admin-cluster-admin-binding --clusterrole=cluster-admin --user=admin

授予cluster-admin集群角色给so名称空间中的app服务账户：

kubectl create clusterrolebinding app-admin-binding --clusterrole=cluster-admin --serviceaccount=so:app

　　RBAC实例demo下面建立solinx-service-account.yml文件包含如下内容：

# 服务帐号
 apiVersion: v1
 kind: ServiceAccount   
 metadata:
   name: solinx
 # 角色
 ---
 kind: Role
 apiVersion: rbac.authorization.k8s.io/v1beta1
 metadata:
   name: solinx
 rules:                #规则
 - apiGroups: [""]       # 全部核心api
   resources: ["pods"]   # 资源
   verbs: ["create","delete","get","list","patch","update","watch"]  #操做
 - apiGroups: [""]
   resources: ["namespaces"]
   verbs: ["create","delete","get","list","patch","update","watch"]
 # 角色绑定
 ---
 apiVersion: rbac.authorization.k8s.io/v1beta1
 kind: RoleBinding
 metadata:
   name: solinx
 roleRef:     # 上面定义的角色
   apiGroup: rbac.authorization.k8s.io
   kind: Role
   name: solinx
 subjects:   # 上面定义的服务帐户
 - kind: ServiceAccount
   name: solinx
   namespace: default

　　上面定义了一个服务帐户solinx、普通角色solinx，并将该服务帐户与角色进行绑定，该角色定义了对了pod的增删查改等操做，因此该服务帐户也具有了该权限；
　　这里使用solinx服务帐户对资源进行操做：

kubectl get po --as system:serviceaccount:default:solinx

因为只授予了pod的操做权限，当访问service资源时被拒绝：

kubectl get svc --as system:serviceaccount:default:solinx

 Error from server (Forbidden): services is forbidden: User "system:serviceaccount:default:solinx" cannot list services in the namespace "default"

该角色为普通角色Role，当访问集群资源NameSpace时一样被拒绝：

kubectl get ns --as system:serviceaccount:default:solinx

 Error from server (Forbidden): namespaces is forbidden: User "system:serviceaccount:default:solinx" cannot list namespaces at the cluster scope

　　此时把角色改成集群角色：ClusterRole，并从新绑定服务帐户：

　　此时该服务帐户已经具有集群角色权限，访问集群资源：NameSpace

kubectl get ns --as system:serviceaccount:default:solinx

参考资料：
https://kubernetes.io/docs/reference/access-authn-authz/rbac/

文章首发地址：Solinx
http://www.solinx.co/archives/1233