在介绍源码之前还是解释一下这个RBAC吧，RBAC（Role-Based Access Control，基于角色的访问控制），就是用户通过角色与权限进行关联。简单地说，一个用户拥有若干角色，每一个角色拥有若干权限。这样，就构造成“用户-角色-权限”的授权模型。在这种模型中，用户与角色之间，角色与权限之间，一般者是多对多的关系。 在kubernetes1.6以后正式引入RBAC这个东西，其实这个事情要分两个方面看，在增加了安全性的同时降低了易用性，应为在真实的环境中不会直接把kubernetes放到公网环境中，内网环境中的网络也是隔离的，当然你可以可以选择关闭RBAC这个服务。 开启服务，在apiserver启动参数设定
--authorization-mode=RBAC --runtime-config=rbac.authorization.k8s.io/v1beta1RBAC首先看角色定义，Role是命名空间级别的
type Role struct { metav1.TypeMeta `json:",inline"` metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"` Rules []PolicyRule `json:"rules" protobuf:"bytes,2,rep,name=rules"` }集群角色是集群级别的
type ClusterRole struct { metav1.TypeMeta `json:",inline"` metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"` Rules []PolicyRule `json:"rules" protobuf:"bytes,2,rep,name=rules"` }角色里面关联的是Rules规则，一个角色有哪些权限，通过rule去定义，下面是rule的属性，这些主要事控制访问的资源、访问URL限制。
type PolicyRule struct { Verbs []string `json:"verbs" protobuf:"bytes,1,rep,name=verbs"` APIGroups []string `json:"apiGroups,omitempty" protobuf:"bytes,2,rep,name=apiGroups"` Resources []string `json:"resources,omitempty" protobuf:"bytes,3,rep,name=resources"` ResourceNames []string `json:"resourceNames,omitempty" protobuf:"bytes,4,rep,name=resourceNames"` NonResourceURLs []string `json:"nonResourceURLs,omitempty" protobuf:"bytes,5,rep,name=nonResourceURLs"` }那角色是怎么和绑定的呢，这就要看RoleBinding和ClusterRoleBinding
type RoleBinding struct { metav1.TypeMeta `json:",inline"` metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"` Subjects []Subject `json:"subjects" protobuf:"bytes,2,rep,name=subjects"` RoleRef RoleRef `json:"roleRef" protobuf:"bytes,3,opt,name=roleRef"` }相同属性的的结构体
type ClusterRoleBinding struct { metav1.TypeMeta `json:",inline"` metav1.ObjectMeta `json:"metadata,omitempty" protobuf:"bytes,1,opt,name=metadata"` Subjects []Subject `json:"subjects" protobuf:"bytes,2,rep,name=subjects"` RoleRef RoleRef `json:"roleRef" protobuf:"bytes,3,opt,name=roleRef"` }主要看两个，第一个是Subjects，它就是关联的对象（”User”, “Group”, 和指定命名空间下的： “ServiceAccount”），第二个是RoleRef，他是是角色的关联。可以看上一篇heapster的rbac就理解怎样使用了。 kubernetes系统自身组件的运行也是需要这些权限管理的，所以系统初始了一些角色和默认的权限，看代码plugin/pkg/auth/authorizer/rbac/bootstrappolicy/policy.go：
先看读写权限的定义
ReadWrite = []string{"get", "list", "watch", "create", "update", "patch", "delete", "deletecollection"} Read = []string{"get", "list", "watch"}对应于API的各种操作。
{ // a "root" role which can do absolutely anything ObjectMeta: metav1.ObjectMeta{Name: "cluster-admin"}, Rules: []rbac.PolicyRule{ rbac.NewRule("*").Groups("*").Resources("*").RuleOrDie(), rbac.NewRule("*").URLs("*").RuleOrDie(), }, }, { // a role which provides just enough power to determine if the server is ready and discover API versions for negotiation ObjectMeta: metav1.ObjectMeta{Name: "system:discovery"}, Rules: []rbac.PolicyRule{ rbac.NewRule("get").URLs("/healthz", "/version", "/swaggerapi", "/swaggerapi/*", "/api", "/api/*", "/apis", "/apis/*").RuleOrDie(), }, }, { // a role which provides minimal resource access to allow a "normal" user to learn information about themselves ObjectMeta: metav1.ObjectMeta{Name: "system:basic-user"}, Rules: []rbac.PolicyRule{ // TODO add future selfsubjectrulesreview, project request APIs, project listing APIs rbac.NewRule("create").Groups(authorizationGroup).Resources("selfsubjectaccessreviews").RuleOrDie(), }, }, ....上面截取了部分代码，他们是系统角色的定义，譬如cluster-admin角色，它的权限是
rbac.NewRule("*").Groups("*").Resources("*").RuleOrDie(), rbac.NewRule("*").URLs("*").RuleOrDie(),匹配所有规则，所有URL，所有资源，那么它将是一个“root”级别，最高权限，所以在kubernetes中kubectl的证书里面”O”: “system:masters”,这个用户组管理的就是cluster-admin这个角色，下面会细说。 先简单分析一下系统里面主要角色： 1.cluster-admin：最高管理角色 2.system:discovery：接口发现角色，主要是接口查询
rbac.NewRule("get").URLs("/healthz", "/version", "/swaggerapi", "/swaggerapi/*", "/api", "/api/*", "/apis", "/apis/*")3.system:basic-user基础角色，最少访问权限 4.admin 空间级别的管理员，有基础资源的增删改查
rbac.NewRule(ReadWrite...).Groups(legacyGroup).Resources("pods", "pods/attach", "pods/proxy", "pods/exec", "pods/portforward").RuleOrDie(), rbac.NewRule(ReadWrite...).Groups(legacyGroup).Resources("replicationcontrollers","replicationcontrollers/scale","serviceaccounts","services", "services/proxy", "endpoints", "persistentvolumeclaims", "configmaps", "secrets").RuleOrDie() ...5.edit空间级别修改角色 6.view空间级别查看角色 7.system:heapster集群级别heapster角色，提供资源查询权限
rbac.NewRule(Read...).Groups(legacyGroup).Resources("events", "pods", "nodes", "namespaces").RuleOrDie(),8.system:node系统级别node节点操作角色 9.system:node-proxier系统级别proxy操作角色 10.system:node-bootstrapper系统级别node启动操作角色，启动时候证书签名用
rbac.NewRule("create", "get", "list", "watch").Groups(certificatesGroup).Resources("certificatesigningrequests").RuleOrDie(),11.system:kube-controller-manager系统级别kube-controller-manager操作角色 12.system:kube-scheduler系统级别kube-scheduler操作角色 13.system:kube-dns系统级别kube-dns操作角色，看过之前源码阅读的就理解了这里为啥是endpoints和services的listwatch了。
rbac.NewRule("list", "watch").Groups(legacyGroup).Resources("endpoints", "services").RuleOrDie(),14.system:persistent-volume-provisioner系统级别PV、PVC操作。 看完系统初始化的这些角色和对应的权限后，看看系统初始化的角色绑定
func ClusterRoleBindings() []rbac.ClusterRoleBinding { rolebindings := []rbac.ClusterRoleBinding{ rbac.NewClusterBinding("cluster-admin").Groups(user.SystemPrivilegedGroup).BindingOrDie(), rbac.NewClusterBinding("system:discovery").Groups(user.AllAuthenticated, user.AllUnauthenticated).BindingOrDie(), rbac.NewClusterBinding("system:basic-user").Groups(user.AllAuthenticated, user.AllUnauthenticated).BindingOrDie(), rbac.NewClusterBinding("system:node").Groups(user.NodesGroup).BindingOrDie(), rbac.NewClusterBinding("system:node-proxier").Users(user.KubeProxy).BindingOrDie(), rbac.NewClusterBinding("system:kube-controller-manager").Users(user.KubeControllerManager).BindingOrDie(), rbac.NewClusterBinding("system:kube-dns").SAs("kube-system", "kube-dns").BindingOrDie(), rbac.NewClusterBinding("system:kube-scheduler").Users(user.KubeScheduler).BindingOrDie(), } addClusterRoleBindingLabel(rolebindings) return rolebindings }这样就可以看到cluster-admin这个角色关联到system:masters这个用户组，system:node-proxier关联到system:kube-proxy这个用户，其它也都是类似的。
