快捷搜索:  汽车  科技

k8s是否使用linux容器技术:一文读懂k8srbac权限验证

k8s是否使用linux容器技术:一文读懂k8srbac权限验证然后 我 就被 公司人事 开除了。我 还不能对 老板 的决定进行 反对 。2,简单抽象的概括就是:谁 是否可以对 什么东西 进行 怎么样 的访问操作。3,这样就组成了访问权限的三个重要的东西:谁 什么东西 怎么样比如: 老板 可以对 我 进行 开除 的决定。 哈哈!这个有点。。。

自我认为的k8s三大难点:权限验证,覆盖网络,各种证书。

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

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

一、前言

1,反正RBAC模型是非常牛逼的。现在运用的非常广。官方的解释是(Role-Based Access Control:基于角色的访问控制)。

2,简单抽象的概括就是: 是否可以对 什么东西 进行 怎么样 的访问操作。

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

比如: 老板 可以对 进行 开除 的决定。 哈哈!这个有点。。。

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

然后 就被 公司人事 开除了。

抱拳 抱拳 抱拳 水平有限!!!

二、RBAC组成

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

  • User(用户):每个用户都有唯一的UID识别,并被授予不同的角色
  • Role(角色):不同角色具有不同的权限
  • Permission(权限):访问权限
  • 用户-角色映射:用户和角色之间的映射关系
  • 角色-权限映射:角色和权限之间的映射

它们之间的关系如下图所示:

k8s是否使用linux容器技术:一文读懂k8srbac权限验证(1)

例如下图:

  • 管理员和普通用户被授予不同的权限
  • 普通用户只能去修改和查看个人信息
  • 而不能创建创建用户和冻结用户
  • 而管理员由于被授予所有权限,所以可以做所有操作

k8s是否使用linux容器技术:一文读懂k8srbac权限验证(2)

二、K8s RBAC

RBAC API 声明了四种 Kubernetes 对象:RoleClusterRoleRoleBindingClusterRoleBinding

你可以用kubectl get 获取到,RoleRoleBinding需要加上namespace。

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

k8s是否使用linux容器技术:一文读懂k8srbac权限验证(3)

2.1.1 Role2.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.io2.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/

感谢阅读 关注三连是最大的支持!

猜您喜欢: