Kubernetes权限管理之RBAC

2020-11-09 16:06:51 52

k8s在启用基于角色管理的访问控制 RBAC（Role-based-Access-Control）的授权模式。相当于基于属性的访问控制ABAC（Attribute-based Access Control）,RBAC主要是引入了角色（Role 权限的集合）和角色绑定（RoleBinding）的抽象概念。在ABAC中，k8s集群中的访问策略只能跟用户直接关联；而RBAC中，访问策略可以跟某个角色关联，具体的用户再和某个角色或者多个角色关联。

RBAC有四个新的k8s顶级资源对象： 角色（Role）、集群角色（ClusterRole）、角色绑定（RoleBinding）、集群角色绑定（ClusterRoleBinding）。同其他API资源对象一样，用户可以使用kubectl或者API调用方式等操作这些资源对象。

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

1）角色( Role)
一个角色就是一组权限的集合，这里的权限都是许可形式的，不存在拒绝的规则。在一个命名空间中，可以用角色来定义一个角色，如果是集群级别的，就需要使用ClusterRole了。角色只能对命名空间内的资源进行授权，下面例子中定义的角色具备读取Pod的权限:

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default            //这里指的是default命名空间下的角色
  name: pod-reader
rules:
- apiGroups: [""]    # ""空字符串，表示核心API群
  resources: ["pods"]            //要操作的资源
  verbs: ["get", "watch", "list"]        //操作资源对应具体的权限

rules 中的参数说明如下：
apiGroups: 支持的API组列表，例如”apiVersion: batch/v1”、”apiVersion: extensions”、”apiVersion: apps”
resources: 支持的资源对象列表，例如 pods、deployments、secrets、jobs、configmaps、endpoints、persistentvolumeclaims、replicationcontrollers、statefulsets、namespaces等。
verbs: 对资源对象 的操作方法列表 ， 例如 get、 watch、 list、 delete、 replace、 patch 、create等

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

集群范围的资源，如Node。

非资源型的路径，如”/healthz”。

包含全部命名空间的资源，例如pods（用于kubectl get pods –all-namespaces这样的操作授权）

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

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: my-cluster-role
  # ClusterRole不受限于命名空间，所以省略了namespace的定义
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

3）角色绑定（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                //操作的类型是user
  name: jane                //user的名称
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role                //权限绑定的类型是 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逻辑关系。

4）对资源的引用方式

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

在这个例子中，Pod是一个命名空间内的资源，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"]

资源还可以通过名称（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数据的一部分。

常用的角色（Role）实例
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"]

常用的角色绑定（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

默认的角色和角色绑定

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

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

kubernetes.io/bootstrapping=rbac-defaults

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

注：有些默认角色不是以”system:” 为前缀的，这部分角色是针对用户的，其中包含超级用户角色（cluster-admin），有的用于集群一级的角色（cluster-status），还有针对namespace的角色（admin、edit、view）

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

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

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

5）授权注意事项：预防提权和授权初始化

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

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

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

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

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

为其授予一个允许其创建和更新角色绑定或者集群角色绑定的角色；
为其授予绑定某一角色的权限。
需要注意的是，在进行第1个角色绑定时，必须让初始用户具备其尚未被授予的权限，要进行初始的角色和角色绑定设置，有以下两种办法：
使用属于system:masters组的身份，这一群组默认具有cluster:admin这一超级角色的绑定。
如果API Server以–insecure-port参数运行，则客户端通过这个非安全端口进行接口调用，这一端口没有认证鉴权的限制。

6）对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

7）使用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

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

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

小案例
需求场景：
一个kubernetes集群中会有多个不同的命名空间，有时，我们需要限制某用户对某些特定命名空间的权限，比如，除了集群管理员外，我们的开发和测试工程师可能需要登录集群，了解应用的运行情况，查看pod的日志，甚至是修改某些配置。显然，我们不希望直接把管理员帐号提供给所有人，这时，可以通过创建不同的token，将该token分发给特定的人员，让他们能通过kubectl命令实现一些允许的操作

操作步骤：

1.创建集群级别的角色 ClusterRole
clusterrole.cr-devlog.yaml 用于提供对pod的完全权限和其它资源的查看权限

# clusterrole.cr-devlog.yaml 提供基本权限
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cr-devlog
rules:
- apiGroups:
  - ""
  resources:
  - pods
  - pods/attach
  - pods/exec
  - pods/log
  - pods/status
  - configmaps
  verbs:
  - get
  - list
  - watch
  - update
  - create
  - delete
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - services
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - extensions
  - apps
  resources:
  - deployments
  - daemonset
  verbs:
  - get
  - list
  - watch

clusterrole.cr-namespace-devlog.yaml 提供kubectl get namespace能力

# clusterrole.cr-namespace-devlog.yaml 提供namespace的查看权限
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cr-namespace-devlog
rules:
- apiGroups:
  - ""
  resources:
  - namespaces/status
  - namespaces
  verbs:
  - get
  - list
  - watch

应用yaml文件：

kubectl apply -f clusterrole.cr-devlog.yaml
kubectl apply -f clusterrole.cr-namespace-devlog.yaml

2.在default命名空间创建 ServiceAccount

kubectl create serviceaccount devlog

注意，创建sa后，会自动创建一个绑定的 secret，命名规则是sa名称-token-xxxx ，后面在登录dashboard中，会用到该secret中的token

3.对sa和集群角色建立绑定关系
这里对dev和test两个namespace授权

kubectl create rolebinding rbd-devlog --clusterrole=cr-devlog --serviceaccount=default:devlog --namespace=dev

kubectl create rolebinding rbd-devlog --clusterrole=cr-devlog --serviceaccount=default:devlog --namespace=test

这里namespace会将集群级别的权限限定在某个namespace下，cr-devlog中定认的集群权限仅作用于dev和test名称空间

kubectl create clusterrolebinding crbd-devlog --clusterrole=cr-namespace-devlog --serviceaccount=default:devlog

该命令提供kubectl get namespace的能力
需要注意的是，这里分别使用了rolebinding和clusterrolebinding

4.获取sa的secret中的token

kubectl describe secret devlog-token-c5gvn

即可得到token，拿到token就可以登录dashboard了

睿江云官网：www.eflycloud.com

上一篇：无

下一篇： API设计模式漫谈(二) - 设计和选型