基于角色的访问控制(RBAC)使用rbac.authorization.k8s.ioAPI组来驱动授权决策，允许管理员通过Kubernetes API动态配置策略。

从1.8开始RBAC模式是稳定的，由rbac.authorization.k8s.io/v1API支持。

开启RBAC启动apiserver的时候通过--authorization-mode=RBAC参数来配置。

Role和ClusterRole

在RBAC API里，角色包含一组标示权限的规则集合，权限是纯碎的加法没有否定规则。角色可以是定义给namespace的Role，也可以是集群范围的ClusterRole。一个Role只能用于对单个namespace的资源访问权限。这里是一个定义给default namespace的Role，可以用于读取访问pods:

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

ClusterRole可以用于授予和Role相同的权限，不过它是集群范围的，也可以用于授权访问权限：

• 集群范围资源(例如节点)
• 非资源端点(例如"/healthz")
• 所有namespace中的命名空间资源(例如pod)

下面的ClusterRole例子可用于访问特定namespace或者所有namespace的secrets(取决于它如何绑定)：

kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  # "namespace" omitted since ClusterRoles are not namespaced
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "watch", "list"]

RoleBinding和ClusterRoleBinding

角色绑定将Role里面定义的权限授予一个用户或者一组用户集合。它包含(users,groups或者serviceaccount)以及被授予的角色引用。权限可以通过RoleBinding授予一个namespace,或者集群范围的ClusterRoleBinding。

RoleBinding可以在相同的namespace引用一个Role。下面的RoleBinding给用户jane在default空间中授予pod-reader角色。允许用户jane读取default空间中的pod。

# This role binding allows "jane" to read pods in the "default" namespace.
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还可以引用ClusterRole来授予RoleBinding命名空间中ClusterRole中定义的命名空间资源权限。这允许管理员为整个集群定义一组通用角色，然后在多个命名空间中使用它们。

例如，以下RoleBinding引用了一个ClusterRole,“dave”将在development命名空间中可以读取secrets。

# This role binding allows "dave" to read secrets in the "development" namespace.
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-secrets
  namespace: development # This only grants permissions within the "development" namespace.
subjects:
- kind: User
  name: dave
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: secret-reader
  apiGroup: rbac.authorization.k8s.io

ClusterRoleBinding可以用于授予所有namespace集群级别的权限。下面的例子ClusterRoleBinding允许manager里面的所有用户都可以读取所有集群的secrets。

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

参考资源

大多数资源的名称由字符串表示，例如pods,就像它出现在API的端点URL中。然后一些Kubernetes API涉及一些子资源，例如pod的日志。下面的URL是pod的日志：

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

在这个例子中，pods是命名空间资源，log是pod的子资源。在RBAC中表示此角色，使用斜杠划分资源和子资源。允许读取pod和pod日志，可以这样写：

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列表中的某些请求的名称引用。当指定时，请求使用"get","delete","update"和"patch"动词可以被限制为资源的各个实例。要限制只能"get"和"update"一个单独的configmap可以这样写：

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

值得注意的是，如果resourceNames被指定动词不能是list, watch, create或者deletecollection。因为资源名称不存在于list, watch, create和deletecollection的URL中。这些动词将不被resourceName设置的规则所允许，因为规则的resourceNames部分与请求不匹配。

Role例子

一下例子只显示rules部分：

允许读取pods资源在核心API组：

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

允许读取和写deployment在extensions和app API组：

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

允许读取pods和读写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限制一个ConfigMap和一个namespace):

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

允许核心组读取nodes(因为Node是一个集群范围，必须在ClusterRole和一个ClusterRoleBinding才可以生效)：

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

允许“GET”和“POST”请求到非资源端点“/ healthz”和所有子路径（必须在与ClusterRoleBinding绑定的ClusterRole中有效）：

rules:
- nonResourceURLs: ["/healthz", "/healthz/*"] # '*' in a nonResourceURL is a suffix glob match
  verbs: ["get", "post"]

参考主题

RoleBinding或ClusterRoleBinding将角色绑定到主题。主题可以是groups,users和serviceaccount。用户由字符串表示。这些可以是简单的用户名，如“alice”，电子邮件样式名称，如“bob@example.com”或以字符串表示的数字ID。由Kubernetes管理员配置认证模块以产生所需格式的用户名。RBAC授权系统不需要任何特定格式。然而，前缀"system："是为Kubernetes系统使用而保留的，因此管理员应确保用户名不会意外包含此前缀。

Kubernetes的组信息目前由Authenticator模块提供。groups,users是用字符串表示，没有格式要求，除了预留的system:。

Service Accounts的名字为system:serviceaccount前缀,并且属于具有system:serviceaccounts前缀的组。

Role绑定的例子

以下例子只显示了RoleBinding部分。

用户名为"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命名空间里的default service account：

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

qa命名空间里面的所有的service account:

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

所有service account在任何地方:

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

所有的验证用户(版本：1.5+):

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

所有的不需要验证用户(版本:1.5+):

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

所有类型用户(版本1.5+):

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