23.kubernetes(k8s)笔记 认证、授权与准入控制(三) RBAC 访问控制

RBAC 访问控制 Users Accounts

---

前言:
前面已经对ServiceAccount、Users Account认证进行了介绍与创建,但最后的测试发现是Users Account并没有访问权限,本节介绍RBAC授权 对ServiceAccount、Users Account认证进行授权

RBAC是什么？

RBAC 是基于角色的访问控制（Role-Based Access Control ）在 RBAC 中，权限与角色相关联，用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。这样管理都是层级相互依赖的，权限赋予给角色，而把角色又赋予用户，这样的权限设计很清楚，管理起来很方便。

角色
　　Role：角色,名称空间级别;授权特定命名空间的访问权限
　　ClusterRole：集群角色,全局级别;授权所有命名空间的访问权限

角色绑定
　　RoleBinding：将角色绑定到主体（即subject）,意味着，用户仅得到了特定名称空间下的Role的权限，作用范围也限于该名称空间;
　　ClusterRoleBinding：将集群角色绑定到主体,让用户扮演指定的集群角色;意味着，用户得到了是集群级别的权限，作用范围也是集群级别;
　　
主体（subject）
　　User：用户
　　Group：用户组
　　ServiceAccount：服务账号

绑定对应关系
主体(Subject) --> RoleBinding --> Role #主体获得名称空间下的Role的权限
主体(Subject) --> ClusterRoleBinding --> clusterRoles #主体获得集群级别clusterRoles的权限
主体(Subject) --> Rolebindig -->ClusterRole #权限降级 主体获得名称空间下的clusterRoles的权限

• rules中的参数说明：
  1、apiGroups：支持的API组列表，例如："apiVersion: batch/v1"等
  2、resources：支持的资源对象列表，例如pods、deplayments、jobs等
  3、resourceNames: 指定resource的名称
  3、verbs：对资源对象的操作方法列表。

• RBAC使用rbac.authorization.k8s.io API Group 来实现授权决策，允许管理员通过 Kubernetes API 动态配置策略，要启用RBAC，需要在 apiserver 中添加参数--authorization-mode=RBAC，如果使用的kubeadm安装的集群，都默认开启了RBAC，可以通过查看 Master 节点上 apiserver 的静态Pod定义文件：

[root@k8s-master usercerts]# cat /etc/kubernetes/manifests/kube-apiserver.yaml 
apiVersion: v1
kind: Pod
metadata:
 ...
spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=192.168.4.170
    - --allow-privileged=true
    - --authorization-mode=Node,RBAC   #默认支持BRAC 基于角色的访问控制
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    - --enable-admission-plugins=NodeRestriction
    - --enable-bootstrap-token-auth=true
    - --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
    - --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt
...

• 查看 kube-system名称空间下的role角色详情

[root@k8s-master ~]# kubectl get role -n kube-system
NAME                                             CREATED AT
extension-apiserver-authentication-reader        2021-06-28T17:43:31Z
kube-proxy                                       2021-06-28T17:43:33Z
kubeadm:kubelet-config-1.19                      2021-06-28T17:43:31Z
kubeadm:nodes-kubeadm-config                     2021-06-28T17:43:31Z
system::leader-locking-kube-controller-manager   2021-06-28T17:43:31Z
system::leader-locking-kube-scheduler            2021-06-28T17:43:31Z
system:controller:bootstrap-signer               2021-06-28T17:43:31Z
system:controller:cloud-provider                 2021-06-28T17:43:31Z
system:controller:token-cleaner                  2021-06-28T17:43:31Z

[root@k8s-master ~]# kubectl get role kube-proxy -n kube-system -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  creationTimestamp: "2021-06-28T17:43:33Z"
  managedFields:
  - apiVersion: rbac.authorization.k8s.io/v1
    fieldsType: FieldsV1
    fieldsV1:
      f:rules: {}
    manager: kubeadm
    operation: Update
    time: "2021-06-28T17:43:33Z"
  name: kube-proxy
  namespace: kube-system
  resourceVersion: "195"
  selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/kube-system/roles/kube-proxy
  uid: a5404b1f-90f0-447f-b104-86fcbdd388e0
rules:   #角色规则详细信息
- apiGroups:
  - ""
  resourceNames:
  - kube-proxy
  resources:
  - configmaps
  verbs:   #能执行的操作
  - get

• role角色绑定
• RoleBinding 角色绑定

[root@k8s-master ~]# kubectl explain rolebinding
KIND:     RoleBinding
VERSION:  rbac.authorization.k8s.io/v1
...
   roleRef