猿创征文|云原生|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-user1
  namespace: view
subjects:
- kind: ServiceAccount
  name: user1-view
  namespace: view
roleRef:
  kind: ClusterRole
  name: view
  apiGroup: 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-view
              kubernetes.io/service-account.uid: 9a7d3693-7d11-4254-a3b1-6842ef8fcd8c
Type:  kubernetes.io/service-account-token
Data
====
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-dev
  namespace: 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-sa
  namespace: 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-binding
  namespace: dev                 #指定 Namespace
subjects:
  - kind: ServiceAccount
    name: sa-dev                 #指定 ServiceAccount
    namespace: dev               #指定 Namespace
roleRef:
  kind: Role
  name: role-sa
  apiGroup: 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: ServiceAccount
    name: sa-dev                     #配置为自定义的 ServiceAccount
    namespace: dev                  #指定为服务账户所在的 Namespace
roleRef:
  kind: ClusterRole
  name: rbac-namespace-role             #配置上面的 Role
  apiGroup: 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-dev
              kubernetes.io/service-account.uid: 7953d280-7b1a-4ba6-a0a4-e705e1cc9550
Type:  kubernetes.io/service-account-token
Data
====
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的博客也就是集群的基本信息是:

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
相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务&nbsp;ACK 容器服务&nbsp;Kubernetes&nbsp;版(简称&nbsp;ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情:&nbsp;https://www.aliyun.com/product/kubernetes
目录
相关文章
|
23天前
|
Kubernetes Cloud Native Devops
云原生技术落地实现之二KubeSphere DevOps 系统在 Kubernetes 集群上实现springboot项目的自动部署和管理 CI/CD (2/2)
云原生技术落地实现之二KubeSphere DevOps 系统在 Kubernetes 集群上实现springboot项目的自动部署和管理 CI/CD (2/2)
47 1
|
1月前
|
弹性计算 运维 Kubernetes
云原生K8S场景自动化响应ECS系统事件
客户云原生K8S场景下,通过社区开源NPD+Draino+Autoscaler零开发,对接响应ECS主动运维事件,通过自动响应事件减少非预期宕机。
|
2月前
|
存储 Kubernetes 安全
加密 K8s Secrets 的几种方案
加密 K8s Secrets 的几种方案
|
2月前
|
Prometheus 监控 Kubernetes
监控 Kubernetes 集群证书过期时间的三种方案
监控 Kubernetes 集群证书过期时间的三种方案
|
3月前
|
Kubernetes Cloud Native 网络协议
【云原生】Kubernetes介绍
【云原生】Kubernetes介绍
35 1
|
3月前
|
Kubernetes Cloud Native 调度
云原生技术专题 | 云原生容器编排问题盘点,总结分享年度使用Kubernetes的坑和陷阱
随着云原生的兴起,越来越多的应用选择基于Kubernetes进行部署,可以说Kubernetes 是最流行的容器编排和部署平台。它的强大功能特性,可以保障在生产中可靠地运行容器化应用程序,相关的DevOps等工具也应运而生,下面就是小编简单化了一个Kubernetes的逻辑架构图。
323 9
云原生技术专题 | 云原生容器编排问题盘点,总结分享年度使用Kubernetes的坑和陷阱
|
3月前
|
Kubernetes iOS开发 Docker
为什么你应该学习 Docker 🐋 和 Kubernetes ☸️?
如果您是一名开发人员,我相信您一定听说过这句话:“它可以在我的机器上运行”。当我们的代码在您的计算机上运行但在朋友的计算机上表现不佳时,这是令人心碎的。
22 0
|
3月前
|
人工智能 Cloud Native PyTorch
阿里云 ACK 云原生 AI 套件中的分布式弹性训练实践
阿里云 ACK 云原生 AI 套件中的分布式弹性训练实践
148642 4
|
3月前
|
人工智能 Cloud Native 调度
为大模型工程提效,基于阿里云 ACK 的云原生 AI 工程化实践
本文主要介绍了解析云原生 AI 所遇到的技术挑战和应对方案,随后介绍云原生 AI 领域的关键技术与架构细节,最后分享我们在 ACK 的相关经验及工程实践。
|
4月前
|
Kubernetes API 容器