猿创征文｜云原生|kubernetes学习之多账户管理--权限精细化分配方案（两种方式-sa和用户）

2023-10-29 14:50
文章标签 云原生 学习 分配 kubernetes 管理 方式 用户 两种 权限 方案 账户 sa 之多 精细化 征文 猿创

本文主要是介绍猿创征文｜云原生|kubernetes学习之多账户管理--权限精细化分配方案（两种方式-sa和用户），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

前言：

kubernetes其实也需要有一定的安全，权限外溢会导致整个系统的破坏，比如，被人恶意种挖矿木马，或者遭遇勒索病毒，因此，在进行kubernetes集群的管理工作时，我们应该给账号划分多层次的账号从而满足各种各样的需求。

一，

serviceaccount形式的账号，此账号只有查看各类资源的功能，没有操作资源的功能

（1）

建立一个namespace，命名为view，建立一个sa名字为user1-view

[root@master ~]# k create ns view
namespace/view created
[root@master ~]# k create sa user1-view -n view
serviceaccount/user1-view created

（2）

在集群中有几个默认存在的clusterrole，其中的view这个clusterrole是具有查看所有资源的权限，我们将此clusterrole绑定到user-view上，那么，在日常的使用中，只需要登录这个sa就可以方便的查看所有的资源了，但，重要的资源此sa无权删除或更改，从而提高了集群的安全性。

[root@master ~]# cat user1-view-bind.yaml 
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:name: role-bind-user1namespace: view
subjects:
- kind: ServiceAccountname: user1-viewnamespace: view
roleRef:kind: ClusterRolename: viewapiGroup: rbac.authorization.k8s.io

验证：

查询此sa的token，命令如下：

[root@master ~]# k describe sa user1-view -n view
Name:                user1-view
Namespace:           view
Labels:              <none>
Annotations:         <none>
Image pull secrets:  <none>
Mountable secrets:   user1-view-token-7qp6t
Tokens:              user1-view-token-7qp6t
Events:              <none>
[root@master ~]# k describe secret user1-view-token-7qp6t -n view
Name:         user1-view-token-7qp6t
Namespace:    view
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: user1-viewkubernetes.io/service-account.uid: 9a7d3693-7d11-4254-a3b1-6842ef8fcd8cType:  kubernetes.io/service-account-tokenData
====
ca.crt:     1359 bytes
namespace:  4 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6IkxNRk93NFRwc3l5UlJjcG05V1IwY25rWjNGOWM1Z05OQjVXN1ROa004R1UifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJ2aWV3Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InVzZXIxLXZpZXctdG9rZW4tN3FwNnQiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoidXNlcjEtdmlldyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjlhN2QzNjkzLTdkMTEtNDI1NC1hM2IxLTY4NDJlZjhmY2Q4YyIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDp2aWV3OnVzZXIxLXZpZXcifQ.h-9-w-02bzh1ccujta4Q4BOTy-TSZ0AZj6HdNYm_VNVVD7CevRE0VHERN7CzhYgIIhK_6FM5O6P7HjhSr92Lb5QW1jJSecK6_ywK7f_BGczvDrqVcQ0TPpUIl0U7Q_UemB_-tJ8X9s2bvRrl2U-BvOlTBZdRs7sLOGE5GzgwmAIHooQeAhKcRwPUDmxlZ0XChjeUVoREupKJEPJFF8T6zX9LXXm4DAV42Qyu2IzpkoEk2xsm0jYNcoTAj6lOSoMmtL8kSTYrvoWU1dmxIysyuR_pDgyv5f9-49NOW8fbxR10kv3Ii9PtT4O-mxyr81bUuWOLMoD5IoWaet3tpxYMGA

也可以这样查询token：

[root@master ~]# k get secret -n view |grep user1
user1-view-token-7qp6t   kubernetes.io/service-account-token   3      73m
[root@master ~]# kubectl get secret user1-view-token-7qp6t  -o jsonpath={.data.token} -n view |base64 -d && echo
eyJhbGciOiJSUzI1NiIsImtpZCI6IkxNRk93NFRwc3l5UlJjcG05V1IwY25rWjNGOWM1Z05OQjVXN1ROa004R1UifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJ2aWV3Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6InVzZXIxLXZpZXctdG9rZW4tN3FwNnQiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoidXNlcjEtdmlldyIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6IjlhN2QzNjkzLTdkMTEtNDI1NC1hM2IxLTY4NDJlZjhmY2Q4YyIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDp2aWV3OnVzZXIxLXZpZXcifQ.h-9-w-02bzh1ccujta4Q4BOTy-TSZ0AZj6HdNYm_VNVVD7CevRE0VHERN7CzhYgIIhK_6FM5O6P7HjhSr92Lb5QW1jJSecK6_ywK7f_BGczvDrqVcQ0TPpUIl0U7Q_UemB_-tJ8X9s2bvRrl2U-BvOlTBZdRs7sLOGE5GzgwmAIHooQeAhKcRwPUDmxlZ0XChjeUVoREupKJEPJFF8T6zX9LXXm4DAV42Qyu2IzpkoEk2xsm0jYNcoTAj6lOSoMmtL8kSTYrvoWU1dmxIysyuR_pDgyv5f9-49NOW8fbxR10kv3Ii9PtT4O-mxyr81bUuWOLMoD5IoWaet3tpxYMGA

dashboard登录成功：

随便找个pod看能不能删除（当然是无权删除）：

 当然了，更改任何配置此sa也是没有权限的，secret这样的敏感信息也是无权查看的哦，这样集群就非常的安全啦。

上述的权限管理是利用了集群内置的角色view实现的，那么这样的权限外放是显得有点粗放的，并不是非常的精细，如果只是希望某个sa只能够访问指定的namespace下资源，如何做呢？

二，权限精细化分配---通过sa和自建角色实现权限精细化分配

（1）

新建一个sa

kubectl create ns dev  先建立一个namespace
[root@master sa]# cat sa-create.yaml 
apiVersion: v1
kind: ServiceAccount
metadata:name: sa-devnamespace: dev

（2）

建立一个角色，并将该角色绑定到sa上：

角色role-sa 具有的权限仅仅是namespace  dev内的所有pod的查看权限，以及deployment的查看权限，无权删除修改这些资源

[root@master sa]# cat sa-role-binding.yaml 
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:name: role-sanamespace: dev                         #指定 Namespace
rules:                                      #权限分配- apiGroups: [""]resources: ["pods"]verbs: ["get", "watch", "list"]- apiGroups: [""]resources: ["pods/log"]verbs: ["get","list","watch"]- apiGroups: [""]resources: ["pods/attach"]verbs: ["get","list","watch"]- apiGroups: [""]resources: ["pods/exec"]verbs: ["get","list","watch"]- apiGroups: [""]resources: ["pods/status"]verbs: ["get","list","watch"]- apiGroups: [""]resources: ["podtemplates"]verbs: ["get","list","watch"]- apiGroups: ["extensions", "apps"]resources: ["deployments","statefulsets"]verbs: ["get", "list", "watch"]- apiGroups: [""]resources: ["configmaps"]verbs: ["get", "list", "watch"]- apiGroups: [""]resources: ["endpoints"]verbs: ["get", "list", "watch"]- apiGroups: [""]resources: ["events"]verbs: ["get", "list", "watch"]- apiGroups: [""]resources: ["replicationcontrollers"]verbs: ["get", "list", "watch"]- apiGroups: [""]resources: ["replicationcontrollers/status"]verbs: ["get"]- apiGroups: [""]resources: ["services"]verbs: ["get", "list", "watch"]- apiGroups: [""]resources: ["services/status"]verbs: ["get", "list", "watch"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:name: rbac-role-bindingnamespace: dev                 #指定 Namespace
subjects:- kind: ServiceAccountname: sa-dev                 #指定 ServiceAccountnamespace: dev               #指定 Namespace
roleRef:kind: Rolename: role-saapiGroup: rbac.authorization.k8s.io

（3）

授权namespace的权限，为什么要授权是因为sa内的secrets里的token只有在dashboard内使用，而上面的角色和角色绑定都是dev这个namespace内的，这样绑定后，拿到token才可以登录到dashboard的首页，否则都无法选择namespace。

[root@master sa]# cat cluster-role-binding.yaml 
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:name: rbac-namespace-role
rules:- apiGroups: [""]                     #配置权限，配置其只用于 namespace 的 list 权限resources: ["namespaces"]verbs: ["list"]- apiGroups: [""]resources: ["namespaces/status"]verbs: ["get"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:name: rbac-default-role-binding
subjects:- kind: ServiceAccountname: sa-dev                     #配置为自定义的 ServiceAccountnamespace: dev                  #指定为服务账户所在的 Namespace
roleRef:kind: ClusterRolename: rbac-namespace-role             #配置上面的 RoleapiGroup: rbac.authorization.k8s.io

（4）

单元测试

首先，使用deployment方式创建一个nginx的pod：

k create deploy nginx --image=nginx -n dev

获取这个sa下的secrets的token，使用该token登录dashboard：

[root@master sa]# kubectl -n dev describe secret $(kubectl get secret -n dev | grep sa-dev | awk '{print $1}')
Name:         sa-dev-token-8ckbd
Namespace:    dev
Labels:       <none>
Annotations:  kubernetes.io/service-account.name: sa-devkubernetes.io/service-account.uid: 7953d280-7b1a-4ba6-a0a4-e705e1cc9550Type:  kubernetes.io/service-account-tokenData
====
ca.crt:     1359 bytes
namespace:  3 bytes
token:      eyJhbGciOiJSUzI1NiIsImtpZCI6IkxNRk93NFRwc3l5UlJjcG05V1IwY25rWjNGOWM1Z05OQjVXN1ROa004R1UifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZXYiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoic2EtZGV2LXRva2VuLThja2JkIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6InNhLWRldiIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6Ijc5NTNkMjgwLTdiMWEtNGJhNi1hMGE0LWU3MDVlMWNjOTU1MCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZXY6c2EtZGV2In0.tGQMxNX-zbAAltH-GkgvDKhBm7VjvNDWwE77NLyD1naqsF8pMfd9_4MlSv9dHVe8KlRTaqH7AHVKvQnwuy68TKbFj-0Zzx7O5P7DI4Q7bmc2p_jwNxjX0RSARiTmk6pAaMN9tffH7FcwsmBKTDBKX7_X7e3MOrDeBsPLgqkFYAQk_bAld0Smv-HbYDuAw3WzdYsnOLmmW1ceUdZycPvHHmbccnhZUWFnjEx0lxdWBksmHJI60W1xAJNSv-EoKTz1klVaQgpCzJrXhv_MENPUeJgxPCS9o6nhoVG13s5gISf8aK7hHi9ccvtyWDsgFw7Od0Vd3x3IiK7o2IpPTormug

选择系统namespace  kube-system以及其它任意的namespace，任何资源都看不到，除了dev这个namespace：

删除这个pod试试看（提示无权删除）：

 OK，编辑功能什么的都可以试一试，全部用不了，只有查看的权利，主要是因为前面的角色 role-sa 给的权限都是verbs: ["get", "watch", "list"]嘛，这样就完成了一个精细化的权限分配操作：指定的sa限定在一个指定的namespace里获取指定的资源（本例是指定的namespace里只有查看pod，deployment等个别资源的权限）。

小结：

那么，sa由于是给服务使用的，本例中是给dashboard使用的，这就造成了管理方面的局限性，总是要登录dashboard或者其它能够使用token的场景，sa的权限才会生效。那么，有没有给人使用的权限精细化分配方案呢？答案是必须有，通过kubeconfig文件就可以实现精准的权限管理啦，命令行和图形化界面都可以使用非常的方便哦。

 三，

通过系统配置文件kubeconfig文件实现权限的精细化分配：

本次案例使用的集群为kubernetes二进制安装教程单master_zsk_john的博客-CSDN博客， 也就是集群的基本信息是：

token是前面的sa-dev这个sa里面的secrets，通过这个命令查询出来的：

kubectl -n dev describe secret $(kubectl get secret -n dev | grep sa-dev | awk '{print $1}')

kubeconfig文件生成前先把变量激活哦，这个不要忘记了： 

KUBE_APISERVER="https://192.168.217.16:6443"
TOKEN="eyJhbGciOiJSUzI1NiIsImtpZCI6IkxNRk93NFRwc3l5UlJjcG05V1IwY25rWjNGOWM1Z05OQjVXN1ROa004R1UifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJkZXYiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlY3JldC5uYW1lIjoic2EtZGV2LXRva2VuLThja2JkIiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZXJ2aWNlLWFjY291bnQubmFtZSI6InNhLWRldiIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6Ijc5NTNkMjgwLTdiMWEtNGJhNi1hMGE0LWU3MDVlMWNjOTU1MCIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDpkZXY6c2EtZGV2In0.tGQMxNX-zbAAltH-GkgvDKhBm7VjvNDWwE77NLyD1naqsF8pMfd9_4MlSv9dHVe8KlRTaqH7AHVKvQnwuy68TKbFj-0Zzx7O5P7DI4Q7bmc2p_jwNxjX0RSARiTmk6pAaMN9tffH7FcwsmBKTDBKX7_X7e3MOrDeBsPLgqkFYAQk_bAld0Smv-HbYDuAw3WzdYsnOLmmW1ceUdZycPvHHmbccnhZUWFnjEx0lxdWBksmHJI60W1xAJNSv-EoKTz1klVaQgpCzJrXhv_MENPUeJgxPCS9o6nhoVG13s5gISf8aK7hHi9ccvtyWDsgFw7Od0Vd3x3IiK7o2IpPTormug"

（1）集群的ca证书生成

[root@master k8s-ssl]# cat ca-config.json 
{
"signing": {
"default": {
"expiry": "87600h"
},
"profiles": {
"kubernetes": {
"expiry": "87600h",
"usages": [
"signing",
"key encipherment",
"server auth",
"client auth"
]
}
}
}
}
[root@master k8s-ssl]# cat ca-csr.json 
{
"CN": "kubernetes",
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"L": "Beijing",
"ST": "Beijing","O": "k8s",
"OU": "System"
}
]
}

生成ca证书，证书生成后存放到任意目录下，例如/mnt：

cfssl gencert -initca ca-csr.json | cfssljson -bare ca -
cp ca.pem /mnt/

建立用户命令（这几个步骤是息息相关的，注意理解）：

config文件引入集群ca证书，这里的set-cluster 可以任意设置，想叫什么集群名字都可以，我这里定义为mykubernetes，kubeconfig文件名称也随意定义，我这里定义为test.kubeconfig，此命令执行后会在当前目录生成test.kubeconfig这个文件：

kubectl config set-cluster mykubernetes \
--certificate-authority=/mnt/ca.pem \
--embed-certs=true \
--server=${KUBE_APISERVER} \
--kubeconfig=test.kubeconfig

定义的用户名称是test，当然，用户名称可以随意定义。里面的token就已经带了前面建立的sa的权限---查看dev这个namespace下的pod的权限：

kubectl config set-credentials "test" \
--token=${TOKEN} \
--kubeconfig=test.kubeconfig

定义上下文的名称，这个也是随便定义，我就用了拼音权限分配，cluster 就是前面定义的集群名称 ，用户名称也是前面定义的，这个不能乱写哦，要匹配。

kubectl config set-context quanxianfenpei \--cluster=mykubernetes \--user=test \--kubeconfig=test.kubeconfig

 切换上下文，其实这一步就是将ca证书和token关联起来并写在了这个新定义的kubeconfig文件内。

kubectl config use-context quanxianfenpei \--kubeconfig=test.kubeconfig

OK，这样我们就完成了使用kubeconfig配置精细化权限的流程，下面进入单元测试环节。 

单元测试：

（1）

将test.kubeconfig这个文件拷贝到浏览器所在环境内，dashboard登录的时候选择此文件，成功登录dashboard，并且功能和上面的单元测试结果一致。

 （2）

使用kubectl config 命令行测试：

可以查看pod，不能编辑删除pod

[root@master cfg]# k --kubeconfig=/root/kubeconfig/test.kubeconfig get po
[root@master cfg]# k --kubeconfig=/root/kubeconfig/test.kubeconfig delete pod 
nginx-f89759699-cbnw6

这篇关于猿创征文｜云原生|kubernetes学习之多账户管理--权限精细化分配方案（两种方式-sa和用户）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/301384。

相关文章

C++中零拷贝的多种实现方式

C++中零拷贝的多种实现方式

《C++中零拷贝的多种实现方式》本文主要介绍了C++中零拷贝的实现示例,旨在在减少数据在内存中的不必要复制,从而提高程序性能、降低内存使用并减少CPU消耗,零拷贝技术通过多种方式实现,下面就来了解一下... 目录一、C++中零拷贝技术的核心概念二、std::string_view 简介三、std::stri
阅读更多...
Linux脚本(shell)的使用方式

Linux脚本(shell)的使用方式

《Linux脚本(shell)的使用方式》：本文主要介绍Linux脚本(shell)的使用方式,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录概述语法详解数学运算表达式Shell变量变量分类环境变量Shell内部变量自定义变量：定义、赋值自定义变量：引用、修改、删
阅读更多...
python判断文件是否存在常用的几种方式

python判断文件是否存在常用的几种方式

《python判断文件是否存在常用的几种方式》在Python中我们在读写文件之前,首先要做的事情就是判断文件是否存在,否则很容易发生错误的情况,：本文主要介绍python判断文件是否存在常用的几种... 目录1. 使用 os.path.exists()2. 使用 os.path.isfile()3. 使用
阅读更多...
使用jenv工具管理多个JDK版本的方法步骤

使用jenv工具管理多个JDK版本的方法步骤

《使用jenv工具管理多个JDK版本的方法步骤》jenv是一个开源的Java环境管理工具,旨在帮助开发者在同一台机器上轻松管理和切换多个Java版本,：本文主要介绍使用jenv工具管理多个JD... 目录一、jenv到底是干啥的？二、jenv的核心功能（一）管理多个Java版本（二）支持插件扩展（三）环境隔
阅读更多...
SpringBoot服务获取Pod当前IP的两种方案

SpringBoot服务获取Pod当前IP的两种方案

《SpringBoot服务获取Pod当前IP的两种方案》在Kubernetes集群中,SpringBoot服务获取Pod当前IP的方案主要有两种,通过环境变量注入或通过Java代码动态获取网络接口IP... 目录方案一：通过 Kubernetes Downward API 注入环境变量原理步骤方案二：通过
阅读更多...
Springboot3+将ID转为JSON字符串的详细配置方案

Springboot3+将ID转为JSON字符串的详细配置方案

《Springboot3+将ID转为JSON字符串的详细配置方案》：本文主要介绍纯后端实现Long/BigIntegerID转为JSON字符串的详细配置方案,s基于SpringBoot3+和Spr... 目录1. 添加依赖2. 全局 Jackson 配置3. 精准控制（可选）4. OpenAPI (Spri
阅读更多...
Mybatis的分页实现方式

Mybatis的分页实现方式

《Mybatis的分页实现方式》MyBatis的分页实现方式主要有以下几种,每种方式适用于不同的场景,且在性能、灵活性和代码侵入性上有所差异,对Mybatis的分页实现方式感兴趣的朋友一起看看吧... 目录​1. 原生 SQL 分页（物理分页）​​2. RowBounds 分页（逻辑分页）​​3. Page
阅读更多...
关于跨域无效的问题及解决(java后端方案)

关于跨域无效的问题及解决(java后端方案)

《关于跨域无效的问题及解决(java后端方案)》：本文主要介绍关于跨域无效的问题及解决(java后端方案),具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录通用后端跨域方法1、@CrossOrigin 注解2、springboot2.0 实现WebMvcConfig
阅读更多...
Linux链表操作方式

Linux链表操作方式

《Linux链表操作方式》：本文主要介绍Linux链表操作方式,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录一、链表基础概念与内核链表优势二、内核链表结构与宏解析三、内核链表的优点四、用户态链表示例五、双向循环链表在内核中的实现优势六、典型应用场景七、调试技巧与
阅读更多...
Go学习记录之runtime包深入解析

Go学习记录之runtime包深入解析

《Go学习记录之runtime包深入解析》Go语言runtime包管理运行时环境,涵盖goroutine调度、内存分配、垃圾回收、类型信息等核心功能,：本文主要介绍Go学习记录之runtime包的... 目录前言：一、runtime包内容学习1、作用：① Goroutine和并发控制：② 垃圾回收：③ 栈和
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2