提升CKA考试胜算:一文带你全面了解RBAC权限控制!

RBAC概述

RBAC引入了四个新的顶级资源对象。RoleClusterRoleRoleBindingClusterRoleBinding。同其他 API 资源对象一样,用户可以使用 kubectl 或者 API 调用等 方式操作这些资源对象。kubernetes集群相关所有的交互都通过apiserver来完成,对于这样集中式管理的系统来说,从1.6版本起,K8S默认启用RBAC访问控制策略,目前RBAC已作为稳定的功能,通过启动文件kube-apiserver.service中的-authorization-mode=RBAC来启用RABC。
在RBAC API中,通过如下步骤进行授权:

  1. 定义角色:在定义角色时会指定此角色对于资源访问控制的规则;
  2. 绑定角色:将主体与角色进行绑定,对用户进行访问授权;

提升CKA考试胜算:一文带你全面了解RBAC权限控制!_第1张图片

RBAC资源对象

在 Kubernetes 中,RBAC 是一种强大的访问控制机制,用于管理对集群资源的访问权限。RBAC 可以帮助管理员精确地控制用户、ServiceAccount 或其他实体对 Kubernetes API 中资源的操作权限。RBAC 基于角色的授权模型使得管理员可以定义角色和角色绑定,从而实现对不同用户或实体的访问权限控制。
RBAC 由四个基本概念组成:

  • 角色(Role):角色定义了一组操作权限,例如对某个命名空间下资源的读取、创建或删除等操作。
  • 角色绑定(RoleBinding):角色绑定将特定的角色授予 UserGroup 或者 ServiceAccount,从而赋予它们相应的权限。
  • 集群角色(ClusterRole):类似于角色,但作用范围更广,可以授权对整个集群中资源的操作权限。
  • 集群角色绑定(ClusterRoleBinding):将集群角色绑定给 UserGroup 或者 ServiceAccount,授予它们在整个集群范围内的权限。

角色

一个角色就是一组权限的集合,这里的权限都是许可形式的,不存在拒绝的规则。Role 总是用来在某个名字空间内设置访问权限; 在你创建 Role 时,你必须指定该 Role 所属的名字空间。
与之相对,ClusterRole 则是一个集群作用域的资源。这两种资源的名字不同(Role 和 ClusterRole) 是因为 Kubernetes 对象要么是名字空间作用域的,要么是集群作用域的,不可两者兼具。
ClusterRole 有若干用法。你可以用它来:

  1. 定义对某名字空间域对象的访问权限,并将在个别名字空间内被授予访问权限;
  2. 为名字空间作用域的对象设置访问权限,并被授予跨所有名字空间的访问权限;
  3. 为集群作用域的资源定义访问权限。

如果你希望在名字空间内定义角色,应该使用 Role; 如果你希望定义集群范围的角色,应该使用 ClusterRole。

Role 示例
  • 命令方式创建

如果忘记了命令方式,也可以通过kubectl create role --help查阅帮助,如下图:

提升CKA考试胜算:一文带你全面了解RBAC权限控制!_第2张图片

kubectl create role pod-reader \
--verb=get,list,watch \
--resource=pods 
  • verb:是指定这个角色包含哪些操作,如get、list、watch
  • resource:是指这个角色能操作哪些资源对象,如pods
  • resource-name:指定对特定资源实例的访问权限。
  • 资源清单方式创建

下面是一个位于 default 名字空间的 Role 的示例,可用来授予对 Pod 的读访问权限:

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

ClusterRole 同样可以用于授予 Role 能够授予的权限。 因为 ClusterRole 属于集群范围,所以它也可以为以下资源授予访问权限:

  • 集群范围资源(比如节点(Node))
  • 非资源端点(比如 /healthz)
  • 跨名字空间访问的名字空间作用域的资源(如 Pod)

比如,你可以使用 ClusterRole 来允许某特定用户执行 kubectl get pods --all-namespaces
下面是一个 ClusterRole 的示例,可用来为任一特定名字空间中的 Secret 授予读访问权限, 或者跨名字空间的访问权限(取决于该角色是如何绑定的):

  • 命令行创建
kubectl create clusterrole  secret-reader \
--verb=get,watch,list \
--resource=secrets
  • 资源清单创建
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"]

角色绑定和集群角色绑定

角色绑定(Role Binding)是将角色中定义的权限赋予一个或者一组用户。 它包含若干主体(Subject)(用户、组或服务账户)的列表和对这些主体所获得的角色的引用。RoleBinding 在指定的名字空间中执行授权,而 ClusterRoleBinding 在集群范围执行授权。
一个 RoleBinding 可以引用同一的名字空间中的任何Role。 或者,一个RoleBinding可以引用某 ClusterRole并将该 ClusterRole 绑定到 RoleBinding 所在的名字空间。 如果你希望将某 ClusterRole绑定到集群中所有名字空间,你要使用ClusterRoleBinding

RoleBinding 示例

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

  • 命令行创建
 kubectl create rolebinding read-pods \
 --role=pod-reader \
 --user=jance \
 --namespace=default

详细清楚可以使用帮助文件 kubectl create rolebinding --help

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

ClusterRoleBinding 示例

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

  • 命令行创建
kubectl create clusterrolebinding read-secrets-global\
--group=manager \
--clusterrole=secret-reader 
  • 资源清单创建
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

资源

Kubernetes API 中,大多数资源都是使用对象名称的字符串表示来呈现与访问的。 例如,对于Pod应使用 pods。 RBAC 使用对应 API 端点的 URL 中呈现的名字来引用资源。 有一些Kubernetes API 涉及子资源(subresource),例如 Pod 的日志。 对 Pod 日志的请求看起来像这样:

GET /api/v1/namespaces/{namespace}/pods/{name}/log

在这里,pods 对应名字空间作用域的 Pod 资源,而 log 是 pods 的子资源。 在 RBAC 角色表达子资源时,使用斜线(/)来分隔资源和子资源。 要允许某主体读取 pods 同时访问这些 Pod 的 log 子资源,你可以这样写:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-and-pod-logs-reader
rules:
- apiGroups: [""]
  resources: ["pods", "pods/log"]
  verbs: ["get", "list"]

对于某些请求,也可以通过 resourceNames 列表按名称引用资源。 在指定时,可以将请求限定为资源的单个实例。 下面的例子中限制可以 get 和 update 一个名为 my-configmap 的 ConfigMap:

  • 命令行创建
kubectl create role configmap-updater \
--verb=update,get \
--resource=configmaps \
--resource-name=my-configmap
  • 资源清单创建
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: configmap-updater
rules:
- apiGroups: [""]
  # 在 HTTP 层面,用来访问 ConfigMap 资源的名称为 "configmaps"
  resources: ["configmaps"]
  resourceNames: ["my-configmap"]
  verbs: ["update", "get"]

主体

RoleBinding或者ClusterRoleBinding可绑定角色到某主体(Subject) 上。 主体可以是组,用户或者服务账户。K8s的用户分两种,一种是普通用户,一种是ServiceAccount(服务账户)。

普通用户

普通用户是假定被外部或独立服务管理的。管理员分配私钥。平时常用的kubectl命令都是普通用户执行的。如果是用户需求权限,则将Role与User(或Group)绑定(这需要创建User/Group),是给用户使用的。

ServiceAccount(服务账户)

ServiceAccount(服务帐户)是由KubernetesAPI管理的用户。它们绑定到特定的命名空间,并由API服务器自动创建或通过API调用手动创建。

服务帐户与存储为Secrets的一组证书相关联,这些凭据被挂载到pod中,以便集群进程与Kubernetes API通信。(登录dashboard时我们使用的就是ServiceAccount)

如果是程序需求权限,将Role与ServiceAccount指定(这需要创建ServiceAccount并且在deployment中指定ServiceAccount),是给程序使用的。

下面示例是RoleBinding中的片段,仅展示其subjects的部分。

subjects:
- kind: User
  name: "[email protected]"
  apiGroup: rbac.authorization.k8s.io
  • 对于名称为 frontend-admins 的用户组:
subjects:
- kind: Group
  name: "frontend-admins"
  apiGroup: rbac.authorization.k8s.io
  • 对于在任何名字空间中的服务账户:
subjects:
- kind: Group
  name: system:serviceaccounts
  apiGroup: rbac.authorization.k8s.io

CKA中的真题

提升CKA考试胜算:一文带你全面了解RBAC权限控制!_第3张图片

Context:
为部署流水线创建一个新的 ClusterRole 并将其绑定到范围为特定的 namespace 的特ServiceAccount。
Task:
创建一个名为 deployment-clusterrole 的clusterrole,该 clusterrole 只允许Deployment、Daemonset、Statefulset 具有create 权限,在现有的namespace app-team1中创建一个名为 cicd-token 的新ServiceAccount。限于namespace app-team1 中,将新的 ClusterRole deployment-clusterrole 绑定到新的 ServiceAccount cicd-token。

这题考点是对RBAC授权模型的理解。可以参考官网文档有关RBAC的资料或者使用-h帮助。

#考试时务必执行,切换集群。
kubectl config use-context k8s

#创建一个名称为deployment-clusterrole的clusterrole

kubectl create clusterrole deployment-clusterrole \
-verb=create -resource=deployments,daemonsets,statefulsets

#在命名空间app-team1创建一个名为cicd-token
kubectl create sa  cicd-token -n app-team1

#题目中写了“限于 namespace app-team1 中”,则创建 rolebinding。没有写的话,则创建 clusterrolebinding。
kubectl create rolebinding cicd-token-rolebinding \
--clusterrole=clusterrole 
--serviceaccount=app-team1:cicd-token --namespace=app-team1

# rolebinding 后面的名字 cicd-token-rolebinding 随便起的,因为题目中没有要求,如果题目中有要求,就不能随便起了。

可以通过下面的命令检查,

kubectl -n app-team1 describe rolebindings cicd-token-rolebinding

出现如下图的证明已经创建成功。
提升CKA考试胜算:一文带你全面了解RBAC权限控制!_第4张图片

你可能感兴趣的:(K8S,CKA,kubernetes,RBAC,CKA,云原生,CKA真题)