Kubernetes - 使用RBAC授权

https://kubernetes.io/docs/admin/authorization/rbac/

Role and ClusterRole

一个角色包括多种权限的规则，权限是纯粹的加法（没有“否定”规则）。一个角色可以在一个命名空间中定义为一个Role，或者在集群中定义为ClusterRole。

一个在默认namespace中赋予pods读权限的例子：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

ClusterRole可以像Role一样赋予相同的权限，但因为它是集群范围的，它还可以被赋予以下权限：

• 集群内的资源（比如nodes）
• 非资源endpoints（比如"/healthz"）？
• 所有命名空间中的资源（比如pods）

下面的ClusterRole可以赋予"secrets"在指定或任何命名空间的读权限（依赖于如何绑定）：

cat secret-reader.yaml
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced （未指定命名空间）
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]
kubectl create -f secret-reader.yaml

RoleBinding and ClusterRoleBinding

角色绑定将定义在Role中的权限赋予一个用户或一些用户。它包含一系列主体（用户、用户组、服务账号），以及被赋予的角色。在namespace范围内使用RoleBinding授权，在集群范围内使用ClusterRoleBinding授权。

RoleBinding可以引用一个相同namespace中的Role。下面的例子赋予了用户jane "pod-reader"角色。

# This role binding allows "jane" to read pods in the "default" namespace.
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

[[email protected] test]# kubectl create -f rolebinding.yaml
rolebinding "read-pods" created
[[email protected] test]# kubectl get rolebinding
NAME        AGE
read-pods   20s

RoleBinding还可以引用ClusterRole来授予RoleBinding命名空间中ClusterRole中定义的命名空间资源的权限。这允许管理员为整个集群定义一组常见角色，然后在多个命名空间中重用它们。

一个ClusterRoleBinding可以在所有命名空间中赋予集群级别的权限。下面的ClusterRoleBinding允许manager组中的任何用户在任何namespace中有读secrets的权限。

# This cluster role binding allows anyone in the "manager" group to read secrets in any namespace.
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

Referring to Resources

pods是命名空间中的资源，log是pod中的子资源，定义Role时，使用斜线将资源和子资源隔开，主体就可以同时读到pod和它的日志：

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将资源在列表中提及。当资源被指定，使用“get”，“delete”，“update”和“patch”动词的请求可以限制为资源的各个实例。 要限制一个主体只能“获取”和“更新”一个配置图，您可以写：

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

值得注意的是，resourceNames不能用于使用“create”动词来限制请求，因为授权者只能访问可以从请求URL，方法和头获得的信息（“create”请求中的资源名称是请求体的一部分）。

Role Examples

Only the rules section is shown in the following examples.

Allow reading the resource “pods” in the core API group:

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

Allow reading/writing “deployments” in both the “extensions” and “apps” API groups:

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

Allow reading “pods” and reading/writing “jobs”:

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

Allow reading a ConfigMap named “my-config” (must be bound with a RoleBinding to limit to a single ConfigMap in a single namespace):

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

Allow reading the resource “nodes” in the core group (because a Node is cluster-scoped, this must be in a ClusterRole bound with a ClusterRoleBinding to be effective):

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

Allow “GET” and “POST” requests to the non-resource endpoint “/healthz” and all subpaths (must be in a ClusterRole bound with a ClusterRoleBinding to be effective):

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




Referring to Subjects

RoleBinding或ClusterRoleBinding绑定到主体。主体可以是组，用户或服务账号。用户名以字符串形势呈现，像是“alice”，“[email protected]”，或数字id。这取决于管理员在认证模块（ authentication modules）产生的用户名格式。RBAC认证系统不需要特定的格式。但是“system”这个前缀是为系统保留的，不要使用。

Kubernetes中的组信息目前由Authenticator模块提供。组名也是字符串，前缀不要使用“system”。

Service Accounts 的用户名有“system:serviceaccount:”前缀，属于组的具有“system:serviceaccounts”前缀。

Role Binding Examples

Only the subjects section of a RoleBinding is shown in the following examples.

For a user named “[email protected]”:

subjects:
- kind: User
  name: "[email protected]"
  apiGroup: rbac.authorization.k8s.io

For a group named “frontend-admins”:

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

For the default service account in the kube-system namespace:

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

For all service accounts in the “qa” namespace:

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

For all service accounts everywhere:

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

For all authenticated users (version 1.5+):

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

For all unauthenticated users (version 1.5+):

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

For all users (version 1.5+):

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