一文读懂k8s rbac 权限验证

自我认为的k8s三大难点：权限验证，覆盖网络，各类证书。

 

今天就说一下我所理解的权限验证rbac。

 

咱不说rbac0，rbac1，rbac2，rbac3。咱就说怎么控制权限就行。

 

 

1、前言

1，反正RBAC模型是很是牛逼的。如今运用的很是广。官方的解释是（Role-Based Access Control：基于角色的访问控制）。

2，简单抽象的归纳就是：谁 是否能够对 什么东西 进行 怎么样 的访问操做。

3，这样就组成了访问权限的三个重要的东西：谁    什么东西    怎么样

 

好比：    老板 能够对 我 进行 开除 的决定。    哈哈！这个有点。。。

                 我 还不能对 老板 的决定进行 反对 。

                 而后 我 就被 公司人事 开除了。

 

抱拳  抱拳  抱拳    水平有限！！！

 

 

2、RBAC组成

 

在RBAC模型里面，有3个基础组成部分，分别是：用户、角色和权限。

 

• User（用户）：每一个用户都有惟一的UID识别，并被授予不一样的角色
• Role（角色）：不一样角色具备不一样的权限
• Permission（权限）：访问权限
• 用户-角色映射：用户和角色之间的映射关系
• 角色-权限映射：角色和权限之间的映射

 

它们之间的关系以下图所示：

 

 

例以下图：

• 管理员和普通用户被授予不一样的权限
• 普通用户只能去修改和查看我的信息
• 而不能建立建立用户和冻结用户
• 而管理员因为被授予全部权限，因此能够作全部操做

 

 

2、K8s RBAC

 

RBAC API 声明了四种 Kubernetes 对象：Role、ClusterRole、RoleBinding 和 ClusterRoleBinding。

你能够用kubectl  get  获取到，Role、RoleBinding须要加上namespace。

咱们先上一张图，我们围绕这张图解释。

 

接下来咱们一个一个的说。

 

 

2.1 Role 和 ClusterRole

role和ClusterRole能够看作是一个角色。

好比：

领导和员工是两个不一样的角色

资源就是一只笔

操做就是签字

那么领导和员工两个不一样的角色所签下去的字的 效果就不同了。这就是角色所带来的不一样权限。

 

 

2.1.1 Role

Role 就是用来在某一个namespace内设置访问权限。建立Role的时候，必须指定namespaces。

下面是一个位于 "default" 名字空间的 Role 的示例，可用来授予对 pods 的读访问权限：

apiVersion: rbac.authorization.k8s.io/v1         # api
kind: Role              # 资源名称
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]        # apiGroups 就是api资源组，你kubectl get apiservice 就能够看到集群全部的api组
  resources: ["pods"]    # 就是k8s资源的名称。kubectl api-resources 这个命令能够查看到，第一列是资源名称，就是能够写在这里的。
                         # 第二列是简写，kubectl get 后面的能够简写。
                         # 第三列是APIGROUP组
                         # 第四列是是否属于NAMESPACED资源，就是你能够在ns下面看到的资源
                         # 第五列是kind的时候写的名称
                         # 资源还分子资源，后期会写一篇专门的文章介绍
  verbs: ["get", "watch", "list"]    # 定义动做，get是查看权限，update是更新权限。。。

 

 

2.1.2 ClusterRole

ClusterRole 就是用来在集群内设置访问权限。ClusterRole不用固定在一个namespaces。

这两种资源的名字不一样（Role 和 ClusterRole）是由于 Kubernetes 对象要么是namespaces做用域的，要么是集群做用域的， 不可二者兼具。

下面是一个 ClusterRole 的示例，可用来为任一特定名字空间中的 Secret 授予读访问权限， 或者跨名字空间的访问权限（取决于该角色是如何绑定的）：

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" 被忽略，由于 ClusterRoles 不受名字空间限制
  name: secret-reader
rules:
- apiGroups: [""]
  # 在 HTTP 层面，用来访问 Secret 对象的资源的名称为 "secrets"
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

 

 

2.2 、RoleBinding 和 ClusterRoleBinding

RoleBinding 和 ClusterRoleBinding 是用来 把用户和角色关联起来的。

角色绑定（Role Binding）是将角色中定义的权限赋予一个或者一组用户。

它包含若干 主体（用户、组或服务帐户）的列表和对这些主体所得到的角色的引用。

RoleBinding 在指定的名字空间中执行受权，而 ClusterRoleBinding 在集群范围执行受权。

 

 

2.2.1 RoleBinding

一个 RoleBinding 能够绑定同一的namespaces中的任何 一个Role。

或者，一个 RoleBinding 能够引用某 ClusterRole ，并将该 ClusterRole 绑定到 RoleBinding 所在的namespaces。

 

下面的例子中的 RoleBinding 将 "pod-reader" Role 授予在 "default" 名字空间中的用户 "jane"。

这样，用户 "jane" 就具备了读取 "default" 名字空间中 pods 的权限。

apiVersion: rbac.authorization.k8s.io/v1
# 此角色绑定容许 "jane" 读取 "default" 名字空间中的 Pods
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
# 你能够指定不止一个“subject（主体）”
- kind: User
  name: jane # "name" 是不区分大小写的
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" 指定与某 Role 或 ClusterRole 的绑定关系
  kind: Role # 此字段必须是 Role 或 ClusterRole
  name: pod-reader     # 此字段必须与你要绑定的 Role 或 ClusterRole 的名称匹配
  apiGroup: rbac.authorization.k8s.io

 

RoleBinding 也能够引用 ClusterRole，以将对应 ClusterRole 中定义的访问权限授予 RoleBinding 所在名字空间的资源。

这种引用使得你能够跨整个集群定义一组通用的角色， 以后在多个名字空间中复用。

 

例如，尽管下面的 RoleBinding 引用的是一个 ClusterRole，

"dave"（这里的主体， 不区分大小写）只能访问 "development" 名字空间中的 Secrets 对象，

由于 RoleBinding 所在的名字空间（由其 metadata 决定）是 "development"。

apiVersion: rbac.authorization.k8s.io/v1
# 此角色绑定使得用户 "dave" 可以读取 "development" 名字空间中的 Secrets
# 你须要一个名为 "secret-reader" 的 ClusterRole
kind: RoleBinding
metadata:
  name: read-secrets
  # RoleBinding 的名字空间决定了访问权限的授予范围。
  # 这里隐含受权仅在 "development" 名字空间内的访问权限。
  namespace: development
subjects:
- kind: User
  name: dave # 'name' 是不区分大小写的
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

 

 

2.2.2 ClusterRoleBinding

若是你但愿将某 ClusterRole 绑定到集群中全部名字空间，你要使用 ClusterRoleBinding。

 

 要跨整个集群完成访问权限的授予，你可使用一个 ClusterRoleBinding。

下面的 ClusterRoleBinding 容许 "manager" 组内的全部用户访问任何名字空间中的 Secrets。

apiVersion: rbac.authorization.k8s.io/v1
# 此集群角色绑定容许 “manager” 组中的任何人访问任何名字空间中的 secrets
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager # 'name' 是不区分大小写的
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

 

 

 

其实关于k8s rbac还有不少须要注意的地方，

你们能够仔细的把官方文档读一遍。

读完了其实你对k8s 的rbac的理解就已经很是厉害了。

官方地址：https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac/

 

你们能够参考个人另外一篇文档，实际运用了一下k8s rbac：https://www.cnblogs.com/fanfanfanlichun/p/14989454.html