k8s学习-基于角色的权限控制RBAC(概念,模版,创建,删除等)

简介: k8s学习-基于角色的权限控制RBAC(概念,模版,创建,删除等)

概念

基于角色的访问控制(RBAC) 是一种基于企业内个人用户的角色来管理对计算机或网络资源的访问的方法。 在此上下文中,权限是单个用户执行特定任务的能力, 例如查看、创建或修改文件。

被启用之后,RBAC(基于角色的访问控制)使用 rbac.authorization.k8s.io API 组来驱动鉴权决策,从而允许管理员通过 Kubernetes API 动态配置权限策略。

要启用 RBAC,请使用 --authorization-mode = RBAC 启动 API 服务器。

查看k8s是否开启了RBAC

查看默认配置文件的授权配置即可

cat /etc/kubernetes/manifests/kube-apiserver.yaml | grep authorization

RBAC三要素

  • Subjects,也就是主体。可以是开发人员、集群管理员这样的自然人,也可以是- 系统组件进程,或者是 Pod 中的逻辑进程;在k8s中有以下三种类型:
  • User Account:用户,这是有外部独立服务进行管理的,管理员进行私钥的分配,用户可以使用 KeyStone或者 Goolge 帐号,甚至一个用户名和密码的文件列表也可以。对于用户的管理集群内部没有一个关联的资源对象,所以用户不能通过集群内部的 API 来进行管理
  • Group:组,这是用来关联多个账户的,集群中有一些默认创建的组,比如cluster-admin。
  • Service Account:服务帐号,通过Kubernetes API 来管理的一些用户帐号,和 namespace 进行关联的,适用于集群内部运行的应用程序,需要通过 API 来完成权限认证,所以在集群内部进行权限操作,都需要使用到 ServiceAccount,这也是本文的重点。
  • API Resource,也就是请求对应的访问目标。在 Kubernetes 集群中也就是各类资源,Pod,Deployment等;
  • Verbs,对应为请求对象资源可以进行哪些操作,包括但不限于"get", “list”, “watch”, “create”, “update”, “patch”, “delete”,"deletecollection"等。

RBAC四对象

Role:包含一组代表相关权限的规则。 这些权限是纯粹累加的(不存在拒绝某操作的规则)。

RoleBinding:将角色中定义的权限赋予一个或者一组用户。 它包含若干主体(用户、组或服务账户)的列表和对这些主体所获得的角色的引用。 RoleBinding 在指定的名字空间中执行授权。RoleBinding 也可以引用 ClusterRole

ClusterRole:包含一组代表相关权限的规则。 这些权限是纯粹累加的(不存在拒绝某操作的规则)。

ClusterRoleBinding:将角色中定义的权限赋予一个或者一组用户。 它包含若干 主体(用户、组或服务账户)的列表和对这些主体所获得的角色的引用。 ClusterRoleBinding 在集群范围执行授权。

资源resources

如果你不记得资源有哪些了,可以查看clusterrole admin的。例如,查看pod的资源。

kubectl get clusterrole admin -o yaml | grep pod

模版

Role

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" 标明 core API 组
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

RoleBinding

下面的例子中的 RoleBinding 将 “pod-reader” Role 授予在 “default” 名字空间中的用户 “lady_killer9”。 这样,用户 “lady_killer9” 就具有了读取 “default” 名字空间中所有 Pod 的权限。

apiVersion: rbac.authorization.k8s.io/v1
# 此角色绑定允许 "lady_killer9" 读取 "default" 名字空间中的 Pod
# 你需要在该命名空间中有一个名为 “pod-reader” 的 Role
kind: RoleBinding
metadata:
  name: read-pods
  namespace: default
subjects:
# 你可以指定不止一个“subject(主体)”
- kind: User
  name: lady_killer9 # "name" 是区分大小写的
  apiGroup: rbac.authorization.k8s.io
roleRef:
  # "roleRef" 指定与某 Role 或 ClusterRole 的绑定关系
  kind: Role        # 此字段必须是 Role 或 ClusterRole
  name: pod-reader  # 此字段必须与你要绑定的 Role 或 ClusterRole 的名称匹配
  apiGroup: rbac.authorization.k8s.io

ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  # "namespace" 被忽略,因为 ClusterRoles 不受名字空间限制
  name: secret-reader
rules:
- apiGroups: [""]
  # 在 HTTP 层面,用来访问 Secret 资源的名称为 "secrets"
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

ClusterRoleBinding

要跨整个集群完成访问权限的授予,你可以使用一个 ClusterRoleBinding。 下面的 ClusterRoleBinding 允许 “manager” 组内的所有用户访问任何名字空间中的 Secrets。

apiVersion: rbac.authorization.k8s.io/v1
# 此集群角色绑定允许 “manager” 组中的任何人访问任何名字空间中的 Secret 资源
kind: ClusterRoleBinding
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager      # 'name' 是区分大小写的
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

实战

创建ServiceAccount

在名字为app-team1的namespace下创建一个名为cicd-token的serviceAccount

命令

kubectl create ns app-team1
kubectl create sa cicd-token -n app-team1

结果

创建ClusterRole

创建一个名为deployment-clusterrole的clusterrole,该clusterrole只允许创建Deployment、Daemonset、Statefulset的create操作。

将前面的模版改一下,deployment-clusterrole.yaml内容如下:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: deployment-clusterrole
rules:
- apiGroups: [""]
  resources: ["deployments","daemonsets","statefulsets"]
  verbs: ["create"]

命令

kubectl create -f deployment-clusterrole.yaml

结果

创建RoleBinding

创建一个RoleBinding,名为deployment-rolebinding,将上面的clusterrole绑定到serviceaccount上。

deployment-rolebinding.yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: deployment-rolebinding
  namespace: app-team1
subjects:
- kind: ServiceAccount
  name: cicd-token
  namespace: app-team1
roleRef:
  # "roleRef" 指定与某 Role 或 ClusterRole 的绑定关系
  kind: ClusterRole
  name: deployment-clusterrole
  apiGroup: rbac.authorization.k8s.io

命令

kubectl create -f deployment-rolebinding.yaml

结果

删除

删除使用delete即可,例如,删除前面创建的rolebinding和clusterrole

命令

kubectl delete rolebinding deployment-rolebinding -n app-team1
kubectl delete clusterrole deployment-clusterrole

结果

参考

k8s-鉴权概述

k8s-RBAC

阿里云-k8s安全之访问控制

更多k8s相关内容,请看文章:k8s学习-思维导图与学习笔记

相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。     相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
存储 Kubernetes 持续交付
k8s学习
【10月更文挑战第1天】
755 4
|
关系型数据库 MySQL Docker
《docker高级篇(大厂进阶):5.Docker-compose容器编排》包括是什么能干嘛去哪下、Compose核心概念、Compose使用三个步骤、Compose常用命令、Compose编排微服务
《docker高级篇(大厂进阶):5.Docker-compose容器编排》包括是什么能干嘛去哪下、Compose核心概念、Compose使用三个步骤、Compose常用命令、Compose编排微服务
971 24
|
关系型数据库 MySQL Docker
《docker高级篇(大厂进阶):5.Docker-compose容器编排》包括是什么能干嘛去哪下、Compose核心概念、Compose使用三个步骤、Compose常用命令、Compose编排微服务
《docker高级篇(大厂进阶):5.Docker-compose容器编排》包括是什么能干嘛去哪下、Compose核心概念、Compose使用三个步骤、Compose常用命令、Compose编排微服务
927 6
|
Kubernetes 应用服务中间件 nginx
k8s学习--YAML资源清单文件托管服务nginx
k8s学习--YAML资源清单文件托管服务nginx
544 2
k8s学习--YAML资源清单文件托管服务nginx
|
Kubernetes 监控 测试技术
k8s学习--基于Ingress-nginx实现灰度发布系统
k8s学习--基于Ingress-nginx实现灰度发布系统
927 2
k8s学习--基于Ingress-nginx实现灰度发布系统
|
存储 Kubernetes 调度
|
Kubernetes API 调度
k8s学习--pod的所有状态详解(图例展示)
k8s学习--pod的所有状态详解(图例展示)
2258 2
|
存储 Kubernetes 调度
K8S中的核心概念
【10月更文挑战第26天】云原生环境下的安全问题易被忽视,导致潜在风险。应用层渗透测试和漏洞扫描是检测安全的关键,尤其是对于CVE漏洞的修复。然而,常见误解认为安全由外部防护处理且不易引入问题。
|
Kubernetes 固态存储 调度
k8s学习--如何控制pod调度的位置
k8s学习--如何控制pod调度的位置
335 0
|
存储 Kubernetes 调度
k8s学习--k8s群集部署zookeeper应用及详细解释
k8s学习--k8s群集部署zookeeper应用及详细解释
1349 0

推荐镜像

更多