【Kubernetes】基于角色的权限控制：RBAC

　Kubernetes中所有的API对象，都保存在Etcd里，对这些API对象的操作，一定都是通过访问kube-apiserver实现的，原因是需要APIServer来做授权工作。

　　在Kubernetes中，负责完成授权（Authorization）工作的机制，就是RBAC：基于角色的访问控制（Role-Based Access Control）

　　RBAC中有三个最基本的概念：

1、Role：角色，它其实是一组规则，定义了一组对Kubernetes API对象的操作权限

　　Role本身是一个Kubernetes的API对象，定义如下所示：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: mynamespace  ## 指定它能产生作用的Namespace
  name: example-role
rules:    ##  定义权限规则
- apiGroups: [""]
  resources: ["pods"]  ## 对mynamespace下面的Pod对象
  verbs: ["get", "watch", "list"]   ## 进行GET、WATCH、LIST操作

2、Subject：被作用者，既可以是“人”，也可以是“机器”，也可以是Kubernetes里定义的“用户”

3、RoleBinding：定义了“被作用者”和“角色”的绑定关系

　　RoleBingding本身也是一个Kubernetes的API对象

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: example-rolebinding
  namespace: mynamespace
subjects:   ## 被作用者
- kind: User     ## 类型是User
  name: example-user  ## 用户名是example-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
## 通过roleRef字段，RoleBinding对象可以直接通过名字来引用Role对象，从而定义了被作用者（Subject）和角色（Role）之间的关系
  kind: Role
  name: example-role
  apiGroup: rbac.authorization.k8s.io

　　需要注意的是：Role和RoleBinding对象都是Namespaced对象，它们对权限限制规则仅在它们自己的Namespace内有效，roleRef也只能引用当前Namespace里的Role对象

　　那对于非Namespaced对象（如： node）或者一个Role想作用于所有的Namespace的时候，又该如何去做授权呢？

　　这个时候就必须要使用ClusterRole和ClusterRoleBinding这个组合了，这两个API对象的用法跟Role和RoleBinding完全一样，只不过它们的定义里没有了Namespace字段

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: example-clusterrole
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: example-clusterrolebinding
subjects:
- kind: User
  name: example-user
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: example-clusterrole
  apiGroup: rbac.authorization.k8s.io

　　 上面的例子里意味着名叫example-user的用户拥有对所有Namespace里的Pod进行GET、WATCH和LIST操作的权限。

　　如果想要赋予用户所有权限，那可以给它指定一个verbs字段的全集

verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

　　Role对象的Rules字段也可以进一步细化，如可以只针对某一个具体的对象进行权限设置

rules:
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["my-config"]
  verbs: ["get"]

　　那现在还有一个问题，在Kubernetes中其实并没有一个叫做“User”的API对象，那这个User从哪里来呢？ 

　　在Kubernetes的User只是一个授权系统里的逻辑概念，在大多数私有的使用环境中，只需要使用Kubernetes提供的内置“用户”足够了。负责管理内置用户的是ServiceAccount

　　首先定义一个ServiceAccount

apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: mynamespace
  name: example-sa

　　然后通过编写RoleBinding的YAML文件，来为这个ServiceAccount分配权限

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: example-rolebinding
  namespace: mynamespace
subjects:
- kind: ServiceAccount
  name: example-sa
  namespace: mynamespace
roleRef:
  kind: Role
  name: example-role
  apiGroup: rbac.authorization.k8s.io

　　接着创建这个三个对象

$ kubectl create -f svc-account.yaml
$ kubectl create -f role-binding.yaml
$ kubectl create -f role.yaml

$ kubectl get sa -n mynamespace -o yaml
- apiVersion: v1
  kind: ServiceAccount
  metadata:
    creationTimestamp: 2018-09-08T12:59:17Z
    name: example-sa
    namespace: mynamespace
    resourceVersion: "409327"
    ...
  secrets:
  - name: example-sa-token-vmfg6

　　可以看到，Kubernetes会为一个ServiceAccount自动创建并分配一个Secret对象。这个Secret就是ServiceAccount对应的、用来跟APIServer进行交互的授权文件，一般称为Token。 Token文件的内容一般是证书或者密码，它以一个Secret对象的方式保存在Etcd中。

　　这时候，用户的Pod就可以声明使用这个ServiceAccount了

apiVersion: v1
kind: Pod
metadata:
  namespace: mynamespace
  name: sa-token-test
spec:
  containers:
  - name: nginx
    image: nginx:1.7.9
  serviceAccountName: example-sa

$ kubectl describe pod sa-token-test -n mynamespace
Name:               sa-token-test
Namespace:          mynamespace
...
Containers:
  nginx:
    ...
    Mounts:
      /var/run/secrets/kubernetes.io/serviceaccount from example-sa-token-vmfg6 (ro)

　　如果一个Pod没有声明serviceAccountName，Kubernetes会自动在它的Namespace下创建一个名叫default的默认ServiceAccount，然后分配给这个Pod，这个默认的ServiceAccount并没有关联任何Role。

　　除了 前面使用的User，Kubernetes还有用户组（Group）的概念

　　实际上一个ServiceAccount，在Kubernetes里对应的User的名字是：

system:serviceaccount:<ServiceAccount 名字 >

　　那它对应的Group的名字就是

system:serviceaccounts:<Namespace 名字 >

　　现在可以在RoleBinding里定义如下的subjects：

subjects:
- kind: Group
  name: system:serviceaccounts:mynamespace  ## Role权限规则作用于Namespace里所有的ServiceAccount
  apiGroup: rbac.authorization.k8s.io

subjects:
- kind: Group
  name: system:serviceaccounts  ## Role权限规则作用于整个系统里所有ServiceAccount
  apiGroup: rbac.authorization.k8s.io

在这个国度中，必须不停地奔跑，才能使你保持在原地。如果想要寻求突破，就要以两倍现在速度奔跑！