经典的RBAC模型我们不必说
简单来说就是角色的权限控制
我们创建了对应的角色，然后由用户绑定角色，角色指定权限，来进行权限的访问控制
而在K8S中，定义了四种角色相关对象，来进行角色控制和角色绑定，分别是Role ClusterRole
RoleBinding ClusterRoleBinding
其中 Role是基于名称空间的角色，来操作名称空间下的资源
RoleBingding，将一个Role绑定一个角色
ClusterRole：集群的角色，来操作集群资源
ClusterRoleBinding，将ClusterRole绑定给一个用户
至于为何区分了Role和ClusterRole两个相关角色对象呢？
这也是来源于K8S集群中分为了不同维度
比如Pod Service这类对象，是存在于名称空间内的，那么这类可以交给Role来做，而类似Node,PV这类不存在于一个单一的命名空间，而是整个集群的话，那么就可以让ClusterRole来做
无论是ClusterRole还是Role，都是和角色做到了多对多的关系，而Role类对象和权限列表，也做到了多对多的关系
我们看下对应的书写示例
kubectl explain role.rules
| FIELDS:
apiGroups <[]string> APIGroups is the name of the APIGroup that contains the resources. If multiple API groups are specified, any action requested against one of the enumerated resources in any API group will be allowed. nonResourceURLs <[]string> NonResourceURLs is a set of partial urls that a user should have access to. *s are allowed, but only as the full, final step in the path Since non-resource URLs are not namespaced, this field is only applicable for ClusterRoles referenced from a ClusterRoleBinding. Rules can either apply to API resources (such as “pods” or “secrets”) or non-resource URL paths (such as “/api”), but not both. resourceNames <[]string> ResourceNames is an optional white list of names that the rule applies to. An empty set means that everything is allowed. resources <[]string> Resources is a list of resources this rule applies to. ResourceAll represents all resources. verbs <[]string> -required- Verbs is a list of Verbs that apply to ALL the ResourceKinds and AttributeRestrictions contained in this rule. VerbAll represents all kinds. |
上面字段中
ApiGroups, 是传入string数组，默认留空，传入就传入对应对象上面的apiVersion，这样就表明了限制固定的apiGroups
noResourceURLs，能访问的url
resourceNames： 能操作的白名单，也就是具体的Pod deployment的名字
resources 操作的对象列表，比如pod,deployment
verbs,操作动作,可以参考 kubectl api-resources -owide中的verbs列表
默认的yaml如下
| apiVersion: rbac.authorization.k8s.io/v1
kind: Role metadata: namespace: default #名称空间 name: pod-reader #名称 rules: – apiGroups: [“”] # “” 标明 core API 组,默认不标注为空字符串 resources: [“pods”] # 操作pod verbs: [“get”, “watch”, “list”] #可以的操作 |
利用这个Role,我们创建了一个角色,并声明了这个角色可以绑定的权限
然后是整体的权限流程
首先是需要一个ServiceAccount,作为整个流程中的用户,然后利用rolebinding来进行绑定关系
首先查看一个rolebinding
Kubectl get rolebinding xxx -oyaml
会在其内部详情中看到subjects一栏,其中声明了
RoleRef标明对应的Role,subjects声明了绑定的账号
其次是对应的serviceAccount
查看可以发现其中绑定了token
这个token就是我们远端登录k8s集群的验证方式
故一个账号使用流程也就是
一个账号带着一个令牌
当令牌被使用登录的时候
会带着这个令牌找到账号
账号找到所有绑定的角色
然后根据所有的角色获取所有的权限列表
如果想要最大的权限,可以考虑参考clusterAdmin
而接下来,我们看一下创建的全流程
首先是创建一个ServiceAccount
| apiVersion: v1
kind: ServiceAccount metadata: name: test namespace: default |
然后创建一个ClusterRole及 ClusterRoleBin去声明使用
| apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole metadata: name: test-role rules: – apiGroups: [“”] resources: [“namespaces”] verbs: [“get”, “watch”, “list”] — apiVersion: rbac.authorization.k8s.io/v1 kind: RoleBinding metadata: name: test-role-binding subjects: – kind: ServiceAccount name: test # ‘name’ 是区分大小写的 apiGroup: “” roleRef: kind: ClusterRole name: test-role apiGroup: rbac.authorization.k8s.io |
这样,我们就做到了利用RBAC去简单管理集群权限的流程
最后一个小扩展
如何使用RestAPI去访问K8S集群
创建ServiceAccount 关联一个权限
然后就可以利用官方提供的api加上ServiceAccount的token进行访问即可