猿创征文|云原生|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登录成功:

e693485c8668497882b9df08e639a065.png

随便找个pod看能不能删除(当然是无权删除):

ede0f0cac6cc46c2bd5e6cab6a644ce0.png

 当然了,更改任何配置此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
相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
2月前
|
存储 Kubernetes 开发者
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档
Docker 是一种开源的应用容器引擎,允许开发者将应用程序及其依赖打包成可移植的镜像,并在任何支持 Docker 的平台上运行。其核心概念包括镜像、容器和仓库。镜像是只读的文件系统,容器是镜像的运行实例,仓库用于存储和分发镜像。Kubernetes(k8s)则是容器集群管理系统,提供自动化部署、扩展和维护等功能,支持服务发现、负载均衡、自动伸缩等特性。两者结合使用,可以实现高效的容器化应用管理和运维。Docker 主要用于单主机上的容器管理,而 Kubernetes 则专注于跨多主机的容器编排与调度。尽管 k8s 逐渐减少了对 Docker 作为容器运行时的支持,但 Doc
154 5
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档
|
3月前
|
Kubernetes Cloud Native 微服务
云原生入门与实践:Kubernetes的简易部署
云原生技术正改变着现代应用的开发和部署方式。本文将引导你了解云原生的基础概念,并重点介绍如何使用Kubernetes进行容器编排。我们将通过一个简易的示例来展示如何快速启动一个Kubernetes集群,并在其上运行一个简单的应用。无论你是云原生新手还是希望扩展现有知识,本文都将为你提供实用的信息和启发性的见解。
|
3月前
|
运维 Kubernetes Cloud Native
云原生技术入门:Kubernetes和Docker的协同工作
【10月更文挑战第43天】在云计算时代,云原生技术成为推动现代软件部署和运行的关键力量。本篇文章将带你了解云原生的基本概念,重点探讨Kubernetes和Docker如何协同工作以支持容器化应用的生命周期管理。通过实际代码示例,我们将展示如何在Kubernetes集群中部署和管理Docker容器,从而为初学者提供一条清晰的学习路径。
|
3月前
|
Kubernetes Cloud Native 云计算
云原生入门:Kubernetes 和容器化基础
在这篇文章中,我们将一起揭开云原生技术的神秘面纱。通过简单易懂的语言,我们将探索如何利用Kubernetes和容器化技术简化应用的部署和管理。无论你是初学者还是有一定经验的开发者,本文都将为你提供一条清晰的道路,帮助你理解和运用这些强大的工具。让我们从基础开始,逐步深入了解,最终能够自信地使用这些技术来优化我们的工作流程。
|
2月前
|
运维 Cloud Native 持续交付
深入理解云原生架构及其在现代企业中的应用
随着数字化转型的浪潮席卷全球,企业正面临着前所未有的挑战与机遇。云计算技术的迅猛发展,特别是云原生架构的兴起,正在重塑企业的IT基础设施和软件开发模式。本文将深入探讨云原生的核心概念、关键技术以及如何在企业中实施云原生策略,以实现更高效的资源利用和更快的市场响应速度。通过分析云原生架构的优势和面临的挑战,我们将揭示它如何助力企业在激烈的市场竞争中保持领先地位。
|
2月前
|
Kubernetes Cloud Native 微服务
探索云原生技术:容器化与微服务架构的融合之旅
本文将带领读者深入了解云原生技术的核心概念,特别是容器化和微服务架构如何相辅相成,共同构建现代软件系统。我们将通过实际代码示例,探讨如何在云平台上部署和管理微服务,以及如何使用容器编排工具来自动化这一过程。文章旨在为开发者和技术决策者提供实用的指导,帮助他们在云原生时代中更好地设计、部署和维护应用。
|
3月前
|
Cloud Native Devops 云计算
云计算的未来:云原生架构与微服务的革命####
【10月更文挑战第21天】 随着企业数字化转型的加速,云原生技术正迅速成为IT行业的新宠。本文深入探讨了云原生架构的核心理念、关键技术如容器化和微服务的优势,以及如何通过这些技术实现高效、灵活且可扩展的现代应用开发。我们将揭示云原生如何重塑软件开发流程,提升业务敏捷性,并探索其对企业IT架构的深远影响。 ####
71 3
|
3月前
|
Cloud Native 持续交付 云计算
云原生架构的演进与挑战
随着云计算技术的不断发展,云原生架构已成为企业数字化转型的重要支撑。本文深入探讨了云原生架构的概念、发展历程、核心技术以及面临的挑战,旨在为读者提供一个全面了解云原生架构的视角。通过分析Kubernetes、Docker等关键技术的应用,以及微服务、持续集成/持续部署(CI/CD)等实践案例,本文揭示了云原生架构在提高应用开发效率、降低运维成本、增强系统可扩展性等方面的显著优势。同时,也指出了云原生架构在安全性、复杂性管理等方面所面临的挑战,并提出了相应的解决策略。
|
2月前
|
运维 Cloud Native 持续交付
云原生技术深度探索:重塑现代IT架构的无形之力####
本文深入剖析了云原生技术的核心概念、关键技术组件及其对现代IT架构变革的深远影响。通过实例解析,揭示云原生如何促进企业实现敏捷开发、弹性伸缩与成本优化,为数字化转型提供强有力的技术支撑。不同于传统综述,本摘要直接聚焦于云原生技术的价值本质,旨在为读者构建一个宏观且具体的技术蓝图。 ####
|
2月前
|
弹性计算 运维 Cloud Native
云原生架构的崛起与未来展望
在数字化转型的浪潮中,云原生架构凭借其高效、灵活和可扩展的特性,正逐渐成为企业IT战略的核心。本文旨在探讨云原生架构的定义、关键特性、实施优势以及面临的挑战,同时展望未来的发展趋势。通过深入分析,我们期望为读者提供一个关于云原生架构全面而深入的视角,助力企业在云计算时代做出更明智的决策。
55 3

热门文章

最新文章