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学习-思维导图与学习笔记

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
打赏
0
0
0
0
6
分享
相关文章
k8s学习
【10月更文挑战第1天】
148 4
《docker高级篇(大厂进阶):5.Docker-compose容器编排》包括是什么能干嘛去哪下、Compose核心概念、Compose使用三个步骤、Compose常用命令、Compose编排微服务
《docker高级篇(大厂进阶):5.Docker-compose容器编排》包括是什么能干嘛去哪下、Compose核心概念、Compose使用三个步骤、Compose常用命令、Compose编排微服务
139 24
《docker高级篇(大厂进阶):5.Docker-compose容器编排》包括是什么能干嘛去哪下、Compose核心概念、Compose使用三个步骤、Compose常用命令、Compose编排微服务
《docker高级篇(大厂进阶):5.Docker-compose容器编排》包括是什么能干嘛去哪下、Compose核心概念、Compose使用三个步骤、Compose常用命令、Compose编排微服务
193 6
k8s学习--基于Ingress-nginx实现灰度发布系统
k8s学习--基于Ingress-nginx实现灰度发布系统
176 2
k8s学习--基于Ingress-nginx实现灰度发布系统
K8S中的核心概念
【10月更文挑战第26天】云原生环境下的安全问题易被忽视,导致潜在风险。应用层渗透测试和漏洞扫描是检测安全的关键,尤其是对于CVE漏洞的修复。然而,常见误解认为安全由外部防护处理且不易引入问题。
k8s学习--pod的所有状态详解(图例展示)
k8s学习--pod的所有状态详解(图例展示)
431 1
k8s学习--k8s群集部署zookeeper应用及详细解释
k8s学习--k8s群集部署zookeeper应用及详细解释
141 0
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等