K8s权限访问控制RBAC

本文涉及到的API对象有: secret, serviceAccount, Role, RoleBinding, ClusterRole, ClusterRoleBinding，他们的关系图如下所示

secret：定义了在etcd中保存的一些保密信息，可以是用户名密码，也可以是秘钥

serviceAccount: 对secret进行了一次封装的概念，并提供给roleBinding或者是clusterRoleBinding对象使用

Role: 一组操作权限的集合，可以指定API对象(如pod,configMap等)操作权限(read,write,patch等)

RoleBinding: 将ServiceAccount对象指定相关的Role权限

ClusterRoleBinding和ClusterRole：和RoleBinding,Role对象类似，只不过作用范围是整个cluster，而并非namespace.

当我们使用yaml文件创建pod时没有指定serviceAccount时，k8s会自动创建一个default的ServiceAccount,如下所示:

[root@kubenode1p ~]# kubectl get sa
NAME      SECRETS   AGE
default   1         96d
[root@kubenode1p ~]# kubectl get sa -o yaml
apiVersion: v1
items:
- apiVersion: v1
  imagePullSecrets:
  - name: acr-credential-c6c63a124360s1a13361512e545490fd
  - name: acr-credential-be5ac8be6a88f42ac1d831b85135a585
  kind: ServiceAccount
  metadata:
    creationTimestamp: "2019-12-16T03:16:18Z"
    name: default
    namespace: default
    resourceVersion: "24809662"
    selfLink: /api/v1/namespaces/default/serviceaccounts/default
    uid: 596fa119-d830-11e9-816a-ce9f6as5a244
  secrets:
  - name: default-token-b6l96
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""
[root@kubenode1p ~]#

这个默认的serviceAccount会关联default-token-b6l96这个secret.

需要注意的是，这个ServiceAccount是没有绑定任何Role的，默认他是有当前namespace的大部分权限的。 以下将它绑定到一个拥有只读权限的Role.

1. 创建只读权限的Role

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: test-role
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

2. 绑定Role

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

3. kubectl apply yaml文件

这个时候，如果使用这个serviceaccout的秘钥访问k8s集群，就只能看，不能去create或者delete相关pod了。

总结：RBAC的这套机制通过Rolebinding对象将权限和用户进行了解耦，我们可以设计拥有不同权限的Role，当需要修改一个用户的权限，只需要把这个用户绑定不同的Role即可。不需要修改用户和Role的任何属性。