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

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

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

一、前言

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

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

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

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

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

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

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

二、RBAC组成

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

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

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

例如下图:

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

二、K8s RBAC

RBAC API 声明了四种 Kubernetes 对象:RoleClusterRoleRoleBinding 和 ClusterRoleBinding

你可以用kubectl  get  获取到,RoleRoleBinding需要加上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

一文读懂k8s rbac 权限验证的更多相关文章

  1. kubernetes基础——一文读懂k8s

    容器 容器与虚拟机对比图(左边为容器.右边为虚拟机)   容器技术是虚拟化技术的一种,以Docker为例,Docker利用Linux的LXC(LinuX Containers)技术.CGroup(Co ...

  2. 一文读懂k8s之Pod安全策略

    导读 Pod容器想要获取集群的资源信息,需要配置角色和ServiceAccount进行授权.为了更精细地控制Pod对资源的使用方式,Kubernetes从1.4版本开始引入了PodSecurityPo ...

  3. [转帖]MerkleDAG全面解析 一文读懂什么是默克尔有向无环图

    MerkleDAG全面解析 一文读懂什么是默克尔有向无环图 2018-08-16 15:58区块链/技术 MerkleDAG作为IPFS的核心数据结构,它融合了Merkle Tree和DAG的优点,今 ...

  4. 一文读懂HTTP/2及HTTP/3特性

    摘要: 学习 HTTP/2 与 HTTP/3. 前言 HTTP/2 相比于 HTTP/1,可以说是大幅度提高了网页的性能,只需要升级到该协议就可以减少很多之前需要做的性能优化工作,当然兼容问题以及如何 ...

  5. 从HTTP/0.9到HTTP/2:一文读懂HTTP协议的历史演变和设计思路

    本文原作者阮一峰,作者博客:ruanyifeng.com. 1.引言 HTTP 协议是最重要的互联网基础协议之一,它从最初的仅为浏览网页的目的进化到现在,已经是短连接通信的事实工业标准,最新版本 HT ...

  6. [转帖]从HTTP/0.9到HTTP/2:一文读懂HTTP协议的历史演变和设计思路

    从HTTP/0.9到HTTP/2:一文读懂HTTP协议的历史演变和设计思路   http://www.52im.net/thread-1709-1-2.html     本文原作者阮一峰,作者博客:r ...

  7. 【FIORI系列】SAP 一文读懂SAP Fiori是什么

    公众号:SAP Technical 本文作者:matinal 原文出处:http://www.cnblogs.com/SAPmatinal/ 原文链接:[FIORI系列]SAP 一文读懂SAP Fio ...

  8. 一文读懂对抗生成学习(Generative Adversarial Nets)[GAN]

    一文读懂对抗生成学习(Generative Adversarial Nets)[GAN] 0x00 推荐论文 https://arxiv.org/pdf/1406.2661.pdf 0x01什么是ga ...

  9. 大数据篇:一文读懂@数据仓库(PPT文字版)

    大数据篇:一文读懂@数据仓库 1 网络词汇总结 1.1 数据中台 数据中台是聚合和治理跨域数据,将数据抽象封装成服务,提供给前台以业务价值的逻辑概念. 数据中台是一套可持续"让企业的数据用起 ...

随机推荐

  1. java enum(枚举)的使用

    在实际编程中,往往存在着这样的“数据集”,它们的数值在程序中是稳定的,而且“数据集”中的元素是有限的. 例如星期一到星期日七个数据元素组成了一周的“数据集”,春夏秋冬四个数据元素组成了四季的“数据集” ...

  2. Nagios监控ganglia的指标

    这是nagios与ganglia整合的一部分内容 . 通常我们会把ganglia的监控发送给一个主机,我们可以在这个主机上执行nc localhost 8649 可以获取到所有发往这个主机的信息,以x ...

  3. webApp前端开发技巧总结

    自Iphone和Android这两个牛逼的手机操作系统发布以来,在互联网界从此就多了一个新的名词-WebApp(意为基于WEB形式的应用程序,运行在高端的移动终端设备.我相信各位童鞋应该和我一个样子, ...

  4. Entity Framework 第九篇 关于自增列的事务处理

    如果一个表带有自增列的,那么在事务处理的过程中,如果抑制了提交,自增的序号就不会得到,如果我们需要得到那怎么办呢?可以临时提交,但是既然提交了就要考虑到事务回滚,否则无法满足数据的一致性 public ...

  5. WCF学习系列二_使用IIS发布WCF服务

    原创作者:灰灰虫的家http://hi.baidu.com/grayworm 上一篇中,我们创建了一个简单的WCF服务,在测试的时候,我们使用VS2008自带的WCFSVCHost(WCF服务主机)发 ...

  6. HDU1865--More is better(统计并查集的秩(元素个数))

    More is better Time Limit: 5000/1000 MS (Java/Others)    Memory Limit: 327680/102400 K (Java/Others) ...

  7. HttpClient(一)HttpClient抓取网页基本信息

    一.HttpClient简介 HttpClient 是 Apache Jakarta Common 下的子项目,可以用来提供高效的.最新的.功能丰富的支持 HTTP 协议的客户端编程工具包, 并且它支 ...

  8. ueditor表格边框没有颜色的解决

    问题: 用ueditor画表格,会发现表格存在,但是表格边框没有颜色. 解决方法: 需要对js文件中的样式进行修改,这里我引用的编辑器样式文件是ueditor.all.min.js,所以先找到该文件, ...

  9. PRML1-引言

    本系列是根据<pattern recognition and machine learning>一书写的,算是读书笔记?算是吧.因为是从自己角度出发,所以其实很大程度上自己看得懂,估计别人 ...

  10. 使用Axure RP原型设计实践04,了解全局变量

    变量是一个可以变的数,可以看作是一个数据的容器.变量有2个操作,一个是读,一个是写.Axure的全局变量是指任何时候都可以对这个变量进行读写操作. 点击工具栏Project下的Global Varia ...