了解K8S的BRAC
Role-based access control(RBAC)基于企业内个人用户属于角色来访问计算和网络的常规访问控制方法。
简单理解为权限与角色关联，用户通过成为角色的成员来得到角色的权限。
K8S的RBAC使用rbac.authorization.k8s.io/v1 API组驱动认证决策，准许管理员通过API动态配置策略。
为了启用RBAC，需要在apiserver启动参数添加--authorization-mode=RBAC。
Service Account为服务提供了一种方便的认证机制，但它不关心授权的问题。可以配合RBAC来为Service Account鉴权。
在Kubernetes中，授权有6种模式：
ABAC（基于属性的访问控制）、
RBAC（基于角色的访问控制）、
Webhook（自定义http回调方法）、
Node（默认node和apiserver就是采用这种模式）、
AlwaysDeny（一直拒绝）和 AlwaysAllow（一直允许）。
在RABC API中，通过如下的步骤进行授权：
1）定义角色：在定义角色时会指定此角色对于资源的访问控制的规则；
2）绑定角色：将主体与角色进行绑定，对用户进行访问授权。
Role与ClusterRole
一个角色包含了一套表示一组权限的规则。 权限以纯粹的累加形式累积（没有”否定”的规则）。
Role：角色可以由命名空间内的Role对象定义，一个Role对象只能用于授予对某一单一命名空间中资源的访问权限
ClusterRole：整个Kubernetes集群范围内有效的角色则通过ClusterRole对象实现。
API概览
Role和ClusterRole
rule下verbs有
|
1 |
"get", "list", "watch", "create", "update", "patch", "delete", "exec" |
rule下资源有：
|
1 |
"services", "endpoints", "pods","secrets","configmaps","crontabs","deployments","jobs","nodes","rolebindings","clusterroles","daemonsets","replicasets","statefulsets","horizontalpodautoscalers","replicationcontrollers","cronjobs" |
rule下apiGroups有：
|
1 |
"","apps", "autoscaling", "batch" |
一个Role只能授权访问单个namespace:
|
1 2 3 4 5 6 7 8 9 |
kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: namespace: default name: pod-reader rules: - apiGroups: [""] # "" indicates the core API group resources: ["pods"] verbs: ["get", "watch", "list"] |
一个ClusterRole能够授予和Role一样的权限，但是它是集群范围内的。
|
1 2 3 4 5 6 7 8 9 |
kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: # "namespace" omitted since ClusterRoles are not namespaced name: secret-reader rules: - apiGroups: [""] resources: ["secrets"] verbs: ["get", "watch", "list"] |
RoleBinding和ClusterROleBinding
RoleBinding将role中定义的权限分配给用户和用户组。RoleBinding包含主题（users,groups,或service accounts）和授予角色的引用。对于namespace内的授权使用RoleBinding，集群范围内使用ClusterRoleBinding。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
kind: RoleBinding apiVersion: rbac.authorization.k8s.io/v1 metadata: name: read-pods namespace: default subjects: - kind: User #这里可以是User,Group,ServiceAccount name: jane apiGroup: rbac.authorization.k8s.io roleRef: kind: Role #这里可以是Role或者ClusterRole name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to apiGroup: rbac.authorization.k8s.io |
示例
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
apiVersion: v1 kind: ServiceAccount metadata: name: test-account namespace: kube-system --- kind: ClusterRole apiVersion: rbac.authorization.k8s.io/v1 metadata: name: test-account namespace: kube-system rules: - apiGroups: ["", "apps", "autoscaling", "batch"] resources: ["services", "endpoints", "pods","secrets","configmaps","crontabs","deployments","jobs","nodes","rolebindings","clusterroles","daemonsets","replicasets","statefulsets","horizontalpodautoscalers","replicationcontrollers","cronjobs"] verbs: ["get", "list", "watch"] --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: test-account namespace: kube-system roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: test-account subjects: - kind: ServiceAccount name: test-account namespace: kube-system |
如果集群中有多个namespace分配给不同的管理员，但是他们的权限是一样的，那么这样可以先定义一个ClusterRole，然后通过RoleBinding将不同namespace的管理员做绑定，这样可以解决多次定义Role的问题。
