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