Kubernetes权限管理之RBAC

K8s在1.3版本中发布了alpha版的基于角色的访问控制RBAC(Role-based Access Control)的授权模式。相对于基于属性的访问控制ABAC(Attribute-based Access Control),RBAC主要是引入了角色(Role)角色绑定(RoleBinding)的抽象概念。在ABAC中,K8s集群中的访问策略只能跟用户直接关联;而在RBAC中,访问策略可以跟某个角色关联,具体的用户在跟一个或多个角色相关联。

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

screenshot

新的RBAC具有如下优势。

  • 对集群中的资源和非资源权限均有完整的覆盖。
  • 整个RBAC完全由 几个API对象完成,同其他API对象一样 ,可以用kubectlAPI进行操作。
  • 可以在运行时进行调整,无须重新启动 API Server。
  • 要使用 RBAC 授权模式 ,则 需要在 API Server 的启动 参数中 加上--authorization-mode=RBAC

角色( 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"]

rules 中的参数说明如下。

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

集群角色(ClusterRole)

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

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

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

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  # ClusterRole不受限于命名空间,所以省略了namespace name的定义
rules:
- apiGroups: [""]
  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: read-pods
  namespace: default
subjects:
- kind: User
    name: jane
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

RoleBinding也可以引用ClusterRole进行授权。

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命名空间中的权限才能赋予dave
subjects:
- kind: User
  name: dave
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

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

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

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

screenshot

2)对资源的引用方式

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

在这个例子中,Pod是一个命名空间内的资源,log就是一个下级资源。要在RBAC角色中体现,则需要用斜线“/”来分隔资源和下级资源。
若想授权让某个主体同时能够读取PodPod 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"]

资源还可以通过名字(ResourceName)进行引用(这里指的是资源实例的名子)。在指定ResourceName后,使用get、delete、update和patch动词的请求,就会被限制在这个资源实例的范围内。

例如下面的声明让一个主体只能对一个configmap进行get和update操作:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  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数据的一部分。

3)常用的角色(Role)示例

下面的例子只展示了rules部分的内容。

(1)允许读取核心API组中的Pod资源

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

(2)允许读写"extensions"和"apps"两个API组中的"deployments"资源

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

(3)允许读取"pods"及读写"jobs"

rules:
- 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)

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

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

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

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

rules:
- nonResourceURLs: ["/healthz", "/healthz/*"]
  verbs: ["get", "post"]
4)常用的角色绑定(RoleBinding)示例

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

(1)用户名"alice@example.com"

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

(2)组名"frontend-admins"
subjects:

- kind: Group
  name: "frontend-admins"
  apiGroup: 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
  apiGroup: rbac.authorization.k8s.io

(5)所有Service Account

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

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

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

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

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

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

subjects:
- kind: Group
  name: system:authenticated
   apiGroup: rbac.authorization.k8s.io
- kind: Group
  name: system:unauthenticated
  apiGroup: rbac.authorization.k8s.io
5)默认的角色和角色绑定

API Server 创建了一系列的默认 ClusterRole 和 ClusterRoleBinding 对象, 其中许多对象以 "system:" 前缀开头,代表其中绑定的资源是作为基础设施适用和占有的。修改这些资源会导致整个集群不可用。一个例子是 system:node 。这个ClusterRole角色拥有一系列的kubelet权限,如果这个集群角色被修改了,可能会让kubelet出现异常。

所有默认的集群角色 (ClusterRole) 和其角色绑定(role binding)都带有如下标记

kubernetes.io/bootstrapping=rbac-defaults

下面对一些常见的默认ClusterRole和ClusterRoleBinding对象进行说明。

对系统角色的说明如下表所示:

默认的ClusterRole 默认的ClusterRoleBinding 描述
system:basic-user system:authenticated和system:unauthenticated组 让用户能够读取自身的信息
system:discovery system:authenticated和system:unauthenticated组 对API发现Endpoint的只读访问,用于API级别的发现和协商

对用户角色的说明如下表所示:

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

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

对核心Master组件角色的说明如下表所示:

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

对其他组件角色的说明如下表所示:

默认的ClusterRole 默认的ClusterRoleBinding 描述
system:auth-delegator None 允许对授权和认证进行托管,通常用于附加的API服务器
system:heapster None Heapster组件的角色
system:kube-aggregator None kube-aggregator的角色
system:kube-dns 在kube-system namespace中kube-dns的Service Account kube-dns角色
system:node-bootstrapper None 允许访问kubelet TLS启动所需的资源
system:node-problem-detector None 允许访问node-problem-detector组件所需的资源
system:persistent-volume-provisioner None 允许访问多数动态卷供给所需的资源

对Controller角色的说明如下表所示:

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:node-controller
system:controller:persistent-volume-binder
system:controller:pod-garbage-collector
system:controller:replicaset-controller
system:controller:replication-controller
system:controller:route-controller
system:controller:service-account-controller
system:controller:service-controller
system:controller:statefulset-controller
system:controller:ttl-controller

K8s Controller Manager负责的是核心控制流。如果启用--user-service-account-credentials,则每个控制过程都会使用不同的Service Account启动。因此就有了对应各个控制过程的角色,前缀是system:controller。如果未启用这一功能,则将使用各自的凭据运行各个控制流程,这就需要为该凭据授予所有相关角色。

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

RBAC API拒绝用户利用编辑角色或者角色绑定的方法进行提权。这一限制是在API层面做出的,因此即使RBAC没有启动也仍然有效。
用户只能在拥有一个角色的所有权限,且与该角色的生效范围一致的前提下,才能对角色进行创建和更新。要让一个用户能够创建或更新角色,需要:

  • 为其授予一个允许创建/更新Role或ClusterRole资源对象的角色;

  • 为用户授予角色,要覆盖该用户所能控制的所有权限范围。用户如果尝试创建超出其自身权限的角色或集群角色,则该API调用会被禁止。

如果一个用户的权限包含了一个角色的所有权限,那么就可以为其创建和更新角色绑定。或者如果被授予了针对某个角色的绑定授权,则也有权完成此操作。

要使用户能够创建、更新这一角色绑定或者集群角色绑定的角色,需要有如下做法:

  • 为其授予一个允许其创建和更新角色绑定或者集群角色绑定的角色;
  • 为其授予绑定某一角色的权限。

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

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

7)对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授予只读权限:

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

(2)为一个命名空间中的"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授予一个角色

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

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

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

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

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

(5)为所有Service Account授予超级用户权限(非常危险)

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

8)使用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=acme: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

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

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

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

10)从旧版本的授权策略升级到RBAC

在k8s 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之一即可工作。
通过输出更详细的日志信息,查看以上鉴权过程和结果。直到某一天,再也不输出RBAC鉴权失败的日志了,就可以移除ABAC了。

(2)粗放管理

可以使用RBAC的角色绑定,复制一个粗话的策略。

下面的策略会让所有Service Account都具备了集群管理员权限,所有容器运行的应用都会自动接收到Service Account的认证,能够对任何API做任何事情,包括查看Secret和修改授权。这一策略无疑是比较凶险的。

$ kubectl create clusterrolebinding permissive-binding --clusterrole=cluster-admin --user=admin --user=kubelet --group=system:serviceaccounts





发表于: 1月前   最后更新时间: 1月前   游览量:106
上一条: Kubernetes之Secret私密凭据
下一条: Kubernetes API概述

评论…


  • 评论…
    • in this conversation