Kubernetes集群安全机制RBAC

目录

• RBAC原理和用法
  • • 1.RBAC的API资源对象说明
    • 2.对资源的引用方式
    • 3.常见的角色(Role)示例
    • 4.常用的角色绑定
    • 5.默认的角色和角色绑定

RBAC原理和用法

1.RBAC的API资源对象说明

RBAC引入了4个新的顶级资源对象：Role、ClusterRole、RoleBinding、ClusterRoleBinding，可以使用kubectl或者API调用等方式操作这些资源对象。

1.角色(Role)

一个角色就是一组权限的集合，这里的权限都是许可形式的，不存在拒绝的规则。在一个命名空间中，用Role来定义一个角色，集群级别的使用ClusterRole。角色只能对命名空间内的资源进行授权。

• 下面的例子中定义的角色具备读取Pod的权限：

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

# 或者写为:
rules:
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["get", "list", "watch"]

rules中的参数说明：

• apiGroup：支持的API组列表，例如：""、APIVersion: batch/v1、APIVersion: extensions:v1、apiVersion:apps/v1等
• resources：支持的资源对象列表，例如：pods、deployments、jobs、secrets、service、namespace等
• verbs：对资源对象的操作方法列表，例如：get、watch、list、delete、replace、patch等

2.集群角色(ClusterRole)

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

• 集群范围的资源，例如node

• 非资源型的路径，例如/healthz

• 包含全部命名空间的资源，例如pods

• 下面例子的集群角色(ClusterRole)可以让用户有权访问任意一个或所有命名空间的secrets：

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

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

角色绑定或集群角色绑定用来把一个角色绑定到一个目标上，绑定目标可以是User、Group或者ServiceAccount。使用RoleBinding为某个命名空间授权，ClusterRoleBinding为集群范围内授权。

RoleBinding可以引用Role进行授权，下例中的RoleBinding将在namespace-test命名空间中把pod-reader角色授予用户test，可以让test用户读取namespace-test命名空间的Pod。

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: namespace-test

subjects:
- kind: User
  name: test
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

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

• 下例中的RoleBinding绑定集群角色secret-reader，使用户dave只能读取development命名空间中的secret：

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-secrets
  namespace: development

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/v1
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

2.对资源的引用方式

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

Pod是一个命名空间内的资源，logs就是一个下级资源。要在一个RBAC角色中体现，则需要用斜线/来分割资源和下级资源。

• 下例中授权让某个角色同时能够读取Pod和Pod logs，可以配置resources为一个数组：

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

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

• 下例的声明让一个主体只能对一个叫my-configmap的configmap进行get和update操作：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: configmap-updater
rules:
- apiGroups: [""]
  resources: ["configmap"]
  resourceNames: ["my-configmap"]
  verbs: ["get", "update"]

3.常见的角色(Role)示例

• 允许读取核心API组中的pod资源及允许读写"batch"和"extensions"组里的jobs资源

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

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

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

• 读取核心组的node资源(Node属于集群级别的资源，必须放在ClusterRole中，并使用ClusterRoleBinding进行绑定)

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

　　

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

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

4.常用的角色绑定

• 用户名Alice@example.com

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

• 组名frontend-admins

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

• kube-system命名空间中的默认ServiceAccount

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

• qa命名空间中的所有Service Account

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

• 所有ServiceAccount

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

• 全部用户(所有未认证+所有已认证)

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

5.默认的角色和角色绑定

API Server会创建一套默认的ClusterRole和ClusterRoleBinding对象，其中很多是以system:为前缀的，以表明这些资源属于基础架构，对这些对象的改动可能造成集群故障。

常见的系统角色如下：

默认的ClusterRole	默认的ClusterRoleBinding	描述
system:basic-user	system:authenticated	让用户能够读取自身的信息
system:discovery	system:authenticated	对API发现Endpoint的只读访问，用于API级别的发现和协商
system:public-info-viewer	system:authenticated 和 system:unauthenticated 组	允许对集群的非敏感信息进行只读访问

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

常见的用户角色如下：

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

核心组件角色：

默认的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形式的用户名进行
system:node-proxier	system:kube-proxy用户	允许访问kube-proxy所需的资源

其他组件角色：

默认ClusterRole	默认ClusterRoleBinding	描述
system:auth-delegator	None	允许将身份认证和鉴权检查操作外包出去。 这种角色通常用在插件式 API 服务器上，以实现统一的身份认证和鉴权。
system:heapster	Node	为 Heapster 组件（已弃用）定义的角色。
system:kube-aggregator	Node	为 kube-aggregator 组件定义的角色。
system:kube-dns	在 kube-system 名字空间中的 kube-dns 服务账户	为 kube-dns 组件定义的角色。
system:kubelet-api-admin	Node	允许 kubelet API 的完全访问权限。
system:node-bootstrapper	Node	允许访问执行 kubelet TLS 启动引导所需要的资源。
system:node-problem-detector	Node	为 node-problem-detector 组件定义的角色。
system:persistent-volume-provisioner	Node	允许访问大部分 动态卷驱动 所需要的资源。
system:monitoring	system:monitoring 组	允许对控制平面监控端点的读取访问（例如：kube-apiserver 存活和就绪端点（/healthz、/livez、/readyz）， 各个健康检查端点（/healthz/、/livez/、/readyz/*）和 /metrics）。 请注意，各个运行状况检查端点和度量标准端点可能会公开敏感信息。

查询命令:

kubectl describe clusterrole admin
kubectl describe clusterrole cluster-admin
kubectl describe clusterrole edit
kubectl describe clusterrole view

参考文档：
https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac/