RBAC使用rbac.authorization.k8s.io API Group 来实现授权决策，允许管理员通过 KubernetesAPI 动态配置策略。

Kubernetes的基本特性就是它的所有资源对象都是模型化的 API 对象，我们可以基于api-server对各种
资源进行增、删、改、查等操作，但是这些操作涉及到的不仅仅是资源本身和动作，而且还涉及到资源和动作
之间的内容，比如api的分组版本和资源和api的关联即权限授权等。

要启用RBAC，需要在 apiserver 中添加参数--authorization-mode=RBAC，
kubeadm安装的集群默认开启了RBAC，我们可以通过查看 Master 节点上 apiserver 的静态Pod定义文件：

master1 ~]# cat /etc/kubernetes/manifests/kube-apiserver.yaml 
...
spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=192.168.10.26
    - --allow-privileged=true
    - --authorization-mode=Node,RBAC
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    - --enable-admission-plugins=NodeRestriction
    - --enable-bootstrap-token-auth=true
...

授权指的是，将某些subject对象赋予执行某些资源动作的权限。我们有时候会将其称为
Group(权限组)，而这个组其实是有两部分组成：组名和组关联(也称绑定)。
简单来说：所谓的授权，其实是为用户授予xx角色

其实是附加在某些资源上的一系列权限，对于k8s来说，它主要有两类：Role和
clusterRole，其中Role主要是作用于namespace，而clusterRole主要作用于多个
namespace，它们之间是一对多的关系。
我们为了将权限应用和具体权限列表分开描述，我们一般称权限列表为规则-rules

所谓的组关联其实是将我们之前定义的Subject和对应的权限组关联在一起，表示某个Subject具有执行某个资源的一系列动作权限。
它主要涉及到两个RoleBingding和ClusterRoleBingding。

为了更好的解释这四个属性，我们按照其工作的范围将其划分为三类进行描述:namespace级别、cluster级别、混合级别。

术语          解析
rules         规则，是一组属于不同 API Group 资源上的权限操作的集合
role          表示在一个namespace中基于rules使用资源的权限，属于集群内部的 API 资源，主要涉及到操作和对象
RoleBingding  将Subject和Role绑定在一起，表示Subject可以在namespace中使用指定资源的role角色权限

术语                     解析
ClusterRole              表示在一个cluster中基于rules使用资源的权限，属于集群内部的 API 资源，一个cluster有多个namespace即有多个role
ClusterRoleBingding      将Subject和ClusterRole绑定在一起，表示Subject可以在cluster中使用指定资源的ClusterRole角色权限

术语:RoleBingding

解析:将Subject基于RoleBingding与ClusterRole绑定在一起，表示Subject可以使用
所有namespace中指定资源的role角色，从而避免了多次role和user的RoleBingding。

同样的操作，站在ClusterRole的角度，我们可以理解为，用户得到的权限仅是
ClusterRole的权限在Rolebinding所属的名称空间上的一个子集，也就是所谓的"权限降级"

多个namespace中的role角色都一致，如果都使用内部的RoleBingding的话，每个namespace都必
须单独创建role，而使用ClusterRole的话，只需要一个就可以了，大大的减轻批量使用namespace中的RoleBingding 操作。

master1 ~]# kubectl explain role
apiVersion <string>
kind <string>
metadata     <Object>
rules       <[]Object>
  apiGroups   <[]string>
  nonResourceURLs     <[]string>
  resourceNames       <[]string>
  resources   <[]string>
  verbs       <[]string> -required

结果显示：
    对于role来说，其核心的内容主要是rules的权限规则
    在这么多rules属性中，最重要的是verbs就是权限条目，而且所有的属性都是可以以列表的形式累加存在。

# 查看pod角色具有get、list权限的role的资源定义文件格式
master1 ~]# kubectl create role pod-reader --verb=get,list --resource=pods --dry-run=client -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  creationTimestamp: null   # 创建的时间
  name: pod-reader          # role名字
rules:                      # 规则
- apiGroups:                # api操作的对象
  - ""                      # 默认所有
  resources:                # 资源对象
  - pods
  verbs:                    # 资源的权限
  - get                     # 获取-权限
  - list                    # 查看-权限


一个role必备的rules来说，它主要有三部分组成：apiGroup、resources、verbs
    apiGroups 设定包含资源的api组，如果是多个，表示只要属于api组范围中的任意资源都可以操作
    resources 位于apiGroup范围中的某些具体的资源对象
    verbs     针对具体资源对象的一些具体操作


关于apiGroups的信息获取，参考官网：https://kubernetes.io/docs/reference/#api-reference

cat >security-myrole.yml<<'EOF'
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: myrole
rules:
- apiGroups: ["", "extensions", "apps"]
  resources: ["pods", "deployments", "replicasets"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
EOF

属性解析：
apiGroups
   Pod属于 core 的 API Group，在YAML中用空字符就可以
   Deployment 属于 apps 的 API Group
   ReplicaSets属于extensions这个 API Group，所以 rules 下面的 apiGroups 的内容：["", "extensions", "apps"]
verbs
   是可以对这些资源对象执行的操作，如果是所有动作，也可以使用["*"]来代替。

master1 ]# kubectl apply -f security-myrole.yml 
role.rbac.authorization.k8s.io/myrole created

master1 ]# kubectl get role
NAME     CREATED AT
myrole   2023-03-30T12:51:09Z

master1 ]# kubectl describe role myrole 
Name:         myrole
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources               Non-Resource URLs  Resource Names  Verbs
  ---------               -----------------  --------------  -----
  deployments             []                 []              [get list watch create update patch delete]
  pods                    []                 []              [get list watch create update patch delete]
  replicasets             []                 []              [get list watch create update patch delete]
  deployments.apps        []                 []              [get list watch create update patch delete]
  pods.apps               []                 []              [get list watch create update patch delete]
  replicasets.apps        []                 []              [get list watch create update patch delete]
  deployments.extensions  []                 []              [get list watch create update patch delete]
  pods.extensions         []                 []              [get list watch create update patch delete]
  replicasets.extensions  []                 []              [get list watch create update patch delete]

通过explain的命令来看一下rolebinding的属性信息

master1 ]# kubectl explain rolebinding
apiVersion   <string>
kind <string>
metadata     <Object>
roleRef     <Object> -required
subjects     <[]Object>

对于角色绑定来说，主要涉及到两点：subject和对应的role权限列表，其中roleRef是必选项。

# 这里cyc的subject来与myrole进行一次模拟绑定查看属性效果
master1 ~]# kubectl create rolebinding cyc-myrole --role=myrole --user=cyc -o yaml --dry-run=client
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  creationTimestamp: null
  name: cyc-myrole
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: myrole
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: cyc
  
# 对于roleRef和subjects分别写好其对应的资源属性信息即可

# 生成yml配置清单
master1]# kubectl create rolebinding cyc-myrole --role=myrole --user=cyc -o yaml --dry-run=client >security-rolebinding.yml

kubectl create rolebinding cyc-myrole --role=myrole --user=cyc
注意：如果是多个用户的话，可以多来几个 --user=subject 彼此间使用空格隔开即可

kubectl apply -f security-rolebinding.yml

注意：如果是多个用户的话，可以多来几个 --user=subject 彼此间使用空格隔开即可

master1 ]# kubectl get rolebindings
NAME         ROLE          AGE
cyc-myrole   Role/myrole   62s

master1 ]# kubectl describe rolebindings cyc-myrole 
Name:         cyc-myrole
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  Role
  Name:  myrole
Subjects:
  Kind  Name  Namespace
  ----  ----  ---------
  User  cyc   
  
# 已经加入到 myrolebinding 角色绑定组中了,这里的namespace没有写，表示默认的default命名空间

1、查看当前namespace:default中资源效果
master1 ]# kubectl get pod --context=cyc@mycluster --kubeconfig=/tmp/cyc.conf 
NAME           READY   STATUS    RESTARTS   AGE
pod-sa-admin   1/1     Running   0          7h39m


2、查看default命名空间中，非pod、deployment、rs之外的资源
master1 ]# kubectl get secrets --context=cyc@mycluster --kubeconfig=/tmp/cyc.conf 
Error from server (Forbidden): secrets is forbidden: User "cyc" cannot list resource "secrets" in API group "" in the namespace "default" 
# 在我们role之外的内容我们都没有权限查看


3、查看非当前namespace中的资源
master1 security]# kubectl -n kube-system get pod --context=cyc@mycluster --kubeconfig=/tmp/cyc.conf 
Error from server (Forbidden): pods is forbidden: User "cyc" cannot list resource "pods" in API group "" in the namespace "kube-system"
# 在当前role权限范围内容，其它namespace中的资源，我们生效不了，因为role只是针对某个具体的ns

# 查看SA的角色绑定格式
kubectl create rolebinding NAME --role=NAME [--serviceaccount=namespace:serviceaccountname]

属性解析：我们在基于服务账号进行关联的时候，需要关注一下该SA所属的namespace信息。

# 相关的创建serviceaccount帐号教程：
https://www.cnblogs.com/ygbh/p/17270653.html#_lab2_5_3

# 1、我们的自建的sa是admin而且是属于default空间
master1 ]# kubectl get sa admin -o yaml | grep namespace
      {"apiVersion":"v1","kind":"ServiceAccount","metadata":{"annotations":{},"name":"admin","namespace":"default"}}
  namespace: default


# 2、我们先将admin和myrole进行绑定，查看一下效果
master1 ]# kubectl create rolebinding myrolebinding-sa-admin --role=myrole --serviceaccount=default:admin
rolebinding.rbac.authorization.k8s.io/myrolebinding-sa-admin created

master1 ]# kubectl describe rolebindings myrolebinding-sa-admin 
Name:         myrolebinding-sa-admin
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  Role
  Name:  myrole
Subjects:
  Kind            Name   Namespace
  ----            ----   ---------
  ServiceAccount  admin  default

# 我们的admin加入到了myrolebinding1的绑定组中了，而且显示了特定的命名空间

所谓的cluster级别的实践主要涉及到clusterRole和ClusterRoleBingding之间的操作，也就是说我们可以操作多个namespace空间的资源。

kubectl explain clusterrole
aggregationRule     <Object>
apiVersion <string>
kind <string>
metadata     <Object>
rules       <[]Object>
   apiGroups   <[]string>
   nonResourceURLs     <[]string>
   resourceNames       <[]string>
   resources   <[]string>
   verbs       <[]string> -required结果显示：
 
clusterrole相对于role的属性多了一个集中控制器的属性aggregationRule，而这是一个可选的属性

master1 ~]# kubectl create clusterrole myclusterrole --verb=get,list --resource=pods -o yaml --dry-run=client
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: null
  name: myclusterrole
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list

单从模板的资源配置样式来说，他的配置信息与role的配置信息几乎一样

cat >security-myclusterrole.yml<<'EOF'
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: myclusterrole
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
EOF

kubectl apply -f security-myclusterrole.yml

master1 ]# kubectl get clusterrole | grep -E 'my|NAME'
NAME                                                                   CREATED AT
myclusterrole                                                          2023-03-30T14:25:20Z

master1 ~]# kubectl describe clusterrole myclusterrole 
Name:         myclusterrole
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  pods       []                 []              [get list watch] # 在myclasterrole仅仅有pod资源的三种权限

命令格式
kubectl create clusterrolebinding NAME --clusterrole=NAME [--user=username] ...

属性解析
对于clusterrolebinding来说，仅仅允许集群角色进行和其进行绑定，对于普通的role来说就无效了

master1 ~]# kubectl create clusterrolebinding myclusterrolebing --clusterrole=myclusterrole --user=cyc -o yaml --dry-run 
W0330 22:30:27.161658  107064 helpers.go:663] --dry-run is deprecated and can be replaced with --dry-run=client.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  creationTimestamp: null
  name: myclusterrolebing
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: myclusterrole
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: cyc

属性解析：
    这里的属性配置与我们之前的role和rolebinding的方法几乎一样
    区别就是kind和--clusterrole的不同

master1 ~]# kubectl create clusterrolebinding myclusterrolebing --clusterrole=myclusterrole --user=cyc
clusterrolebinding.rbac.authorization.k8s.io/myclusterrolebing created

master1 ~]# kubectl get clusterrolebindings.rbac.authorization.k8s.io | grep -E 'NAME|my'
NAME                                                   ROLE                                                                               AGE
myclusterrolebing                                      ClusterRole/myclusterrole                                                          26s

master1 ~]# kubectl describe clusterrolebindings myclusterrolebing 
Name:         myclusterrolebing
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  ClusterRole
  Name:  myclusterrole
Subjects:
  Kind  Name  Namespace
  ----  ----  ---------
  User  cyc  # 我们将cyc的账号，赋予了操作集群角色的权限

master1 ~]# kubectl get pod --context=cyc@mycluster --kubeconfig=/tmp/cyc.conf 
NAME           READY   STATUS    RESTARTS   AGE
pod-sa-admin   1/1     Running   0          9h

master1 ~]# kubectl -n kube-system get pod --context=cyc@mycluster  --kubeconfig=/tmp/cyc.conf 
NAME                              READY   STATUS    RESTARTS         AGE
coredns-75c9cf9bd7-55d6h          1/1     Running   0                7d7h
...
kube-scheduler-master3            1/1     Running   5 (24h ago)      14d
...
对于clusterrolebinding来说，绑定后的user account不但可以看到当前namespace中的资源对象，还能看到其他namespace中的资源对象

所谓的cluster级别的实践主要涉及到clusterRole和rolebinding之间的操作，也就是说虽然我们可以
操作很大范围的权限，但是由于某个特殊的场景我们需要避免大的权限，采用rolebinding的方式来主动降
低可行的执行权限，即，在混合级别实践的场景中，无论我们的用户是哪一个，我们只需要关联同一个
clusterrole，那么这个用户只能在指定的namespace空间中进行响应的操作。

# 还原环境
kubectl delete rolebinding myrolebinding
kubectl delete rolebinding myrolebinding1
kubectl delete clusterrolebinding myclusterrolebinding
当前subject和clusterrole现状
]$ kubectl get clusterrole | egrep 'NA|my'
NAME                                                       CREATED AT
myclasterrole                                             2021-10-06T23:28:08Z
]$ kubectl config get-contexts
CURRENT   NAME                         CLUSTER     AUTHINFO           
NAMESPACE
*         kubernetes-admin@kubernetes   kubernetes   kubernetes-admin   

kubectl create rolebinding NAME --clusterrole=NAME|--role=NAME [--user=username]
属性解析：
   对于rolebinding来说，我可以基于clusterrole和role两种角色进行绑定操作。

master1 ~]# kubectl create rolebinding merge-role --clusterrole=myclusterrole --user=cyc -o yaml --dry-run=client
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  creationTimestamp: null
  name: merge-role
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: mycluster
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: cyc

master1 ]# kubectl create rolebinding merge-role --clusterrole=myclusterrole --user=cyc -o yaml --dry-run=client >security-merge-binding.yml

master1 ]# vi security-merge-binding.yml 
  creationTimestamp: null
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  namespace: default
  name: merge-role
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: myclusterrole
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: cyc
# 我们将自动生成的配置文件中的时间戳删除，然后给其设定了一个namespace的权限范围属性

master1 ]# kubectl apply -f security-merge-binding.yml 
rolebinding.rbac.authorization.k8s.io/merge-role created


master1 ]# kubectl get rolebindings.rbac.authorization.k8s.io 
NAME         ROLE                    AGE
merge-role   ClusterRole/mycluster   86s

master1 ~]# kubectl describe rolebindings merge-role 
Name:         merge-role
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  ClusterRole
  Name:  myclusterrole
Subjects:
  Kind  Name  Namespace
  ----  ----  ---------
  User  cyc  
  
# 我们已经将cyc采用rolebinding的方式赋予其clusterrole的角色权限

master1 ]# kubectl -n default get pod --context=cyc@mycluster --kubeconfig=/tmp/cyc.conf 
NAME           READY   STATUS    RESTARTS   AGE
pod-sa-admin   1/1     Running   0          9h

master1 ]# kubectl -n kube-system get pod --context=cyc@mycluster --kubeconfig=/tmp/cyc.conf 
Error from server (Forbidden): pods is forbidden: User "cyc" cannot list resource "pods" in API group "" in the namespace "kube-system"

# 对于rolebinding的clusterrole来说，我们只能访问指定的default空间中的资源了

# 我们知道对于自定义的myclusterrole来说，它对于pod只有查看的权限查询如下：
master1 ~]# kubectl describe clusterrole myclusterrole 
Name:         myclusterrole
Labels:       <none>
Annotations:  <none>
PolicyRule:
  Resources  Non-Resource URLs  Resource Names  Verbs
  ---------  -----------------  --------------  -----
  pods       []                 []              [get list watch]

# 没有删除的权限，我们无法对dafault命名空间的pod资源做权限之外的事情。
master1 ~]# kubectl  delete pod pod-sa-admin --context=cyc@mycluster --kubeconfig=/tmp/cyc.conf 
Error from server (Forbidden): pods "pod-sa-admin" is forbidden: User "cyc" cannot delete resource "pods" in API group "" in the namespace "default"

我们知道官方也给default空间提供了很多权限，admin的权限就是极大，admin的clusterrole它是在default命名空间中的，而且对pod有各种操作权限

# 关联admin clusterrole
master1 ~]# kubectl create rolebinding default-ns-admin --clusterrole=admin --user=cyc
rolebinding.rbac.authorization.k8s.io/default-ns-admin created

# 删除原来关联
master1 ~]# kubectl delete rolebindings merge-role 
rolebinding.rbac.authorization.k8s.io "merge-role" deleted

# 查询设置
master1 ~]# kubectl describe rolebindings default-ns-admin 
Name:         default-ns-admin
Labels:       <none>
Annotations:  <none>
Role:
  Kind:  ClusterRole
  Name:  admin
Subjects:
  Kind  Name  Namespace
  ----  ----  ---------
  User  cyc 

# 使用cyc用户，获取pod
master1 ~]# kubectl get pod --context=cyc@mycluster --kubeconfig=/tmp/cyc.conf 
NAME           READY   STATUS    RESTARTS   AGE
pod-sa-admin   1/1     Running   0          10h

# 使用cyc用户，删除pod
master1 ~]# kubectl delete pod pod-sa-admin --context=cyc@mycluster --kubeconfig=/tmp/cyc.conf 
pod "pod-sa-admin" deleted

# 查询命令空间：kube-system，没有权限
master1 ~]# kubectl -n kube-system get pod --context=cyc@mycluster --kubeconfig=/tmp/cyc.conf 
Error from server (Forbidden): pods is forbidden: User "cyc" cannot list resource "pods" in API group "" in the namespace "kube-system"

# 我们只能管理当前命名空间的资源，其他命名空间的资源是管理不了的。

# 原因是rolebindings命令空间配置default,所以只能管理default
master1 ~]# kubectl get rolebindings default-ns-admin -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  creationTimestamp: "2023-03-30T15:35:45Z"
  name: default-ns-admin
  namespace: default
  resourceVersion: "1001958"
  uid: 8e374dff-323a-4ab1-a848-e1281c8240ec
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: cyc

# 删原来的配置
kubectl delete rolebinding default-ns-admin;

# 指定命令空间创建
kubectl create rolebinding default-ns-admin --clusterrole=admin --user=cyc --namespace=kube-system;

# 此时cyc用户，可以的管理kube-system权限
master1 ~]# kubectl -n kube-system get pod  --context=cyc@mycluster --kubeconfig=/tmp/cyc.conf 
NAME                              READY   STATUS    RESTARTS         AGE
coredns-75c9cf9bd7-55d6h          1/1     Running   0                7d9h

#此时命令空间：default,也不能被cyc用户管理
master1 ~]# kubectl -n default get pod  --context=cyc@mycluster --kubeconfig=/tmp/cyc.conf 
Error from server (Forbidden): pods is forbidden: User "cyc" cannot list resource "pods" in API group "" in the namespace "default"