Using RBAC Authorization

作者： /

https://kubernetes.io/docs/reference/access-authn-authz/rbac

API objects

RBAC API 定义了四种 Kubernetes 对象：

  1. Role
  2. ClusterRole
  3. RoleBinding
  4. ClusterRoleBinding

Role and ClusterRole

Role 和 ClusterRule 包含一组表示权限的规则。这些权限是相互叠加的（不存在拒绝的规则）。

Role 只能作用在特定的 Namespace 中。所以当你创建 Role 时，你必须指定为它指定一个 Namespace。

相对的，ClusterRole 是非 Namespace 资源。这些资源有不同的名字（Role 和 ClusterRole）是因为 Kubernetes 对象要么是 Namespace 限定的要么不是，它不能是既可以 Namespace 限定又可以不限定。

ClusterRole 有如下用途：

  • 定义 Namespace 内资源的权限并授权给某个 Namespace 内资源访问
  • 定义 Namespace 内资源的权限并跨 Namespace 授权
  • 在集群范围上的资源定义权限

RoleBinding and ClusterRoleBinding

RoleBinding 是将 Role 定义的权限授予指定的用户或一组用户。它有一组 subjects（用户、组或 Service Account）和一个将被授予的 Role 引用。RoleBinding 在指定的 Namespace 授权，而 ClusterRoleBinding 在集群范围执行授权。

RoleBinding 可以引用同 Namespace 内的任意 Role。或者，RoleBinding 可以绑定 ClusterRole 到当前 Namespace 并引用。如果你想绑定 ClusterRole 到所有 Namespace，请使用 ClusterRoleBinding。

Referring to resources

在 Kubernetes API 中，大多数资源都是使用他们的对象名称（字符串表示）来呈现和访问的，比如对于 Pod 使用 pods。 RBAC 使用资源相关的 API URL 地址中的名字来引用资源。有一些 Kubernetes API 还涉及子资源（subresource），比如 Pod 的日志。

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

在上述例子中，pods 是指 Namespace 内的 Pod 资源，而 log 就是 pods 的子资源。使用斜杠（/） 分隔资源和子资源。要允许访问 pods 资源同时也允许访问其 log，那么你需要：

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

你也可以通过 resourceNames 数组指定资源的名称来引用资源，当指定时，可以将请求限定在单个资源的实例上。比如：

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: configmap-updater
rules:
- apiGroups: [""]
  #
  # at the HTTP level, the name of the resource for accessing ConfigMap
  # objects is "configmaps"
  resources: ["configmaps"]
  resourceNames: ["my-configmap"]
  verbs: ["update", "get"]

滚动至顶部