Page tree

如需转载请标注内容地址为: https://wiki.shileizcc.com/confluence/display/KUB/Kubernetes+RBAC

Skip to end of metadata
Go to start of metadata




Kubernetes RBAC

RBAC (Role-Based Access Control) 基于角色的访问控制。

在 v1.5 中引入,在 v1.6 版本时升级为 Beta 版本,成为 kubeadm 安装方式下的默认选项,足见其重要程度。相对于其他的访问控制方式,新的 RBAC 具有如下优势。

  • 对集群中的资源和非资源权限均有完整的覆盖。
  • 整个 RBAC 完全由几个 API 对象完成,同其他 API 对象一样,可以用 kubectl 或 API 进行操作。
  • 可以在运行时进行调整,无需重新启动 API Server。

要使用 RBAC 授权模式,则需要在 API Server 的启动参数中加入 --authorization-mode=RBAC。

下面对 RBAC 的原理和用法进行说明。

RBAC 的 API 资源对象说明

RBAC 引入了 4 个新的顶级资源对象:Role、ClusterRole、RoleBinding 和 ClusterRoleBinding。同其他 API 资源对象一样,用户可以使用 kubectl 或者 API 调用等方式操作这些资源对象。

角色(Role)

一个角色就是一组权限的集合,这里的权限都是许可模式,不存在拒绝的规则。在一个命名空间中,可以用角色来定义一个角色,如果是集群级别的,就需要使用 ClusterRole 了。

角色只能对命名空间内的资源进行授权,下面的例子中定义的角色具有读取 Pod 的权限:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" 空字符串,表示核心 API 群
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

reule 中的参数说明如下:

  • apiGroups:支持的 API 组列表,例如 “apiVersion: batch/v1” “apiVersion: extensions/v1beta1” "apiVersion: apps/v1beta1" 等。
  • resource:支持的资源对象列表,例如 pods、deployments、jobs 等。
  • verbs:对资源对象的操作方法列表,例如 get、watch、list、delete、replace、patch 等。

集群角色(Cluster Role)

集群角色除了具有和角色一致的命名空间内资源的管理能力,因其集群级别的范围,还可以用于以下特殊元素的授权。

  • 集群范围的资源,例如 Node(节点)。
  • 非资源型的路径,例如 “/healthz”。
  • 包含全部命名空间的资源,例如 pods(用于 kubectl get pods --all-namespaces 这样的操作授权)。

下面的集群角色可以让用户有权访问任意一个或所有命名空间的 secrets(视其保定方式而定):

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  # ClusterRole 不授权与命名空间,所以忽略了 namespace 的定义。
rules:
- apiGroups: [""] # "" 空字符串,表示核心 API 群
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

角色绑定(RoleBinding)和集群角色绑定(ClusterRoleBinding)

角色绑定或集群角色绑定用来把一个角色绑定到一个目标上,保定目标可以是 User(用户)、Group(组)或者 Service Account。使用 RoleBinding 为某个命名空间授权,使用 ClusterRoleBinding 为集群范围内授权。

RoleBinding 可以引用 Role 进行授权。下例中的 RoleBinding 将在 default 命名空间中把 pod-reader 角色授权用户 jane,这一操作让 jane 可以读取 default 命名空间中的 Pod:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: default
  namespace: default
subjects:
- kind: User
  name: jane
  apiGroups: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroups: rbac.authorization.k8s.io

RoleBinding 也可以引用 ClusterRole,对属于同一命名空间内 ClusterRole 定义的资源主体进行授权。一种常见的做法是集群管理员为集群范围预先定义好了一组角色(ClusterRole),然后在多个命名空间中重复使用这些 ClusterRole。

例如下面的例子,虽然 secret-reader 是一个集群角色,但是因为使用了 RoleBinding,所以 dave 只能读取 development 命名空间的 secret:

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-secrets
  namespace: development # 集群角色中,只有在 development namespace 中的权限才能赋予 dave
subjects:
- kind: User
  name: dave
  apiGroups: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroups: rbac.authorization.k8s.io

集群角色绑定中的角色只能是集群角色,用于进行集群级别或者对所有命名空间都生效的授权。下面的例子允许 manager 组的用户读取任意 namespace 中的 secret:

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: read-secrets-global
subjects:
- kind: Group
  name: manager
  apiGroups: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroups: rbac.authorization.k8s.io

下图展示了对 Pod 的 get/watch/list 操作进行授权的 Role 和 RoleBinding 逻辑关系。

对资源的引用方式

多数资源可以用其名称的字符串来表达,也就是 Endpoint 中的 URL 相对路径,例如 pods。然而,某些 Kubernetes API 包含下级资源,例如 Pod 的日志(logs)。Pod 日志的 Endpoint 是 GET /api/v1/namespaces/{namespaces}/pod/{name}/log。

在这个例子中,Pod 是一个 namespace 内的资源,log 就是一个下级资源。要在一个 RBAC 角色中体现,则需要用斜线 “/” 来分隔资源和下级资源。若想授权让某个主题同时能够读取 Pod 和 Pod log,则可以配置 resources 为一个数组:

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

可想而知,resourceName 这种用法对 list、watch、create 或 deletecollection 操作是无效的,这是因为必须要通过 URL 进行鉴权,而资源名称在 list、watch、create 或 deletecollection 请求中只是请求 Body 数据的一部分。

下面对场景的角色(Role)和角色绑定(RoleBinding)给出示例,提供参考用法。

常用的角色(Role)示例

注意:下面的例子只显示了 rules 部分的内容。

1、允许读取核心 API 组中的 Pod 资源:

rule:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

2、允许读写 “extensions” 和 “apps” 两个 API 组中的 “deployment” 资源:

rule:
- apiGroups: ["extensions", "apps"]
  resources: ["deployments"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

3、允许读取 “pods” 及读写 “jobs”:

rule:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]
- apiGroups: ["batch", "extensions"]
  resources: ["jobs"]
  verbs: ["get", "list", "watch", "create", "update", "patch", "delete"]

4、允许读取一个名为 “my-config” 的 ConfigMap(必须绑定到一个 RoleBinding 来限制到一个 namespace 下的 ConfigMap):

rule:
- apiGroups: [""]
  resources: ["configmaps"]
  resourceNames: ["my-config"]
  verbs: ["get"]

5、读取核心组的 “node” 资源(Node 属于集群级的资源,所以必须存在与 ClusterRole 中,并使用 ClusterRoleBinding 进行绑定):

rule:
- apiGroups: [""]
  resources: ["nodes"]
  verbs: ["get", "list", "watch"]

6、允许对非资源端点 "/healthz" 及其所有子路径进行 “GET” 和 “POST” 操作(必须使用 ClusterRole 和 ClusterRoleBinding):

rule:
- nonResourceURLs: ["/healthz", "/healthz/*"]
  verbs: ["get", "post"]

常用的角色绑定(RoleBinding)示例

注意:下面的例子中只包含 subjects 部分的内容。

1、用户名 “alice@example.com”:

subjects:
- kind: User
  name: "alice@example.com"
  apiGroups: rbac.authorization.k8s.io

2、组名 “frontend-admins”

subjects:
- kind: Group
  name: "frontend-admins"
  apiGroups: rbac.authorization.k8s.io

3、kube-system 命名空间中的默认 Service Account:

subjects:
- kind: ServiceAccount
  name: default
  namespace: kube-system

4、"qa" 命名空间中的所有 Service Account:

subjects:
- kind: Group
  name: system:serviceaccounts:qa
  apiGroups: rbac.authorization.k8s.io

5、所有 Service Account:

subjects:
- kind: Group
  name: system:serviceaccounts
  apiGroups: rbac.authorization.k8s.io

6、所有认证用户(v1.5以上版本)

subjects:
- kind: Group
  name: system:authenticated
  apiGroups: rbac.authorization.k8s.io

7、所有未认证用户(v1.5以上版本)

subjects:
- kind: Group
  name: system:unauthenticated
  apiGroups: rbac.authorization.k8s.io

8、全部用户(v1.5以上版本)

subjects:
- kind: Group
  name: system:serviceaccounts:qa
  apiGroups: rbac.authorization.k8s.io
- kind: Group
  name: system:unauthenticated
  apiGroups: rbac.authorization.k8s.io

默认的角色和角色绑定

API Service 会创建一套默认的 ClusterRole 和 ClusterRoleBinding 对象,其中很多是以 “system” 为前缀的,以表明这些资源属于基础架构,对这些对象的改动可能造成集群故障。举例来说,system:node 这个 ClusterRole 为 kubelet 定义了权限,如果这个集群角色被改动了,则 kubelet 会停止工作。

所有默认的 ClusterRole 和 RoleBinding 都会用标签 kubernetes.io/bootstapping=reac-defaults 进行标记。

下面对默认的 ClusterRole 和 RoleBingding 对象进行说明。

对系统角色的说明如下表

默认的 ClusterRole默认的 ClusterRoleBinding描述
system:basic-usersystem:authenticated让用户能够读取自身的信息。
system:discoverysystem:authenticated对 API 发现 Endpoint 的只读访问,用于 API 级别的发现和协商。
system:public-info-viewersystem:authenticated 和 system:unathenticated 组允许读取集群的非敏感信息

对用户角色的说明如下表

有些默认角色不是以 "system:" 为前缀的,这部分角色是针对用户的。其中包含超级用户角色(cluster-admin),有的用于集群一级的角色(cluster-status),还有针对 namespace 的角色(admin, edit, view)。

用户角色表

默认的 ClusterRole默认的 ClusterRoleBinding描述
cluster-adminsystem:masters 组让超级用户可以对任何资源执行任何操作。如果在 ClusterRoleBinding 中使用,则影响的是整个集群的所有 namespace 中的任何资源:如果使用的是 RoleBinding,则能控制这一绑定的 namespace 中的资源,还包括 namespaces 本身。
cluster-statusNone可以对基础集群状态信息进行只读访问。
adminNone允许 admin 访问,可以限制在一个 namespace 中使用 RoleBinding,如果在 RoleBinding 中使用,则允许对 namespace 中的大多数资源进行读写访问,其中包含创建角色和角色绑定的能力。这一角色不允许操作 namespace 本身,也不能写入资源限额。
editNone允许对命名空间内的大多数资源进行读写操作,不允许查看或修改角色,以及角色绑定。
viewNone允许对多数对象进行读写操作,但是对角色、角色绑定以及 Secret 是不可访问的。

核心 Master 组件角色说明表

默认的 ClusterRole默认的 ClusterRoleBinding描述
system:kube-schedulersystem:kube-scheduler 用户能够访问 kube-scheduler 组件所需的资源。
system:kube-controller-managersystem:kube-controller-manager 用户能够访问 kube-controller-manager 组件所需的资源。不同的控制所需的不同权限。
system:nodesystem:nodes 组允许访问 kubelet 所需的资源,包括对 secret 的读取,以及对 Pod 的写入。未来会把上面的两个权限限制在分配到本 Node 的对象上。今后的鉴权过程,kubelet 必须以 system:node 及一个 system:node 形式的用户名进行。参看:https://pr.k8s.io/40476。
system:node-proxiersystem:kube-proxy 用户允许访问 kube-proxy 所需的资源。
system:kube-schedulersystem:kube-scheduler 用户能够访问 kube-scheduler 组件所需的资源。

其他组件角色说明表

默认的 ClusterRole默认的 ClusterRoleBinding描述
system:auth-delegatorNode允许对授权和认证进行托管,通常用于附加的 API 服务器。
system:heapsterNoneHeapster 组件的角色。
system:kube-aggregatorNonekube-agggregator 的角色。
system:kube-dns在 kube-system namespace 中 kube-dns 的 Service Accountkube-dns 的角色。
system:node-bootstrapperNone允许访问 kubelet TLS 启动所需的资源。
system:node-problem-detectorNone允许访问 node-problem-detector 组件所需的资源。
system:persistent-volume-provisionerNone允许访问多数动态卷供给所需的资源。

Controller 角色说明表

需要赋予的角色
system:controller:attachdetach-controller
system:controller:certificate-controller
system:controller:cronjob-controller
system:controller:daemon-set-controller
system:controller:deployment-controller
system:controller:disruption-controller
system:controller:endpoint-controller
system:controller:generic-garbage-collector
system:controller:horizontal-pod-autoscaler
system:controller:job-controller
system:controller:namespace-controller
system:controller:controller
system:controller:persistent-volume-binder
system:controller:pod-garbage-conllector
system:controller:replicaset-controller
system:controller:replication-controller
system:controller:resourcequota-controller
system:controller:route-controller
system:controller:service-account-controller
system:controller:service-controller
system:controller:statefulset-controller
system:controller:ttl-controller

Kubernetes Controller Manager 负责的是核心控制流。如果用 --use-service-account-credentials 调用,则每个控制过程都会使用不同的 Service Account 启动,因此就有了对应各个控制过程的角色。前缀是 system:controller。如果 Controlle Manager 没有用 --use-service-account-credentials 启动参数,则将使用自己的凭据允许各个控制流,这就需要为该凭据授予所有相关角色。

授权注意事项: 预防提权和授权初始化

RBAC API 拒绝用户利用编辑角色或者角色绑定的方式进行提权。这一限制是在 API 层面作出的,因此即使 RBAC 没有启用也仍然有效。

用户只能在拥有一个角色的所有权限,且与该角色的生效范围一致(如果是集群角色,则是集群范围;如果是普通角色,则可能是同一 namespace 或全集群)的前提下,才能对角色进行创建和更新。例如用户 user-1 没有列出集群中所有 secret 的权限,就不能创建具有这一权限的集群角色。要让一个用户能够创建或更新角色,需要:

  • 为其授权一个允许 创建/更新 Role 或 ClusterRole 资源对象的角色。
  • 为用户授权角色,要覆盖该用户所能控制的所有权限范围。用户如果尝试创建超出其自身权限的角色或者集群角色,则该 API 调用会被禁止。

如果一个用户的权限包含了一个角色的所有权限,那么就可以为其创建和更新角色绑定(要求同样的作用范围);或者如果被授予了针对某个角色的绑定授权,则也有权完成此操作。例如,如果用户 user-1 没有列出集群内所有 secret 的权限,就无法为一个具有这样权限的角色创建集群角色绑定。要使用户能够创建、更新这一角色绑定,则需要有如下做法。

  • 为其授权一个允许创建和更新角色绑定或者集群角色绑定的角色。
  • 为其授权绑定某一个角色的权限,有隐式或显式两种方法。
    隐式:让其具有所有该角色的权限。
    显式:为用户授权针对该角色(或集群角色)的绑定操作的权限。

例如,下面的集群角色和角色绑定能让 user-1 为其他用户在 user-1-namespace 中授予 admin、edit 及 view 角色:

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: role-grantor
rules:
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["rolebindings"]
  verbs: ["create"]
- apiGroups: ["rbac.authorization.k8s.io"]
  resources: ["clusterroles"]
  verbs: ["bind"]
  resourceNames: ["admin", "edit", "view"]
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: role-grantor-binding
  namespace: user-1-namespace
roleRef:
  apiGroups: rbac.authorization.k8s.io
  kind: ClusterRole
  name: role-grantor
subjects:
- apiGroups: rbac.authorization.k8s.io
  kind: User
  name: user-1

在进行第一个角色和角色绑定时,必须让初始用户具备其尚未被授予的权限,要进行初始的角色和角色绑定设置,有以下两种办法。

  • 使用属于 system:masters 组的身份,这一群组默认具有 cluster-admin 这一超级角色的绑定。
  • 如果 API Service 以 --insecure-port 参数运行,则客户端通过这个非安全端口进行接口调用,这一端口没有认证鉴权的限制。

对 Service Account 的权限管理

默认的 RBAC 策略为控制平台组件、节点和控制器授予有限范围的权限,但是在 “kube-system” 之外的 Service Account 是没有任何权限的(除了所有认证用户都具有的 discovery 权限)。

这就要求用户为 Service Account 赋予所需的权限。细粒度的角色分配能够提高安全性,但也会提高管理成本。粗放的授权方式可能会给 Service Account 多余的权限,但会更容易管理。

下面的实践以安全性递减的方式排序。

1、为一个应用专属的 Service Account 授权(最佳实践)。

这个应用需要在 Pod 的 Spec 中指定一个 serviceAccountName,用 API、Application Manifest、kubectl create serviceaccount 命令等创建 Service Account,例如为 “my-namespace” 中的 “my-sa" Service Account 授权只读权限:(需要有 my-namespace 这个命名空间才可以创建否则会报错)

$ kubectl create rolebinding my-sa-view \
  --clusterrole=view \
  --serviceaccount=my-namespace:my-sa \
  --namespace=my-namespace

2、为一个 namespace 中的 ”default“ Service Account 授权。

如果一个应用没有指定 serviceAccountName,则会使用 ”default“ Service Account。注意,赋给 ”default“ Service Account 的授权会让所有没指定 serviceAccountName 的 Pod 都具有这些权限。

例如在 ”my-namespace“ 命名空间里为 ”default“ Service Account 赋予只读权限:

$ kubectl create rolebinding default-view \
  --clusterrole=view \
  --serviceaccount=my-namespace:default \
  --namespace=my-namespace

目前不少 Add-Ons 在 ”kube-system“ 命名空间中用 ”default“ Service Account 运行。要让这些 Add-Ons 能够使用超级用户权限,则可以把 cluster-admin 授权赋予 ”kube-system“ 的 ”default“ Service Account。注意,这一操作意味着 ”kube-system" 命名空间包含了通向 API 超级用户的捷径:

$ kubectl create clusterrolebinding add-on-cluster-admin \
  --clusterrole=cluster-admin \
  --serviceaccount=kube-system:default

3、为命名空间内的所有 Service Account 授予一个角色。

如果希望在一个命名空间里,任何 Service Account 的应用都具有一个角色,则可以为这一命名空间的 Service Account 群组进行授权。

例如,为 “my-namespace" 命名空间中的所有 Service Account 赋予只读权限:

$ kubectl create rolebinding serviceaccounts-view \
  --clusterrole=view \
  --group=system:serviceaccounts:my-namespace \
  --namespace=my-namespace

4、为集群范围内的所有 Service Account 授予一个低权限角色(不推荐)。

如果不想为每个命名空间管理权限,则可以把一个集群级别的角色赋给所有 Service Account。

例如,为所有命名空间中的所有 Service Account 授予只读权限:

$ kubectl create clusterrolebinding serviceaccounts-view \
  --clusterrole=view \
  --group=system:serviceaccounts

5、为所有 Service Account 授予超级用户权限(强烈不建议这样设置)。

如果完全不在意权限,则可以把超级用户权限分配给每一个 Service Account。

注意:折让所有具有读取 Secret 权限的用户都可以创建 Pod 来访问超级用户的专属权限:

$ kubectl create clusterrolebinding serviceaccounts-cluster-admin \
  --clusterrole=cluster-admin \
  --group=system:serviceaccounts

使用 kubectl 命令行工具创建资源对象

除了使用 yaml 配置文件来创建这些资源对象,也可以直接使用 kubectl 命令行工具对它们进行创建。下面通过几个例子进行说明。

1、在命名空间 acme 内为用户 bob 授权 admin  ClusterRole:

$ kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme

2、在命名空间 acme 内为名为 myapp 的 Service Account 授予 view ClusterRole:

$ kubectl create rolebinding myapp-view-binding --clusterrole=view --serviceaccount=accme:myapp --namespace=acme

3、在全集群范围内为用户 ”root“ 授予 cluster-admin ClusterRole:

$ kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root

4、在全集群范围内为用户 ”kubelet“ 授予 system:node ClusterRole:

$ kubectl create clusterrolebinding kubelet-node-binding --clusterrole=system:node --user=kubelet

5、在全集群范围内为名为 ”myapp“ 的 Service Account 授予 view ClusterRole:

$ kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp

RBAC 的 Auto-reconciliation(自动恢复)功能

自动回复从 v1.6 版本开始引入。每次启动时,API Server 都会更新默认的集群角色的缺失权限,也会刷新默认的角色绑定中缺失的主体,这样就防止了一些破坏性的修改,也保证了在集群升级的情况下相关内容能够及时更新。

如果不需要使用这一功能,则可以将一个默认的集群角色(ClusterRole)或者角色绑定(RoleBinding)的 Annoration 注解 ”rbac.authorization.kubernetes.io/autoupdate“ 值设置为 false。

从旧版本的策略升级到 RBAC

在 v1.6 之前,很多 Deployment 都试用了比较宽松的 ABAC 策略,包含为所有 Service Account 开放完全 API 访问。

默认的 RBAC 策略为控制台组件、节点和控制器授予了范围受限的权限,但是不会为 ”kube-system“ 以外的 Service Account 授予任何权限。

这样一来,可能会对现有的一些工作负载造成影响,这时用两种办法来解决这一问题。

1、并行认证。RBAC 和 ABAC 同时允许,并包含传统的 ABAC 策略:

--authorization-mode=RBAC,ABAC --authorization-policy-file=mypolicy.jsonl

首先会由 RBAC 尝试对请求进行授权,如果得到的结果是拒绝,那么就轮到了 ABAC 生效。这样所有应用只要满足 RBAC 或 ABAC 之一即可工作。

如果使用 2 或者更高的日志标准(--v=2),则将可以在 API Server 日志中看到 RBAC 的拒绝行为(前缀:RBAC DENY)。可以利用这一信息来确定需要授权任何权限给用户、组或 Service Account。如果有一天,集群管理员已经按照 RBAC 的方式对 Service 进行授权,并且这些工作负载运行的过程中不再出现 RBAC 的拒绝信息,就可以移除 RBAC 了。

1、粗放管理。可以使用 RBAC 的角色绑定,复制一个粗放的策略。

警告:下面的策略让所有 Service Account 都具备了集群管理员权限,所有容器运行的应用都会自动接收到 Service Account 的认证,能够对任何 API 做任何事情,包括查看 Secret 和修改权限。这不是一个值得推荐的策略。

$ kubectl create clusterrolebinding pemissive-binding \
  --clusterrole=cluster-admin \
  --user=admin \
  --user=kubelet \
  --group=system:serviceaccounts
  • No labels