猿创征文|云原生|kubernetes学习之RBAC(6.1)

本文涉及的产品
访问控制,不限时长
简介: 猿创征文|云原生|kubernetes学习之RBAC

前言


kubernetes集群系统比较复杂的部分应该算是权限验证了,本文也主要就二进制安装的k8s集群的权限控制做一个简单的抛砖引玉。

主要还是根据前面所写的部署博客来分析,博文地址为:kubernetes二进制安装教程单master_zsk_john的博客-CSDN博客

一,什么是权限控制?什么是RBAC?


一般我们认为RBAC就是权限控制,是基于角色来进行的细度话的权限控制,主要在于用户可能有一个,但,用户的属性,角色可能会有很多个,这样组合方式就非常多,也能做到更加的精细,细粒度很高。

  • RBAC(Role-Based Access Control,基于角色的访问控制)允许通过Kubernetes API动态配置策略。也就是说整个用户系统是围绕角色来进行权限的分配划分。当然,也可以看做是一套复杂的访问控制策略。

二,权限控制的分类


在k8s中,大体可以分为六种权限控制:ABAC(基于属性的访问控制)、RBAC(基于角色的访问控制)、Webhook、Node、AlwaysDeny(一直拒绝)和AlwaysAllow(一直允许)这6种模式。

从1.6版本起,Kubernetes 默认启用RBAC访问控制策略。从1.8开始,RBAC已作为稳定的功能。通过设置–authorization-mode=RBAC,启用RABC。所以RBAC也就成了一种默认选用的授权模式。

webhook在k8s中的使用是在ingress插件中使用,最主要的也是最常用的就让RBAC。

二,RBAC的构成要素


在RBAC模型里面,有3个基础组成部分,分别是:主体、角色和权限。

  • User(用户):每个用户都有唯一的UID识别,并被授予不同的角色
  • group(用户组):相同类型的用户组成的组
  • serverAccount(服务账号):User,group,serverAccout都是主体类型对象
  • Role(角色):不同角色具有不同的权限,角色,比较抽象的对象。是一系列权限的集合,例如一个Role可包含读取和列出 Pod的权限
  • Permission(权限):访问权限(例如,get,update,list,也就是那些verbs)
  • 用户-角色映射:用户和角色之间的映射关系
  • 角色-权限映射:角色和权限之间的映射

那么,这里就有一个线性逻辑了,权限--->角色---->主体,也就是从权限开始,结束于主体了。权限指的是对于各种资源也可以称之为对象的动作定义,例如,列出pod名称,列出所有的deployment等等。

关于资源也就是对象,在k8s中是由apiserver定义的,其中关于权限认证的资源对象有这些:

[root@master cfg]# k api-resources
NAME                              SHORTNAMES   APIGROUP                       NAMESPACED   KIND
bindings                                                                      true         Binding
configmaps                        cm                                          true         ConfigMap
secrets                                                                       true         Secret
serviceaccounts                   sa                                          true         ServiceAccount
mutatingwebhookconfigurations                  admissionregistration.k8s.io   false        MutatingWebhookConfiguration
validatingwebhookconfigurations                admissionregistration.k8s.io   false        ValidatingWebhookConfiguration
apiservices                                    apiregistration.k8s.io         false        APIService
tokenreviews                                   authentication.k8s.io          false        TokenReview
localsubjectaccessreviews                      authorization.k8s.io           true         LocalSubjectAccessReview
selfsubjectaccessreviews                       authorization.k8s.io           false        SelfSubjectAccessReview
selfsubjectrulesreviews                        authorization.k8s.io           false        SelfSubjectRulesReview
subjectaccessreviews                           authorization.k8s.io           false        SubjectAccessReview
certificatesigningrequests        csr          certificates.k8s.io            false        CertificateSigningRequest
poddisruptionbudgets              pdb          policy                         true         PodDisruptionBudget
podsecuritypolicies               psp          policy                         false        PodSecurityPolicy
clusterrolebindings                            rbac.authorization.k8s.io      false        ClusterRoleBinding
clusterroles                                   rbac.authorization.k8s.io      false        ClusterRole
rolebindings                                   rbac.authorization.k8s.io      true         RoleBinding
roles                                          rbac.authorization.k8s.io      true         Role

认证「Authentication」


认证有如下几种方式:

1、HTTP Token认证:通过一个Token来识别合法用户。

HTTP Token的认证是用一个很长的特殊编码方式的并且难以被模仿的字符串来表达客户的一种方式。每一个Token对应一个用户名,存储在API Server能访问的文件中。当客户端发起API调用请求时,需要在HTTP Header里放入Token。

2、HTTP Base认证:通过用户名+密码的方式认证

用户名:密码 用base64算法进行编码后的字符串放在HTTP Request中的Heather Authorization 域里发送给服务端,服务端收到后进行解码,获取用户名和密码。

3、最严格的HTTPS证书认证:基于CA根证书签名的客户端身份认证方式

授权「Authorization」


认证只是确认通信的双方都是可信的,可以相互通信。而授权是确定请求方有哪些资源的权限。API Server目前支持如下几种授权策略(通过API Server的启动参数 --authorization-mode 设置)

  • AlwaysDeny:表示拒绝所有请求。仅用于测试
  • AlwaysAllow:表示允许所有请求。如果有集群不需要授权流程,则可以采用该策略
  • Node:节点授权是一种特殊用途的授权模式,专门授权由 kubelet 发出的 API 请求
  • Webhook:是一种 HTTP 回调模式,允许使用远程 REST 端点管理授权
  • ABAC:基于属性的访问控制,表示使用用户配置的授权规则对用户请求进行匹配和控制
  • RBAC:基于角色的访问控制,默认使用该规则
localsubjectaccessreviews                      authorization.k8s.io           true         LocalSubjectAccessReview
selfsubjectaccessreviews                       authorization.k8s.io           false        SelfSubjectAccessReview
selfsubjectrulesreviews                        authorization.k8s.io           false        SelfSubjectRulesReview
subjectaccessreviews                           authorization.k8s.io           false        SubjectAccessReview

例如这些资源就是授权,但很少使用。

那么,RBAC的开启是在apiserver的配置文件内,例如,我前面写的二进制安装部署文档内:

[root@master cfg]# cat /opt/kubernetes/cfg/kube-apiserver.conf
KUBE_APISERVER_OPTS="--v=2 \
--logtostderr=false \
--log-dir=/opt/kubernetes/logs \
--etcd-servers=https://192.168.217.16:2379,https://192.168.217.17:2379,https://192.168.217.18:2379 \
--bind-address=192.168.217.16 \
--secure-port=6443 \
--advertise-address=192.168.217.16 \
--allow-privileged=true \
--service-cluster-ip-range=10.0.0.0/24 \
--enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota,NodeRestriction \
--authorization-mode=RBAC,Node \
。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

可以看到,--authorization-mode可以定义多个,也就是授权模式可以混用。

RBAC【RBAC】


clusterrolebindings                            rbac.authorization.k8s.io      false        ClusterRoleBinding
clusterroles                                   rbac.authorization.k8s.io      false        ClusterRole
rolebindings                                   rbac.authorization.k8s.io      true         RoleBinding
roles                                          rbac.authorization.k8s.io      true         Role

其实,本文主要要讨论的就是这四个:角色,角色绑定,集群角色,集群角色绑定,这里需要注意,角色和角色绑定是被限定在namespace里的。

三,

(1)角色的建立

role定义只是定义权限,无关主体也就是用户,组,sa这些,是权限的集合。例如,建立一个名字叫test的角色,role和namespace是绑定的:

命令行方式:

[root@master cfg]# k create role test --verb=list,get,watch --resource=pods
role.rbac.authorization.k8s.io/test created

yaml文件形式:

[root@master cfg]# cat test-role.yaml 
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: test
rules:
- apiGroups: [""]
  resources: ["nodes", "pods", "services", "resourcequotas", "replicationcontrollers", "limitranges", "persistentvolumeclaims", "persistentvolumes", "namespaces", "endpoints"]
  verbs: ["list", "watch","get","update","create","ptach"]
- apiGroups: ["extensions"]
  resources: ["daemonsets", "deployments", "replicasets"]
  verbs: ["list", "watch"]
- apiGroups: ["apps"]
  resources: ["statefulsets"]
  verbs: ["list", "watch"]
- apiGroups: ["batch"]
  resources: ["cronjobs", "jobs"]
  verbs: ["list", "watch"]
- apiGroups: ["autoscaling"]
  resources: ["horizontalpodautoscalers"]
  verbs: ["list", "watch"]

以yaml文件形式为例详解:

这个新建的role是没有定义namespace,因此,是默认default这个namespace下,这个可以随意定义一个namespace,role是仍然可以建立的。

- apiGroups: [""] # apiGroups 就是api资源组,使用kubectl api-resources 第三列可以查看到
例如,k  api-resources 里查到的jobs是属于batch 这个apigroup的 --verb=*  用星号可表示全部权限
resources 指的就是资源对象了,比如,这个角色就对很多的资源有权限,例如pod,namespace,--resource=* 同样也可以用星号表示所有资源
verbs 就是指的权限了,所有权限是verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

[root@master cfg]# k describe role test

Name:                                   test

Labels:                                 <none>

Annotations:                            PolicyRule:

 Resources                             Non-Resource URLs  Resource Names  Verbs

 ---------                             -----------------  --------------  -----

 endpoints                             []                 []              [list watch get update create ptach]

 limitranges                           []                 []              [list watch get update create ptach]

 namespaces                            []                 []              [list watch get update create ptach]

 nodes                                 []                 []              [list watch get update create ptach]

 persistentvolumeclaims                []                 []              [list watch get update create ptach]

 persistentvolumes                     []                 []              [list watch get update create ptach]

 pods                                  []                 []              [list watch get update create ptach]

 replicationcontrollers                []                 []              [list watch get update create ptach]

 resourcequotas                        []                 []              [list watch get update create ptach]

 services                              []                 []              [list watch get update create ptach]

 statefulsets.apps                     []                 []              [list watch]

 horizontalpodautoscalers.autoscaling  []                 []              [list watch]

 cronjobs.batch                        []                 []              [list watch]

 jobs.batch                            []                 []              [list watch]

 daemonsets.extensions                 []                 []              [list watch]

 deployments.extensions                []                 []              [list watch]

 replicasets.extensions                []                 []              [list watch]

(2)集群角色 clusterrole

clusterrole是不和namespace绑定的,适用范围是整个集群,很明显是比role的使用范围大的。别的和role都基本一致,例如:

定义一个clusterrole:

[root@master ~]# kubectl create clusterrole testclusterrole --verb=get,list,watch --resource=pods --dry-run -o yaml
W0904 20:27:52.564182   19827 helpers.go:535] --dry-run is deprecated and can be replaced with --dry-run=client.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  creationTimestamp: null
  name: testclusterrole
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
  - watch

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
7天前
|
Cloud Native Serverless 数据中心
阿里云ACK One:注册集群支持ACS算力——云原生时代的计算新引擎
ACK One注册集群已正式支持ACS(容器计算服务)算力,为企业的容器化工作负载提供更多选择和更强大的计算能力。
|
2月前
|
存储 Kubernetes 开发者
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档
Docker 是一种开源的应用容器引擎,允许开发者将应用程序及其依赖打包成可移植的镜像,并在任何支持 Docker 的平台上运行。其核心概念包括镜像、容器和仓库。镜像是只读的文件系统,容器是镜像的运行实例,仓库用于存储和分发镜像。Kubernetes(k8s)则是容器集群管理系统,提供自动化部署、扩展和维护等功能,支持服务发现、负载均衡、自动伸缩等特性。两者结合使用,可以实现高效的容器化应用管理和运维。Docker 主要用于单主机上的容器管理,而 Kubernetes 则专注于跨多主机的容器编排与调度。尽管 k8s 逐渐减少了对 Docker 作为容器运行时的支持,但 Doc
178 5
容器化时代的领航者:Docker 和 Kubernetes 云原生时代的黄金搭档
|
3月前
|
Kubernetes Cloud Native 微服务
云原生入门与实践:Kubernetes的简易部署
云原生技术正改变着现代应用的开发和部署方式。本文将引导你了解云原生的基础概念,并重点介绍如何使用Kubernetes进行容器编排。我们将通过一个简易的示例来展示如何快速启动一个Kubernetes集群,并在其上运行一个简单的应用。无论你是云原生新手还是希望扩展现有知识,本文都将为你提供实用的信息和启发性的见解。
|
3月前
|
Kubernetes Cloud Native 云计算
云原生入门:Kubernetes 和容器化基础
在这篇文章中,我们将一起揭开云原生技术的神秘面纱。通过简单易懂的语言,我们将探索如何利用Kubernetes和容器化技术简化应用的部署和管理。无论你是初学者还是有一定经验的开发者,本文都将为你提供一条清晰的道路,帮助你理解和运用这些强大的工具。让我们从基础开始,逐步深入了解,最终能够自信地使用这些技术来优化我们的工作流程。
|
3月前
|
运维 Kubernetes Cloud Native
云原生技术入门:Kubernetes和Docker的协同工作
【10月更文挑战第43天】在云计算时代,云原生技术成为推动现代软件部署和运行的关键力量。本篇文章将带你了解云原生的基本概念,重点探讨Kubernetes和Docker如何协同工作以支持容器化应用的生命周期管理。通过实际代码示例,我们将展示如何在Kubernetes集群中部署和管理Docker容器,从而为初学者提供一条清晰的学习路径。
|
3月前
|
Kubernetes Cloud Native 开发者
云原生入门:Kubernetes的简易指南
【10月更文挑战第41天】本文将带你进入云原生的世界,特别是Kubernetes——一个强大的容器编排平台。我们将一起探索它的基本概念和操作,让你能够轻松管理和部署应用。无论你是新手还是有经验的开发者,这篇文章都能让你对Kubernetes有更深入的理解。
|
1月前
|
缓存 容灾 网络协议
ACK One多集群网关:实现高效容灾方案
ACK One多集群网关可以帮助您快速构建同城跨AZ多活容灾系统、混合云同城跨AZ多活容灾系统,以及异地容灾系统。
|
2月前
|
Kubernetes Ubuntu 网络安全
ubuntu使用kubeadm搭建k8s集群
通过以上步骤,您可以在 Ubuntu 系统上使用 kubeadm 成功搭建一个 Kubernetes 集群。本文详细介绍了从环境准备、安装 Kubernetes 组件、初始化集群到管理和使用集群的完整过程,希望对您有所帮助。在实际应用中,您可以根据具体需求调整配置,进一步优化集群性能和安全性。
148 12
|
2月前
|
Prometheus Kubernetes 监控
OpenAI故障复盘 - 阿里云容器服务与可观测产品如何保障大规模K8s集群稳定性
聚焦近日OpenAI的大规模K8s集群故障,介绍阿里云容器服务与可观测团队在大规模K8s场景下我们的建设与沉淀。以及分享对类似故障问题的应对方案:包括在K8s和Prometheus的高可用架构设计方面、事前事后的稳定性保障体系方面。
|
2月前
|
Kubernetes 网络协议 应用服务中间件
Kubernetes Ingress:灵活的集群外部网络访问的利器
《Kubernetes Ingress:集群外部访问的利器-打造灵活的集群网络》介绍了如何通过Ingress实现Kubernetes集群的外部访问。前提条件是已拥有Kubernetes集群并安装了kubectl工具。文章详细讲解了Ingress的基本组成(Ingress Controller和资源对象),选择合适的版本,以及具体的安装步骤,如下载配置文件、部署Nginx Ingress Controller等。此外,还提供了常见问题的解决方案,例如镜像下载失败的应对措施。最后,通过部署示例应用展示了Ingress的实际使用方法。
87 2

热门文章

最新文章