k8s结合jumpserver做kubectl权限控制 用户在多个namespaces的访问权限 rbac权限控制
圈子太小,做人留一面,日后好相见。
其实这个文章就是用户用jumpserver登录到k8s master节点
然后执行kubectl的时候只有自己namespaces的所有权限。
背景
1,k8s 有一天突然kubectl 执行任何命令都报权限不对。
2,最后查明是因为有一个开发不小心把admin的ClusterRoleBinding给删除了。
3,jumpserver给所有开发的权限都是同一个普通用户。
4,因为我们是一个k8s集群,然后用不同的namespaces区分不同的业务小组。每个小组有固定的node机器。
5,kubectl 的配置文件都是用的同一个,权限也是admin的。
要求
1,领导要求业务小组只有自己namespaces的权限。
2,业务小组不能有一个集群的大的权限,比如删除node,不能更新master node的一些信息。
总体思路
1,在jumpserver上面新建各业务方系统用户。
2,把系统用户绑定给各业务方用户组。(关于Jumpserver 系统用户和管理用户介绍,后期出一篇单独的文章。)
3,在k8s master1节点上面的各个业务方系统用户家目录下面 新建不同的.kube/config文件。
一、.kube/config 文件生成
1,这里我就用我这边的需求写了,有关于k8s rbac的分享,我在后期会写一篇单独的文章。
2,业务方有:axer,paas。这是我公司这边的两个业务方。
3,其实k8s的rbac确实非常的复杂,难理解,实现权限划分的方式
1.1 权限划分思路
1,首先是各种资源的权限,k8s资源又分两种,一种是集群的资源,一种是ns资源。
2,然后是将权限和谁绑定起来。 大概就是两步:权限和绑定权限。
3,我这里是用了两个ClusterRole,一个是集群的资源的权限,一个是ns资源的权限
4,我选择的是sa来做授权的对象。然后用这个sa的token去做kubectl的权限验证
5,多个RoleBinding,每一个RoleBinding把ns的资源权限固定在一个ns里面。你想要这个sa有哪些ns的权限,就写几个RoleBinding。
6,一个ClusterRoleBinding,用于绑定sa对集群资源的权限。
1.2 创建ClusterRole
1.2.1 集群资源权限
也就是说整个k8s集群的一些权限。比如:get ns,get node,get node status,git ns status......
# 其实这里就是设置对k8s集群的一些权限的
apiVersion: rbac.authorization.k8s.io/v1 # api
kind: ClusterRole # 资源类型
metadata: # 元数据 ClusterRole 不受ns的限制,所以不用写ns
name: business-axer-get-auth # ClusterRole 的名称,能区分就行
rules:
- apiGroups: # apiGroups 就是api资源组,你kubectl get apiservice 就可以看到集群所有的api组
- "" # 我这里代表为空,就是api组里面有一个v1. 这样的
resources: # 就是k8s资源的名称。kubectl api-resources 这个命令可以查看到,第一列是资源名称,就是可以写在这里的。
# 第二列是简写,kubectl get 后面的可以简写。
# 第三列是APIGROUP组
# 第四列是是否属于NAMESPACED资源,就是你可以在ns下面看到的资源
# 第五列是kind的时候写的名称
# 资源还分子资源,后期会写一篇专门的文章介绍
- namespaces/status # 这个是ns状态
- namespaces # 这个是ns
- persistentvolumes # pv
verbs: # verbs是定义动作的
- get # 就是可以查看ns的权限
- list
- watch
- apiGroups:
- ""
resources: # 这里定义的是可以查看node的权限,更新node的权限。
- nodes
- nodes/status
verbs:
- get
- list
- watch
- patch
- update
- apiGroups:
- "storage.k8s.io"
resources: # 这里定义的是可以查看sc的权限,因为我们有后端的存储集群,他们可以对sc的所有权限
- storageclasses
- storageclasses/status
resourceNames: # 因为sc属于集群资源,不同的业务方需要对自己的sc才有 全部权限。
- axersc # 所有这里可以指定对哪一个sc有全部权限
verbs:
- create
- delete
- deletecollection
- get
- list
- patch
- update
- watch
1.2.2 ns资源权限
就是定义业务方对自己ns的所有权限,自己的ns里面的所有资源都要有权限。
点击查看代码
点击查看代码
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: business-axer-admin-auth
rules:
- apiGroups:
- ""
resources: # 对pod的一些权限。
- pods/attach
- pods/exec # exec pod
- pods/portforward # 设置pod的转发
- pods/proxy
- secrets # secrets的权限
- services/proxy
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- serviceaccounts # sa的权限
verbs:
- impersonate
- apiGroups:
- ""
resources:
- pods
- pods/attach
- pods/exec
- pods/portforward
- pods/proxy
verbs:
- create
- delete
- deletecollection
- patch
- update
- apiGroups:
- ""
resources:
- configmaps
- endpoints
- persistentvolumeclaims
- replicationcontrollers
- replicationcontrollers/scale
- secrets
- serviceaccounts
- services
- services/proxy
verbs:
- create
- delete
- deletecollection
- patch
- update
- apiGroups:
- apps
resources:
- daemonsets
- deployments
- deployments/rollback
- deployments/scale
- replicasets
- replicasets/scale
- statefulsets
- statefulsets/scale
verbs:
- create
- delete
- deletecollection
- patch
- update
- apiGroups:
- autoscaling
resources:
- horizontalpodautoscalers
verbs:
- create
- delete
- deletecollection
- patch
- update
- apiGroups:
- batch
resources:
- cronjobs
- jobs
verbs:
- create
- delete
- deletecollection
- patch
- update
- apiGroups:
- extensions
resources:
- daemonsets
- deployments
- deployments/rollback
- deployments/scale
- ingresses
- networkpolicies
- replicasets
- replicasets/scale
- replicationcontrollers/scale
verbs:
- create
- delete
- deletecollection
- patch
- update
- apiGroups:
- policy
resources:
- poddisruptionbudgets
verbs:
- create
- delete
- deletecollection
- patch
- update
- apiGroups:
- networking.k8s.io
resources:
- ingresses
- networkpolicies
verbs:
- create
- delete
- deletecollection
- patch
- update
- apiGroups:
- metrics.k8s.io
resources:
- pods
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- configmaps
- endpoints
- persistentvolumeclaims
- pods
- replicationcontrollers
- replicationcontrollers/scale
- serviceaccounts
- services
verbs:
- get
- list
- watch
- apiGroups:
- ""
resources:
- bindings
- events
- limitranges
- pods/log
- pods/status
- replicationcontrollers/status
- resourcequotas
- resourcequotas/status
verbs:
- get
- list
- watch
- apiGroups:
- apps
resources:
- controllerrevisions
- daemonsets
- deployments
- deployments/scale
- replicasets
- replicasets/scale
- statefulsets
- statefulsets/scale
verbs:
- get
- list
- watch
- apiGroups:
- autoscaling
resources:
- horizontalpodautoscalers
verbs:
- get
- list
- watch
- apiGroups:
- batch
resources:
- cronjobs
- jobs
verbs:
- get
- list
- watch
- apiGroups:
- extensions
resources:
- daemonsets
- deployments
- deployments/scale
- ingresses
- networkpolicies
- replicasets
- replicasets/scale
- replicationcontrollers/scale
verbs:
- get
- list
- watch
- apiGroups:
- policy
resources:
- poddisruptionbudgets
verbs:
- get
- list
- watch
- apiGroups:
- networking.k8s.io
resources:
- ingresses
- networkpolicies
verbs:
- get
- list
- watch
- apiGroups:
- authorization.k8s.io
resources:
- localsubjectaccessreviews
verbs:
- create
- apiGroups:
- rbac.authorization.k8s.io
resources:
- rolebindings
- roles
verbs:
- create
- delete
- deletecollection
- get
- list
- patch
- update
- watch
这样两个权限的ClusterRole就创建好了。其实就是定义权限。有哪些权限。
1.3 创建sa ServiceAccount
我选择的是sa做角色,当然也可以选择user,或者usergroup。就是K8s实现权限划分有很多方式。看大家的选择需求了。
apiVersion: v1
kind: ServiceAccount
metadata:
name: business-axer-serviceaccount # sa的名称。随便取,当然你要能认识区分
namespace: business-auth # sa的ns。我这里单独的建了一个ns,就是为了做权限划分的ns。
1.4 创建ClusterRoleBinding
ClusterRoleBinding是用来绑定集群权限的。
也就是说把我上面定义的集群权限ClusterRole绑定给sa。这样这个sa就有操作集群的一些字眼的权限了。
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding # ClusterRoleBinding 用于绑定集群权限的
metadata:
name: business-axer:get # 名称 ClusterRoleBinding 不受ns的限制,所以没有ns
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole # 上面定义的ClusterRole名称
name: business-axer-get-auth
subjects:
- kind: ServiceAccount # 上面定义的sa名称
name: business-axer-serviceaccount
namespace: business-auth
1.5 创建RoleBinding
这个RoleBinding就是绑定ns里面的资源的权限的。
也就是说我把上面定义的ClusterRole权限绑定给sa。然后这个权限只能在这个RoleBinding所在的ns里面才有权限。
想要授权给业务放哪个ns的权限 就要在哪个ns里面创建一个RoleBinding。
假如说一个业务放有10个ns的权限,那么久需要创建10个RoleBinding。
# 我这下面是给这个sa了两个ns的所有权限
# ai-platform-deploy和ai-platform-test命名空间的所有权限
# 如果需要别的ns的权限那就定义多个RoleBinding。
# 当然这个RoleBinding必须要在ns里面。
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: business-axer:ai-platform-deploy
namespace: ai-platform-deploy
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: business-axer-admin-auth
subjects:
- kind: ServiceAccount
name: business-axer-serviceaccount
namespace: business-auth
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: business-axer:ai-platform-test
namespace: ai-platform-test
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: business-axer-admin-auth
subjects:
- kind: ServiceAccount
name: business-axer-serviceaccount
namespace: business-auth
权限和绑定都做完了,剩下的就是生成config文件了
1.6 生成config文件
我这里选择的是token的验证方式。
我是写了一个简单的脚本。
#!/bin/bash
sa_name="business-axer-serviceaccount" # 这个是sa的名称
user="business-axer" # 这个是user,对于我使用token的验证方式,这里的user没啥用,随便写
context_name="business-axer-ct" # 对于我使用token的验证方式,这个也是可以随便写,
cp ./demo.config ./guest.config # 拷贝一份demo.config
# 这里是获取sa的secret名称,每一个sa都会有。
secret_name=`kubectl get sa -n business-auth $sa_name -o go-template='{{range .secrets}}{{.name}}{{end}}'`
# 这里是获取secret的token
TOKEN=`kubectl -n business-auth get secret $secret_name -o go-template='{{.data.token}}'`
# 这下面是设置一些上下文
kubectl config set-credentials $user --token=`echo ${TOKEN} | base64 -d` --kubeconfig=./guest.config
kubectl config set-context $context_name --cluster=kubernetes --user=$user --kubeconfig=./guest.config
kubectl config use-context $context_name --kubeconfig=./guest.config
demo.config文件
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUCg== 这个是固定的,你查看一下线上的,其实就是https安全验证,ca证书
server: https://10.19.250.206:8443 # k8s集群apiservice的端口
name: kubernetes # 集群的名称
kind: Config
最终的guest.config文件,我的下面的除了token和ca我删了,其他的都是正确的。
apiVersion: v1
clusters:
- cluster:
certificate-authority-data: LShRTl0tLS0tCg==
server: https://10.19.250.206:8443
name: kubernetes
contexts:
- context:
cluster: kubernetes
user: business-axer
name: business-axer-ct
current-context: business-axer-ct
kind: Config
preferences: {}
users:
- name: business-axer
user:
token: eyJhbGciOiJSUzI1NiIsImtpZC-iyX0M6m5nEXqC6w
解读如下:
clusters记录了 clusters(一个或多个 K8S 集群)信息:
name是这个 cluster(K8S 集群)的名称代号
server是这个 cluster(K8S 集群)的访问方式,一般为 IP+PORT
certificate-authority-data是证书数据,只有当 cluster(K8S 集群)的连接方式是 https 时,为了安全起见需要证书数据
users记录了访问 cluster(K8S 集群)的账号信息:
name是用户账号的名称代号
user/token是用户的 token 认证方式,token 不是用户认证的唯一方式,其他还有账号+密码等。
contexts是上下文信息,包括了 cluster(K8S 集群)和访问 cluster(K8S 集群)的用户账号等信息:
name是这个上下文的名称代号
cluster是 cluster(K8S 集群)的名称代号
user是访问 cluster(K8S 集群)的用户账号代号
current-context记录当前 kubectl 默认使用的上下文信息
kind和apiVersion都是固定值,用户不需要关心
preferences则是配置文件的其他设置信息,我没有使用过,暂时不提。
1.7 config文件放入业务方用户的家目录下面的.kube/config。权限要644的。
多个业务放就按照上面的步骤创建就行,可以把业务放理解成sa。
二、配置jumpserver
其实就是在jumpserver上面创建系统用户,然后把这个系统用户绑定到用户组。
那么用户组里面的用户登录k8s master1机器的时候就是他们自己的系统用户了。
然后这个用户执行kubectl 的时候 默认会去家目录下面的.kube找config文件。
config文件又是我们生成的。
这样就可以把用户限制在ns里面了。
欢迎大佬留言评论,有什么不足的望各位大佬指出。
k8s结合jumpserver做kubectl权限控制 用户在多个namespaces的访问权限 rbac权限控制的更多相关文章
- 两种RBAC权限控制模型详解
序言 由于最近一直卡在权限控制这个坎上,原来设计的比较简单的权限控制思路已经无法满足比较复杂一些的场景,因此一直在探索一种在大部分场景下比较通用的权限模型. 首先,这里说明一下两种RBAC权限模型分别 ...
- 资源限制 ( resource limit 或 rlimit ),是 Linux 内核控制 用户 或 进程 资源占用的机制。
###### https://learn-linux.readthedocs.io/zh_CN/latest/administration/kernel/rlimit.html ########### ...
- Thinkphp3.2.3中的RBAC权限验证
最近在用TP的RBAC权限控制,在这里记录学习一下.先来看看相关的概念 一.相关概念 访问控制与RBAC模型1.访问控制: 通常的多用户系统都会涉及到访问控制,所谓访问控制,是指通过某种 ...
- sudo控制用户对系统命令的使用权限
sudo控制用户对系统命令的使用权限 sudo相关概念 普通用户涉及到超级权限的运用,管理员如果想让该普通用户通过su来切换到root获得超级权限,就必须把root权限密码告诉用户.但是如果普通用户有 ...
- SQLServer控制用户访问权限表
连接地址:http://www.cnblogs.com/yxyht/archive/2013/03/22/2975880.html 一.需求 在管理数据库过程中,我们经常需要控制某个用户访问数据库的权 ...
- SQL Server 2005 控制用户权限访问表
转自:http://www.cnblogs.com/gaizai/archive/2011/07/14/2106617.html 一.需求 在管理数据库过程中,我们经常需要控制某个用户访问数据库的权限 ...
- oracle_控制用户权限
oracle_控制用户权限 ①对 限制 数据库安全: 系统安全 数据安全性 系统权限: 对于数据库的权限 对象权限: 操作数据库对象的权限 1.系统权限 ...
- sharepoint:拥有完全控制权限的用户依然“拒绝访问”
//来源 http://www.cnblogs.com/jindahao/archive/2012/04/25/2468714.html 遇到问题: 拥有完全控制权限的用户依然拒绝访问. 可能的原因: ...
- Oracle 学习笔记 13 -- 控制用户权限
数据库控制语言的功能室控制用户对数据库的存取权限. 用户对某类数据具有何种操作权限是有DBA决定的.Oracle 通过GRANT语句完毕权限的授予,通过REVOKE语句完毕对权限的收回. 权限分为系统 ...
随机推荐
- Installing SFTP/SSH Server on Windows using OpenSSH
Installing SFTP/SSH Server 1. On Windows 10 version 1803 and newer In Settings app, go to Apps > ...
- 使用nmcli命令配置网络
!!!前言 nmcli是redhat7或者centos7之后的命令该命令可以完成网卡上所有的配置工作,并且可以写入配置文件,永久生效 1.NetworkManager NetworkManager是管 ...
- inux软件安装管理之——dpkg与apt-*详解
inux软件安装管理之--dpkg与apt-*详解 Nosee123关注 0.5922017.09.12 17:47:44字数 3,894阅读 8,565 [Linux软件安装管理系列]- - 传送门 ...
- NFS PersistentVolume(11)
一.部署nfs服务端 1.需在 k8s-master 节点上搭建了一个 NFS 服务器,目录为 /nfsdata: yum install -y nfs-utils rpcbind vim /etc/ ...
- 11.14 mii-tool:管理网络接口的状态
mii-tool命令用于查看.管理网络接口,默认情况下网卡的状态是自动协商的,但是有时也会出现不正常的情况,可以使用mii-tool进行调整. mii-tool [option] [interface ...
- Java必会之多线程
一.线程的基本知识 1.1 线程知识 进程和线程的关系和区别 线程: 线程是进程的基本执行单元,进程想要执行任务,必须要有线程.程序启动默认开启一条线程,这个线程被称为主线程. 进程: 进程是指在系统 ...
- Docker Context基本原理
Docker Context基本原理 介绍 本指南介绍了上下文如何使单个Docker CLI轻松管理多个Swarm集群.多个Kubernetes集群和多个单独的Docker节点. 单个Docker C ...
- 20 岁发表 SCI 的学霸,梦想用算法改变世界
2021 年 2 月,"新内容 新交互" 全球视频云创新挑战赛启幕.本次大赛由英特尔联合阿里云主办,与优酷战略技术合作,天池平台和阿里云视频云团队共同承办.大赛自开赛以来,吸引了全 ...
- python_xlutils : python利用xlutils修改表格内容
一.xlutils是什么 是一个提供了许多操作修改excel文件方法的库: 属于python的第三方模块 xlrd库用于读取excel文件中的数据,xlwt库用于将数据写入excel文件,修改用xlu ...
- Python集合:set
集合 集合的描述 set是一个无序不重复的序列,可以用{}或者 set() 函数创建集合,它存放不可变类型(如字符串.数字.元组)数据. 注意:创建一个空集合必须使用set()方法,因为{}是用来生成 ...