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

[root@k8s-master test]# kubectl create -f rolebinding.yaml
rolebinding "read-pods" created
[root@k8s-master 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 Resourcespods是命名空间中的资源，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

 sectionis 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

 tolimit to a single 

ConfigMap

 ina single namespace):

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

Allow reading the resource “nodes” in the core group (because a 

Node

 iscluster-scoped, this must be in a 

ClusterRole

 boundwith a 

ClusterRoleBinding

 tobe 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

 boundwith a 

ClusterRoleBinding

 tobe effective):

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

Referring to Subjects

RoleBinding或ClusterRoleBinding绑定到主体。主体可以是组，用户或服务账号。用户名以字符串形势呈现，像是“alice”，“bob@example.com”，或数字id。这取决于管理员在认证模块（ authenticationmodules）产生的用户名格式。RBAC认证系统不需要特定的格式。但是“system”这个前缀是为系统保留的，不要使用。Kubernetes中的组信息目前由Authenticator模块提供。组名也是字符串，前缀不要使用“system”。ServiceAccounts 的用户名有“system:serviceaccount:”前缀，属于组的具有“system:serviceaccounts”前缀。

Role Binding Examples

Only the 

subjects

 sectionof a 

RoleBinding

 isshown in the following examples.For a user named “alice@example.com”:

subjects:- kind: Username: "alice@example.com"apiGroup: rbac.authorization.k8s.io

For a group named “frontend-admins”:

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

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

subjects:- kind: ServiceAccountname: defaultnamespace: kube-system

For all service accounts in the “qa” namespace:

subjects:- kind: Groupname: system:serviceaccounts:qaapiGroup: rbac.authorization.k8s.io

For all service accounts everywhere:

subjects:- kind: Groupname: system:serviceaccountsapiGroup: rbac.authorization.k8s.io

For all authenticated users (version 1.5+):

subjects:- kind: Groupname: system:authenticatedapiGroup: rbac.authorization.k8s.io

For all unauthenticated users (version 1.5+):

subjects:- kind: Groupname: system:unauthenticatedapiGroup: rbac.authorization.k8s.io

For all users (version 1.5+):

subjects:- kind: Groupname: system:authenticatedapiGroup: rbac.authorization.k8s.io- kind: Groupname: system:unauthenticatedapiGroup: rbac.authorization.k8s.io