Kubernetes中有很多种内置的编排对象,此外还可以自定义API资源类型和控制器的编写方式.那么,我能不能自己写一个编排对象呢?答案是肯定的.而这,也正是Kubernetes项目最具吸引力的地方.

毕竟在互联网级别的大规模集群里,Kubernetes内置的编排对象,很难做到完全满足所有需求,所以很多实际的容器化工作,都会要求设计一个自己的编排对象,实现自己的控制器模式.

所以,我们可以基于插件机制来完成这些工作,而不需要修改任何一行代码.但是,如果要通过外部插件,在Kubernetes中实现新增和操作API对象,那么就必须先了解一个非常重要的知识:RBAC.

什么是RBAC呢?我们知道,Kubernetes中所有的API对象,都保存在Etcd里,但是呢,对这些API对象的操作,却一定都是通过访问kube-apiserver来实现的.其中一个非常重要的原因,就是你需要APIServer来帮助你做授权工作.而在Kubernetes项目中,负责完成授权(Authorization)工作的机制,就是RABC:基于角色的访问控制(Role-Based Access Control).

  • 通过这篇文章,能明确三个基本的概念,就可以说收获不少了:
    • Role:角色.它其实是一组规则,定义了一组对Kubernetes API对象的操作权限
    • Subject:被作用者.既可以是"人",也可以是"机器",也可以是你在Kubernetes里定义的"用户"
    • RoleBinding:定义了"被作用者"和"角色"的绑定关系.
  • 这三个概念,可以说是整个RABC体系的核心所在.所以接下来详细讲解一下.

    Role

    Role本身就是一个Kubernetes的API对象,定义如下所示:

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

    如果对这个格式比较熟悉的话,应该能够一眼看出来:首先,这个Role对象指定了它能产生作用的Namespace是:mynamespace.

    Namespace是Kubernetes项目里的一个逻辑管理单位,不同Namespace的API对象,在通过kubectl命令进行操作的时候,是互相隔离开的.这只是逻辑上的"隔离".Namespace并不会提供任何实际的隔离或者多租户能力.

    Role对象的rules字段,就是它所定义的权限规则.在这里规则的意思就是:允许"被作用者",对mynamespace下面的Pod对象,进行GET,WATCH和LIST操作.

    那么,这个具体的"被作用者"又是如何指定的呢?这就需要通过RoleBinding来实现了.

    Subject与RoleBinding

    RoleBinding本身也是Kubernetes的API对象.定义如下:

    kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
    name: example-rolebinding
    namespace: mynamespace
    subjects:
    - kind: User
    name: example-user
    apiGroup: rbac.authorization.k8s.io
    roleRef:
    kind: Role
    name: example-role
    apiGroup: rbac.authorization.k8s.io

    由上,我们能够看到,这个RoleBinding对象里定义了一个subjects字段,即"被作用者".它的类型是User,即Kubernetes中的用户,这个用户的名字是example-user.但是,在Kubernetes中,并没有一个叫做"User"的API对象,这个User到底是从哪儿来的呢?

    实际上,Kubernetes中的"User"就是"用户",只是一个授权系统里的逻辑概念.它需要通过外部认证服务来提供,或者也可以直接给APIServer指定一个用户名,密码文件.那么Kubernetes的授权系统,就可以从这个文件里找到对应的"用户".其实在大多数私有的使用环境中,只要使用Kubernetes提供的内置"用户",就足够了.

    好像有点儿扯远了.这个等下再详细说吧.

    再往下看,能够看到roleRef字段.正是通过这个字段,RoleBinding对象就可以直接通过名字,来引用我们前面定义的Role对象(example-role),从而定义了"被作用者(Subject)"和"角色(Role)"之间的绑定关系.

    在这里需要强调一下:Role和RoleBinding对象都是Namespaced对象,它们对权限的限制规则仅在它们自己的Namespace内有效,roleRef也只能引用当前Namespace中的Role对象.

    那么,对于非Namespaced(Non-namespaced)对象(比如:Node),或者某一个Role想要作用于所有的Namespace时,我们又该怎么去做授权呢?

    这时,就必须要使用ClusterRole和ClusterRoleBinding这两个组合了.这两个API对象的用法和Role与RoleBinding完全一样,只不过它们的定义里,没有了Namespace字段.

    具体如下所示:

    kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
    name: example-clusterrole
    rules:
    - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "watch", "list"]
    kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
    name: example-clusterrolebinding
    subjects:
    - kind: User
    name: example-user
    apiGroup: rbac.authorization.k8s.io
    roleRef:
    kind: ClusterRole
    name: example-clusterrole
    apiGroup: rbac.authorization.k8s.io

    上面的例子中,意味着名叫example-user用户,拥有对所有Namespace里的Pod进行GET,WATCH和LIST操作的权限.更进一步的说,在Role或者ClusterRole里面,如果要赋予用户example-user所有权限,那么就可以给它指定一个verbs字段的全集,如下所示:

    verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

    当然,也可以根据自己的需求,只针对某一个具体的对象进行权限设置.比如:

    rules:
    - apiGroups: [""]
    resources: ["configmaps"]
    resourceNames: ["my-config"]
    verbs: ["get"]

    这个例子就表示,这条规则的"被作用者",只对名叫"my-config"的ConfigMap对象,有进行GET操作权限.

    在上面提了一下,大多数时候,我们其实都不太使用"用户"这个功能,而是直接使用Kubernetes中的"内置用户",而这个"内置用户"就是:ServiceAccount.

    ServiceAccount分配权限的过程

    通过一个实例,来讲解一下为ServiceAccount分配权限的过程.

    首先,需要定义一个ServiceAccount.它的API对象非常简单,如下所示:

    apiVersion: v1
    kind: ServiceAccount
    metadata:
    namespace: mynamespace
    name: example-sa

    可以看到,一个最简单的ServiceAccount对象,只需要Name和Namespace这两个最基本的字段.

    然后我们通过编写RoleBinding的YAML文件,来为这个ServiceAccount分配权限:

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

    接下来,我们用kubectl命令创建这三个对象:

    $ kubectl create -f svc-account.yaml
    $ kubectl create -f role-binding.yaml
    $ kubectl create -f role.yaml

    然后,来查看一下ServiceAccount的详细信息:

    $ kubectl get sa -n mynamespace -o yaml
    - apiVersion: v1
    kind: ServiceAccount
    metadata:
    creationTimestamp: 2018-09-08T12:59:17Z
    name: example-sa
    namespace: mynamespace
    resourceVersion: "409327"
    ...
    secrets:
    - name: example-sa-token-vmfg6

    可以看到,Kubernetes会为一个ServiceAccount自动创建并分配一个Secret对象.这个Secret就是这个ServiceAccount对应的,用来和APIServer进行交互的授权文件,一般称它为:Token.

    Token文件的内容一般是证书或者密码,它以一个Secret对象的方式,保存在Etcd当中.

    此时,用户的Pod就可以声明使用这个ServiceAccount了.

    对以上内容的总结

    上面内容有些多,最后来一个总结:

    所谓角色(Role),其实就是一组权限规则列表.分配这些权限的方式,就是通过创建RoleBinding对象,将被作用者(Subject)和权限列表进行绑定.

    另外,与之对应的ClusterRole和ClusterRoleBinding,则是Kubernetes集群级别的Role和RoleBinding,它们的作用范围不受Namespace限制.

    尽管权限的被作用者可以用很多种(比如,User,Group等),但在我们平常的使用中,最普遍的用法还是ServiceAccount.所以,Role+RoleBinding+ServiceAccount的权限分配方式,是最应该掌握的内容.

    以上内容来自我学习<深入剖析Kubernetes>专栏文章之后的一些见解,有偏颇之处,还望指出.

    感谢您的阅读~

    [Kubernetes]基于角色的权限控制之RBAC的更多相关文章

    1. 图文详解基于角色的权限控制模型RBAC

      我们开发一个系统,必然面临权限控制的问题,即不同的用户具有不同的访问.操作.数据权限.形成理论的权限控制模型有:自主访问控制(DAC: Discretionary Access Control).强制 ...

    2. 【Kubernetes】基于角色的权限控制:RBAC

      Kubernetes中所有的API对象,都保存在Etcd里,对这些API对象的操作,一定都是通过访问kube-apiserver实现的,原因是需要APIServer来做授权工作. 在Kubernete ...

    3. RBAC: K8s基于角色的权限控制

      文章目录 RBAC: K8s基于角色的权限控制 ServiceAccount.Role.RoleBinding Step 1:创建一个ServiceAccount,指定namespace Step 2 ...

    4. webapi框架搭建-安全机制(四)-可配置的基于角色的权限控制

      webapi框架搭建系列博客 在上一篇的webapi框架搭建-安全机制(三)-简单的基于角色的权限控制,某个角色拥有哪些接口的权限是用硬编码的方式写在接口上的,如RBAuthorize(Roles = ...

    5. webapi框架搭建-安全机制(三)-简单的基于角色的权限控制

      webapi框架搭建系列博客 上一篇已经完成了“身份验证”,如果只是想简单的实现基于角色的权限管理,我们基本上不用写代码,微软已经提供了authorize特性,直接用就行. Authorize特性的使 ...

    6. thinkphp基于角色的权限控制详解

      一.什么是RBAC 基于角色的访问控制(Role-Based Access Control)作为传统访问控制(自主访问,强制访问)的有前景的代替受到广泛的关注. 在RBAC中,权限与角色相关联,用户通 ...

    7. Django 基于角色的权限控制

      有一种场景, 要求为用户赋予一个角色, 基于角色(比如后管理员,总编, 编辑), 用户拥有相应的权限(比如管理员拥有所有权限, 总编可以增删改查, 编辑只能增改, 有些页面的按钮也只有某些角色才能查看 ...

    8. IdentityServer4实战 - 基于角色的权限控制及Claim详解

      一.前言 大家好,许久没有更新博客了,最近从重庆来到了成都,换了个工作环境,前面都比较忙没有什么时间,这次趁着清明假期有时间,又可以分享一些知识给大家.在QQ群里有许多人都问过IdentityServ ...

    9. RBAC - 基于角色的权限控制

      ThinkPHP中关于RBAC使用详解 自己的源码下载:百度网盘,thinkPHP文件夹下,RBAC文件夹. 重要的是,权限信息的写入函数等.在源码中能找到,Modules/Amin/Common/c ...

    随机推荐

    1. 三十九、vue中element最原始的分页(未封装的)

      html<el-table ref="scoreUserTable" :data="scorePageUser.slice((currentPage1-1)*pag ...

    2. [题解]图的m着色问题

      图的m着色问题(color) [题目描述] 给定无向连通图G和m种不同的颜色.用这些颜色为图G的各顶点着色,每个顶点着一种颜色.如果有一种着色法使G中每条边的2个顶点着不同颜色,则称这个图是m可着色的 ...

    3. HTML之表单

      目录 表单的结构 get方式与post方式 输入 单行文本输入框 提交按钮和重置按钮 密码输入框 复选框 单选按钮 图像按钮 文本选择输入框 隐藏框 多行文本输入框 下拉列表框 新增输入元素 新增其他 ...

    4. 美化ubuntu18.04,并安装搜狗输入法

      目录 美化Ubuntu 下载主题和图标文件 下载GNOME3 美化过程 安装输入法 下载并安装搜狗输入法 安装fcitx框架 安装过程 美化Ubuntu 下载主题和图标文件 下载地址:https:// ...

    5. Java Web的简单项目部署

      目录 项目介绍 安装并配置jdk和tomcat 安装并配置mysql 使用Eclipse导出war包 部署war包到服务器 导出项目的数据库 将项目的数据库导入服务器的数据库中 修改配置 重启Tomc ...

    6. Windows下安装配置MongoDB

      Windows下安装配置MongoDB 一,介绍 MongoDB 是由C++语言编写的,是一个基于分布式文件存储的开源数据库系统.在高负载的情况下,添加更多的节点,可以保证服务器性能. MongoDB ...

    7. [转帖]Windows 上面IE的历史

      微软向Chrome举手投降 这么多代IE你都用过吗 2019年04月20日 18:48 4030 次阅读 稿源:太平洋电脑网 2 条评论 这个清明假节,很多人过得波澜不惊,然而一个曾被万千网民挂在口中 ...

    8. JQ倒计时,正计时

      <p class="lastP">距离二维码过期还剩<strong></strong>秒,过期后自动刷新页面.</p><scr ...

    9. 利用控制台承载SignalR作为服务端、及第三方推送信息

      一 首先建立一个控制台需要引用一些组件 特别要注意引用Microsoft.Owin.Host.HttpListener别忘了这个组件,不引用他可能程序正常运行不会报错,但服务器一直开启失败(我之前就是 ...

    10. mysql-笔记-numberic 方法 操作符

      DIV 整数除法---结果舍去小数部分, /除法 ---除以0时返回 null值 -减法 % MOD 取模 ---结果为 余数 也可以用于有小数部分的数返回余数,mod(N,0)返回null值 + 加 ...