kubernetes实战(八):k8s集群安全机制RBAC
1、基本概念
RBAC(Role-Based Access Control,基于角色的访问控制)在k8s v1.5中引入,在v1.6版本时升级为Beta版本,并成为kubeadm安装方式下的默认选项,相对于其他访问控制方式,新的RBAC具有如下优势:
- 对集群中的资源和非资源权限均有完整的覆盖
整个RBAC完全由几个API对象完成,同其他API对象一样,可以用kubectl或API进行操作
可以在运行时进行调整,无需重启API Server
要使用RBAC授权模式,需要在API Server的启动参数中加上--authorization-mode=RBAC
2、RBAC原理和用法
2.1 RBAC的API资源对象说明
RBAC引入了4个新的顶级资源对象:Role、ClusterRole、RoleBinding、ClusterRoleBinding。同其他API资源对象一样,用户可以使用kubectl或者API调用等方式操作这些资源对象。
- 角色(Role)
一个角色就是一组权限的集合,这里的权限都是许可形式的,不存在拒绝的规则。在一个命名空间中,可以用角色来定义一个角色,如果是集群级别的,就需要使用ClusterRole了。
角色只能对命名空间内的资源进行授权,下面的例子中定义的角色具备读取Pod的权限:
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: default
name: pod-reader rules:
- apiGroups: [""] # 空字符串表示核心API群
resource: ["pods"]
verbs: ["get", "watch", "list"]
rules中的参数说明:
- apiGroup:支持的API组列表,例如:APIVersion: batch/v1、APIVersion: extensions:v1、apiVersion:apps/v1等
resources:支持的资源对象列表,例如:pods、deployments、jobs等
verbs:对资源对象的操作方法列表,例如:get、watch、list、delete、replace、patch等
- 集群角色(ClusterRole)
集群角色除了具有和角色一致的命名空间内资源的管理能力,因其集群级别的范围,还可以用于以下特殊元素的授权。
- 集群范围的资源,例如Node
非资源型的路径,例如/healthz
包含全部命名空间的资源,例如pods
下面的集群角色可以让用户有权访问任意一个或所有命名空间的secrets:
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
# name: secret-reader
# ClusterRole不受限于命名空间,所以省略了namespace name的定义 rules:
- apiGroups: [""]
resources: ["secrets"]
verbs: ["get", "watch", "list"]
- 角色绑定(RoleBinding)和集群角色绑定(ClusterRoleBinding)
角色绑定或集群角色绑定用来把一个角色绑定到一个目标上,绑定目标可以是User、Group或者Service Account。使用RoleBinding为某个命名空间授权,ClusterRoleBinding为集群范围内授权。
RoleBinding可以引用Role进行授权,下例中的RoleBinding将在default命名空间中把pod-reader角色授予用户jane,可以让jane用户读取default命名空间的Pod:
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: read-pods
namespace: default subjects:
- kind: User
name: jane
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
RoleBinding也可以引用ClusterRole,对属于同一命名空间内ClusterRole定义的资源主体进行授权。一种常见的做法是集群管理员为集群范围预先定义好一组角色(ClusterRole),然后在多个命名空间中重复使用这些ClusterRole。
使用RoleBinding绑定集群角色secret-reader,使dave只能读取development命名空间中的secret:
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: read-secrets
namespace: development subjects:
- kind: User
name: dave
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io
集群角色绑定中的角色只能是集群角色,用于进行集群级别或者对所有命名空间都生效的授权。
允许manager组的用户读取任意namespace中的secret
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: read-secrets-global
subjects:
- kind: Group
name: manager
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: ClusterRole
name: secret-reader
apiGroup: rbac.authorization.k8s.io
2.2 对资源的引用方式
多数资源可以用其名称的字符串来表达,也就是Endpoint中的URL相对路径,例如pods。然后,某些Kubernetes API包含下级资源,例如Pod的日志(logs)。Pod日志的Endpoint是GET /api/v1/namespaces/{namespaces}/pods/{name}/log。
Pod是一个命名空间内的资源,log就是一个下级资源。要在一个RBAC角色中体现,则需要用斜线/来分割资源和下级资源。若想授权让某个主体同时能够读取Pod和Pod log,则可以配置resources为一个数组:
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: default
name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
resources: ["pods", "pods/log"]
verbs: ["get", "list"]
资源还可以通过名字(ResourceName)进行引用。在指定ResourceName后,使用get、delete、update、patch动词的请求,就会被限制在这个资源实例范围内。例如下面的声明让一个主体只能对一个叫my-configmap的configmap进行get和update操作:
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
namespace: default
name: configmap-updater
rules:
- apiGroups: [""]
resources: ["configmap"]
resourceNames: ["my-configmap"]
verbs: ["update", "get"]
2.3 常见的角色(Role)示例
- 允许读取核心API组中Pod的资源:
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
- 允许读写"extensions"和"apps"两个API组中的deployment资源
rules:
- apiGroups: ["extensions", "apps"]
resources: ["deployments"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- 允许读写pods及读写jobs
rules:
- apiGroups: [""]
resources: ["pods"]
verbs: ["get", "list", "watch"]
- apiGroups: ["batch", "extensions"]
resources: ["jobs"]
verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]
- 允许读取一个名为my-config的ConfigMap(必须绑定到一个RoleBinding来限制到一个namespace下的ConfigMap):
rules:
- apiGroups: [""]
resources: ["configmaps"]
resourceNames: ["my-config"]
verbs: ["get"]
- 读取核心组的node资源(Node属于集群级别的资源,必须放在ClusterRole中,并使用ClusterRoleBinding进行绑定):
rules:
- apiGroups: [""]
resources: ["nodes"]
verbs: ["get", "list", "watch"]
- 允许对非资源端点/healthz及其所有子路径进行GET/POST操作(必须使用ClusterRole和ClusterRoleBinding):
rules:
- nonResourceURLs: ["/healthz", "/healthz/*"]
verbs: ["get", "post"]
2.4 常用的角色绑定
- 用户名Alice@example.com
subjects:
- kind: User
name: "Alice@example.com"
apiGroup: rbac.authorization.k8s.io
- 组名frontend-admins
subjects:
- kind: Group
name: "frontend-admins"
apiGroup: rbac.authorization.k8s.io
- kube-system命名空间中的默认Service Account
subjects:
- kind: ServiceAccount
name: default
namespace: kube-system
- qa命名空间中的所有Service Account
subjects:
- kind: Group
name: system:serviceaccounts:qa
apiGroup: rbac.authorization.k8s.io
- 所有Service Account
subjects:
- kind: Group
name: system:serviceaccounts
apiGroup: rbac.authorization.k8s.io
- 所有认证用户
subjects:
- kind: Group
name: system:authentication
apiGroup: rbac.authorization.k8s.io
- 所有未认证用户
subjects:
- kind: Group
name: system:unauthentication
apiGroup: rbac.authorization.k8s.io
- 全部用户
subjects:
- kind: Group
name: system:authentication
apiGroup: rbac.authorization.k8s.io
- kind: Group
name: system:unauthentication
apiGroup: rbac.authorization.k8s.io
2.5 默认的角色和角色绑定
API Server会创建一套默认的ClusterRole和ClusterRoleBinding对象,其中很多是以system:为前缀的,以表明这些资源属于基础架构,对这些对象的改动可能造成集群故障。
所有默认的ClusterRole和RoleBinding都会用标签kubernetes.io/bootstrapping=rbac-defaults进行标记。
常见的系统角色如下:
有些默认角色不是以system:为前缀的,这部分角色是针对用户的,其中包含超级用户角色cluster-admin,有的用于集群一级的角色cluster-status,还有针对namespace的角色admin、edit、view
常见的用户角色如下:
- 核心Master组件角色
2.6 授权注意事项:预防提权和授权初始化
RBAC API拒绝用户利用编辑角色或者角色绑定的方式进行提权。这一限制是在API层面做出的,因此即使RBAC没有启用也仍然有效。
用户只能在拥有一个角色的所有权限,且与该角色的生效范围一致的前提下,才能对角色进行创建和更新。例如用户user-1没有列出集群中所有secret的权限,就不能创建具有这一权限的集群角色。要让一个用户能够创建或更新角色,需要以下权限:
- 为其授予一个允许创建/更新Role或ClusterRole资源对象的角色;
为用户授予角色,要覆盖该用户所能控制的所有权限范围。用户如果尝试创建超出其自身权限的角色或者集群角色,则该API调用会被禁止。
如果一个用户的权限包含了一个角色的所有权限,那么就可以为其创建和更新角色绑定;或者如果被授予了针对某个角色的绑定授权,则也有权完成此操作。
例如:user1没有列出集群内所有secret的权限,就无法为一个具有这样权限的角色创建集群角色绑定。要使用户能够创建、更新这一角色绑定,则需要有如下做法:
- 为其授予一个允许创建和更新角色绑定或者集群角色绑定的角色
为其授予绑定某一角色的权限,有隐式或显式两种方法
- 隐式:让其具有所有该角色的权限
- 显式:让用户授予针对该角色或集群角色绑定操作的权限
让user-1有对user-1-namespace命名空间中的其他用户授予admin、edit及view角色
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: role-grantor
rules:
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["rolebindings"]
verbs: ["create"]
- apiGroups: ["rbac.authorization.k8s.io"]
resources: ["clusterroles"]
verbs: ["bind"]
resourceNames: ["admin", "edit", "view"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: role-grantor-binding
namespace: user--namespace
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: role-grantor
subjects:
- apiGroup: rbac.authorization.k8s.io
kind: User
name: user-
在进行第一个角色和角色绑定时,必须让初始用户具备其尚未被授予的权限,要进行初始的角色和角色绑定设置,有以下两种方法:
- 使用属于system:masters组的身份,这一群组默认具有cluster-admin这一超级角色的绑定。
如果API Server以--insecure-port参数运行,则客户端通过这个非安全端口进行接口调用,这一端口没有认证鉴权的限制。
赞助作者:
kubernetes实战(八):k8s集群安全机制RBAC的更多相关文章
- kubernetes(k8s)集群安全机制RBAC
1.基本概念 RBAC(Role-Based Access Control,基于角色的访问控制)在k8s v1.5中引入,在v1.6版本时升级为Beta版本,并成为kubeadm安装方式下的默认选项, ...
- 一键运行CIS安全扫描,集群安全无忧!
CIS安全扫描是Rancher 2.4推出的其中一个重磅功能,旨在帮助用户快速.有效地加强集群的安全性.本文将详细介绍CIS安全扫描这一功能,包含详细的操作demo. 本文来自Rancher Labs ...
- Kubernetes-深入分析集群安全机制
Kubernetes过一系列机制来实现集群的安全机制,包括API Server的认证授权.准入控制机制及保护敏感信息的Secret机制等.集群的安全性必须考虑以下的几个目标: 保证容器与其所在宿主机的 ...
- Apache-Shiro+Zookeeper系统集群安全解决方案之缓存管理
上篇[Apache-Shiro+Zookeeper系统集群安全解决方案之会话管理],解决了Shiro在系统集群开发时安全的会话共享问题,系统在使用过程中会有大量的权限检查和用户身份检验动作,为了不频繁 ...
- (二)Kubernetes kubeadm部署k8s集群
kubeadm介绍 kubeadm是Kubernetes项目自带的及集群构建工具,负责执行构建一个最小化的可用集群以及将其启动等的必要基本步骤,kubeadm是Kubernetes集群全生命周期的管理 ...
- [k8s]jenkins配合kubernetes插件实现k8s集群构建的持续集成
另一个结合harbor自动构建镜像的思路: 即code+baseimage一体的方案 - 程序员将代码提交到代码仓库gitlab - 钩子触发jenkins master启动一次构建 - jenkin ...
- Kubernetes实战 高可用集群搭建,配置,运维与应用
1-1 K8S导学 1-2 搭建K8S集群步骤和要点介绍 1-3 搭建三节点Ubuntu环境 1-4 安装容器引擎 1-5 下载Kubeadm.node组件和命令行工具 1-6 向集群中加入worke ...
- K8s集群认证之RBAC
kubernetes认证,授权概括总结: RBAC简明总结摘要:API Server认证授权过程: subject(主体)----->认证----->授权[action(可做什么)]--- ...
- 十二,k8s集群访问控制之RBAC授权
目录 角色访问控制RBAC (Role-Based Access Control) 常用的授权插件: RBAC控制: role 和 clusterrole rolebinding 和 clusterr ...
随机推荐
- 基于.Net实现前端对话框和消息框
关于前端对话框.消息框的优秀插件多不胜数.造轮子是为了更好的使用轮子,并不是说自己造的轮子肯定好.所以,这个博客系统基本上都是自己实现的,包括日志记录.响应式布局等等一些本可以使用插件的.好了,废话不 ...
- Unity工程3D和2D开发模式切换
在新建工程时,经常会选择默认的3D工程,但是如果想做2D游戏又不小心选了3D工程呢,总不能把工程删了重新建吧,有个办法就是打开 Edit > Project Settings > Edit ...
- Navicat for Mysql 如何备份数据库
Navicat for Mysql 如何备份数据库 打开界面如下 打开自己的的数据库 点击需要备份的数据库名 未完!!! 文章来自:http://jingyan.baidu.com/article/f ...
- [转]ASP.NET MVC 5 - 添加一个模型
在本节中,您将添加一些类,这些类用于管理数据库中的电影.这些类是ASP.NET MVC 应用程序中的"模型(Model)". 您将使用.NET Framework 数据访问技术En ...
- 【RF库Collections测试】Set To Dictionary
Name:Set To DictionarySource:Collections <test library>Arguments:[ dictionary | *key_value_pai ...
- 实例:用类来写一个 memcached 启动脚本
[root@localhost ~]$ yum install -y memcached #!/usr/bin/env python #-*- coding:utf-8 -*- import os i ...
- divmod()
divmod() 接收两个数值,然后以元组的形式返回这两个数值的商和余数 In [1]: divmod(5, 2) Out[1]: (2, 1) In [2]: divmod(10, 7) Out[2 ...
- jquery单选框radio绑定click事件实现和是否选中的方法
使用jquery获取radio的值,最重要的是掌握jquery选择器的使用,在一个表单中我们通常是要获取被选中的那个radio项的值,所以要加checked来筛选,比如有以下的一些radio项: 1. ...
- poj_1475 BFS+BFS
题目大意 推箱子游戏的基本玩法,求将箱子推到目的地的推动次数最少(并不是人移动总次数)的人移动路径. 题目分析 求最短路径的搜索问题,使用BFS.注意题目求的是 推动次数最少,因此将箱子移动作为状态, ...
- Window PHP 使用命令行模式
电脑系统: win7 php环境: phpstudy 1 把php目录放到环境变量path下面: 我的电脑->属性->高级->环境变量->系统变量->Path->编 ...