附006.Kubernetes RBAC授权
一 RBAC
1.1 RBAC授权
基于角色的访问控制（RBAC）是一种基于个人用户的角色来管理对计算机或网络资源的访问的方法。
RBAC使用rbac.authorization.k8s.io API组来推动授权决策，允许管理员通过Kubernetes API动态配置策略。
使用--authorization-mode=RBAC开启RBAC授权模块功能。
RBAC API定义了四个资源对象用于描述RBAC中用户和资源之间的连接权限：
- Role
- ClusterRole
- RoleBinding
- ClusterRoleBinding
二 角色
2.1 Role 和 ClusterRole
RBAC API声明了四种类型。
在RBAC API中，角色包含表示一组权限的规则。权限都是叠加的，没有deny规则。附加的（没有“拒绝”规则）。可以使用参数role在一个namespace中定义一个角色，或者在集群范围内使用ClusterRole定义集群角色。
一个Role只能用于授予对单个命名空间内的资源的访问权限。
示例1：
1 apiVersion: rbac.authorization.k8s.io/v1
2 kind: Role
3 metadata:
4 namespace: default
5 name: pod-reader
6 rules:
7 - apiGroups: [""] # "" indicates the core API group
8 resources: ["pods"]
9 verbs: ["get", "watch", "list"]解释：该Role授予对“default”命名空间中的pod的读取权限。
一个ClusterRole可用于授予与一个Role相同的权限，同时由于它们是群集范围的，因此它们还可用于授予对以下内容的访问权限：
- 集群范围的资源（如nodes）；
- non-resource endpoints（如“/healthz”）；
- 跨所有命名空间（可通过kubectl get pods --all-namespaces查看）的命名空间资源（如pods）。
示例2：
1 apiVersion: rbac.authorization.k8s.io/v1
2 kind: ClusterRole
3 metadata:
4 # "namespace" omitted since ClusterRoles are not namespaced
5 name: secret-reader
6 rules:
7 - apiGroups: [""]
8 resources: ["secrets"]
9 verbs: ["get", "watch", "list"]解释：该ClusterRole可用于授予对任何特定命名空间或所有命名空间中的secrets资源的读访问权限。
2.2 RoleBinding 和 ClusterRoleBinding
角色绑定将角色中定义的权限授予用户或用户组。它包含由users,groups,或service accounts组成的列表，以及对所授予角色的引用。可以在具有个RoleBinding集群名称或具有一个ClusterRoleBinding范围内授予权限。
一个RoleBinding可以引用同一名称空间中的Role。
示例：
1 apiVersion: rbac.authorization.k8s.io/v1
2 # This role binding allows "jane" to read pods in the "default" namespace.
3 kind: RoleBinding
4 metadata:
5 name: read-pods
6 namespace: default
7 subjects:
8 - kind: User
9 name: jane # Name is case sensitive
10 apiGroup: rbac.authorization.k8s.io
11 roleRef:
12 kind: Role #this must be Role or ClusterRole
13 name: pod-reader # this must match the name of the Role or ClusterRole you wish to bind to
14 apiGroup: rbac.authorization.k8s.io解释：该RoleBinding将“pod-reader”角色授予“default”命名空间中的用户“jane”，同时允许“jane”读取“default”命名空间中的pod。
该RoleBinding 使用roleRef将用户“jane”绑定到Role上面创建的名称pod-reader。
2.3 默认角色
API服务器创建了一组默认ClusterRole和ClusterRoleBinding对象。其中格式为system：前缀的表示该资源由系统基础设施所拥有。手动修改该类资源可能导致集群功能异常，若system:node的ClusterRole，定义了kubelet的权限。
提示：所有默认群集角色和角色绑定都标有kubernetes.io/bootstrapping=rbac-defaults。
三 角色相关命令
3.1 创建角色
1 [root@master ~]# kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods
2 role.rbac.authorization.k8s.io/pod-reader created解释：创建一个名为“pod-reader”的Role，允许用户在pod上执行“get”，“watch”和“list”。
1 [root@master ~]# kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod解释：创建一个指定了namespace为anotherpod的名为“pod-reader”的Role。
1 [root@master ~]# kubectl create role foo --verb=get,list,watch --resource=replicasets.apps解释：创建一个指定apiGroups的名为“foo”的Role，允许用户在replicasets.apps上执行“get”，“watch”和“list”。
1 [root@master ~]# kubectl create role foo --verb=get,list,watch --resource=pods,pods/status解释：创建一个指定子资源权限的名为“foo”的Role，允许用户在pods上执行“get”，“watch”和“list”。
3.2 创建集群角色
1 [root@master ~]# kubectl create clusterrole pod-reader --verb=get,list,watch --resource=pods解释：创建一个名为“pod-reader”的clusterrole，允许用户在pod上执行“get”，“watch”和“list”。
1 [root@master ~]# kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod解释：创建一个指定了resourceNames名为“pod-reader“的clusterrole，并允许执行“get”。
1 [root@master ~]# kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps解释：创建一个指定apiGroups的名为“foo”的clusterrole，允许用户在replicasets.apps上执行“get”，“watch”和“list”。
1 [root@master ~]# kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status解释：创建一个指定子资源权限的名为“foo”的clusterrole，允许用户在pods上执行“get”，“watch”和“list”。
1 [root@master ~]# kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/*解释：创建一个指定了non-resource路径名为“pod-reader“的clusterrole，并允许执行“get”。
3.3 权限和角色绑定
1 [root@master ~]# kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme解释：在acme的namespace中，将admin的clusterrole和bob用户进行绑定。
1 [root@master ~]# kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp --namespace=acme解释：在acme的namespace中，将view的clusterrole和myapp服务账号进行绑定。
1 [root@master ~]# kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme解释：在acme的namespace中，将view的clusterrole和myapp的namespace中的服务账号进行绑定。
3.4 权限和集群角色绑定
1 [root@master ~]# kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme解释：在整个集群中，将cluster-admin的clusterrole和root用户进行绑定。
1 [root@master ~]# kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy解释：在整个集群中，将system:node-proxier的clusterrole和system:kube-proxy用户进行绑定。
1 [root@master ~]# kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp解释：在整个集群中，将view的clusterrole和myapp中的acme服务账户进行绑定。
提示：roles和clusterroles的区别在于roles只能对某个命令空间内的资源定义权限。而集群角色定义的权限都是针对整个集群的命名空间的。
更多RBAC参考：https://kubernetes.io/docs/reference/access-authn-authz/rbac/#role-and-clusterrole
3.4 相关对比
ClusterRole和ClusterRoleBinding是针对整个Cluster范围内有效的，无论用户或资源所在的namespace是什么；
Role和RoleBinding的作用范围是局限在某个k8s namespace中的。
kubernetes在安装之初就已经生成了许多role、rolebinding、clusterrole和clusterrolebinding,它们也是属于kubernetes资源的一部分，可通过get、describe等命令查看，如下：
1 [root@master ~]# kubectl get role -n kube-system
1 [root@master ~]# kubectl describe role extension-apiserver-authentication-reader -n kube-system