k8s上rbac功能实践

上一篇已经讲到了 ABAC，这篇讲下 RBAC，RBAC 现在是 k8s 官方推荐的做权限限制的方案，ABAC 已经不再做功能增加了

官方文档写的有点复杂，这里简化描述下，RBAC 首先有2个概念：

一个叫 Role（或者是ClusterRole），Role 里面定义了可以干什么事情，有什么样的权限，Role 定义的资源只能是某个既定 namespace 下的，而ClusterRole 可以定义 cluster 相关的资源，比如对namespace这个资源本身的权限。
另外一个概念叫 RoleBinding(ClusterRoleBinding) 是一个把用户和 ROLE 关联起来的东西，即这个用户有这个 Role 里面定义的权限. PS用户一般是 –basic-auth-file 里面定义的用户，当然也有些系统默认有的账户，比如 system:unsecure 表示走http访问没有认证的。

具体的例子：

比如我们创建个

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

这样就创建了role，这个role限制了只能对pods进行读取操作，但是并没有人用这个role，所以现在还并不会有什么影响
注意其中的apigroup和resources 可以通过平常get -o yaml的方式来判断，一般apiVersion是v1的都不用写，resources在pod secret之类的后面加个s就行了
比如 deployment 要这样写

rules:
- apiGroups: ["extensions", "apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

在创建了 role 之后还需要创建个 rolebinding 来关联用户和权限

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-pods #按需求取个名字和之前的不相关
  namespace: default
subjects:
- kind: User
  name: jane #改成你自己的用户名 
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader #上面创建的role的名字
  apiGroup: rbac.authorization.k8s.io

这样就限制了用户jane 只能读取pods

然后再回到限制用户只能操作固定的 namespace 内的内容的问题上，并且可以自己创建 namespace 。

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
   name: namespace-creater
rules:
- apiGroups:
  - ""
  resources:
  - namespaces
  verbs:
  - create
  - update
  - patch

这样就能限制用户只能创建 namespace 不能删除，结合之前 abac 的功能，可以实现用户只能访问同一串 namespace 前缀的 namespace 下的内容，但是一个大的问题是，用户可以创建别的 namespace，虽然创建了后无法访问也无法删除。这个得靠 admission webhook 解决。