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

Posted lady_killer9

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了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,对应为请求对象资源可以进行哪些操作,包括增删改查、list、get、watch 等。

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

以上是关于k8s学习-基于角色的权限控制RBAC(概念,模版,创建,删除等)的主要内容,如果未能解决你的问题,请参考以下文章

基于K8s Jenkins CICD和RBAC角色权限控制

角色数据维护基于RBAC

云原生 kubernetes - 基于角色的访问控制RBAC

「走进k8s」Kubernetes1.15.1的RBAC(28)

了解K8S的RBAC

k8s学习-CKA真题-基于角色的访问控制-RBAC