基于角色的访问控制

在 RBAC API 中，一个 角色 包含了一套表示 一组权限 的规则：

• 权限以纯粹的 累加 形式累积（没有” 否定” 的规则）
  • 角色可以由 namespace 内的 Role 对象定义
  • 整个 Kubernetes 集群 范围内有效的角色则通过 ClusterRole 对象实现

一个 Role 对象只能用于授予对某一单一命名空间中资源的访问权限

kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # 空字符串"" 表明使用 core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

以上示例描述了 _default_ 命名空间中的一个 Role 对象的定义，用于授予对 pod 的读访问权限

ClusterRole 对象可以授予与 Role 对象相同的权限，但由于它们属于集群范围对象， 用它们授予对以下几种资源的访问权限：

• 集群范围资源

  例如节点，即 node
  

• 非资源类型 endpoint

  例如”/healthz”
  

• 跨所有命名空间的命名空间范围资源

  例如 pod，需要运行命令 kubectl get pods --all-namespaces 来查询集群中所有的 pod
  

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  # 鉴于 ClusterRole 是集群范围对象，所以这里不需要定义 "namespace" 字段
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

示例中的 ClusterRole 定义可用于授予用户对某一特定命名空间，或者所有命名空间中的 secret（取决于其 绑定 方式）的读访问权限

角色绑定将一个角色中定义的各种权限授予一个或者一组用户：

• 角色绑定包含了一组相关主体：
  • 用户 User
  • 用户组 Group
  • 服务账户 Service Account
  • 对被授予角色的引用
• 在命名空间中可以通过 RoleBinding 对象授予权限
• 集群范围的权限授予则通过 ClusterRoleBinding 对象完成

RoleBinding 可以引用在同一命名空间内定义的 Role 对象

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
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 对象在 ”default” 命名空间中将 ”pod-reader” 角色授予用户”jane”

这一授权将允许用户”jane” 从”default” 命名空间中读取 pod

RoleBinding 对象也可以引用一个 ClusterRole 对象

这一点允许管理员在整个集群范围内首先定义一组通用的角色，然后再在不同的命名空间中复用这些角色

# 以下角色绑定允许用户 "dave" 读取 "development" 命名空间中的 secret。
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-secrets
  namespace: development # 这里表明仅授权读取 "development" 命名空间中的资源。
subjects:
- kind: User
  name: dave
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

尽管示例中的 RoleBinding 引用的是一个 ClusterRole 对象，但是用户”dave”（即角色绑定主体）还是只能读取”development” 命名空间中的 secret（即 RoleBinding 所在的命名空间）

也可以使用ClusterRoleBinding在集群级别和所有命名空间中授予权限

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

示例中所定义的ClusterRoleBinding允许在用户组”manager” 中的任何用户都可以读取集群中任何命名空间中的 secret

大多数资源由代表其 名字的字符串 表示

例如”pods”，就像它们出现在相关 API endpoint 的 URL 中一样

然而，有一些 Kubernetes API 还 包含了 子资源

比如 pod 的 logs，在 Kubernetes 中 pod logs endpoint 的 URL 格式为：

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

在这种情况下，”pods” 是 命名空间资源 ，而 ”log” 是 pods 的子资源。为了在 RBAC 角色中表示出这一点，需要使用 斜线 来划分资源 与子资源。如果需要角色绑定主体读取 pods 以及 pod log，需要定义以下角色：

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"]

通过 resourceNames 列表，角色可以针对不同种类的请求根据资源名引用资源实例。当指定了resourceNames列表时，不同 动作 种类的请求的权限将被 限定 到资源列表中所包含的资源实例上

如使用”get”、”delete”、”update” 以及”patch” 等动词的请求

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

如果需要限定一个角色绑定主体只能”get” 或者”update” 一个 configmap 时，可以定义上面这个角色

注意：如果设置了 resourceNames ，则请求所使用的动词 不能 是 list 、 watch 、 create 或者 deletecollection

由于资源名不会出现在 create、list、watch 和 deletecollection 等 API 请求的 URL 中，所以这些请求动词不会被设置了 resourceNames 的规则所允许，因为规则中的resourceNames 部分不会匹配这些请求

每次启动时，API Server 都会更新默认 ClusterRole 所缺乏的各种权限，并更新默认 ClusterRoleBinding 所缺乏的各个角色绑定主体

这种自动更新机制允许集群修复一些意外的修改，由于权限和角色绑定主体在新的 Kubernetes 释出版本中可能变化，这也能够保证角色和角色 绑定始终保持是最新的

如果需要禁用自动更新，请将默认 ClusterRole 以及 ClusterRoleBinding 的 rbac.authorization.kubernetes.io/autoupdate 设置成为 false

注意，缺乏默认权限和角色绑定主体可能会导致非功能性集群问题

一些默认角色并不包含 system: 前缀，它们是面向用户的角色。 这些角色包含 超级用户 角色（cluster-admin），即旨在利用 ClusterRoleBinding（cluster-status）在集群范围内授权的角色， 以及那些使用 RoleBinding（admin、edit 和 view）在特定命名空间中授权的角色

Kubernetes controller manager 负责运行核心控制循环：

• 当使用 –use-service-account-credentials 选项运行 controller manager 时，每个 控制循环 都将使用 单独的服务账户 启动。 而每个控制循环都存在对应的 角色 ，前缀名为 system:controller:
• 如果不使用 –use-service-account-credentials 选项时，controller manager 将会使用 自己的凭证 运行所有控制循环，而这些凭证必须被 授予 相关的角色

这些控制器角色包括：

• 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:resourcequota-controller
• system:controller:route-controller
• system:controller:service-account-controller
• system:controller:service-controller
• system:controller:statefulset-controller
• system:controller:ttl-controller

要求应用程序在其 pod spec 中指定 serviceAccountName 字段，并且要创建相应服务账户

例如，在”my-namespace” 命名空间中授予服务账户”my-sa” 只读权限

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

如果一个应用程序没有在其 pod 规范中指定 serviceAccountName，它将默认使用 default 服务账号

注意：授予 default 服务账号的权限将可用于命名空间内任何没有指定 serviceAccountName 的 pod 

下面的例子将在”my-namespace” 命名空间内授予 ”default” 服务账号只读权限

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

目前 许多 加载项（addon） 作为 kube-system 命名空间中的 default 服务帐户运行。 要允许这些加载项使用超级用户访问权限，请将 cluster-admin 权限授予 kube-system 命名空间中的 default 服务帐户

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

注意：启用上述操作意味着 ”kube-system” 命名空间将包含允许超级用户访问 API 的秘钥

如果希望命名空间内的所有应用程序都拥有同一个角色，无论它们使用什么服务账户，可以为该命名空间的服务账户用户组授予角色

下面的例子将授予 ”my-namespace” 命名空间中的所有服务账户只读权限

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

如果不想管理每个命名空间的权限，则可以将集群范围角色授予所有服务帐户

下面的例子将所有命名空间中的只读权限授予集群中的所有服务账户

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

如果根本不关心权限分块，可以对所有服务账户授予超级用户访问权限。

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

警告：这种做法将允许任何具有读取权限的用户访问 secret 或者通过创建一个容器的方式来访问超级用户的凭据