一、RBAC鉴权

基于角色（Role）的访问控制（RBAC）是一种基于组织中用户的角色来调节控制对计算机或网络资源的访问的方法。

要启用 RBAC，在启动 API 服务器时将 --authorization-mode 参数设置为一个逗号分隔的列表并确保其中包含 RBAC

API对象

RBAC API 声明了四种 Kubernetes 对象：Role、ClusterRole、RoleBinding 和 ClusterRoleBinding

RBAC.png

Role 或 ClusterRole 中包含一组代表相关权限的规则。这些权限是纯粹累加的（不存在拒绝某操作的规则）

Role 定义命名空间内权限，ClusterRole是定义跨命名空间的权限

Role定义例子如下：

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default      ##如果kind是ClusterRole，无须指定，代表集群级别
  name: pod-reader
rules:
- apiGroups: [""]             #"" indicates the core API group 具体参考kubectl api-resources
  resources: ["pods"]         # 资源names, 子资源例子：["pods/log"]
  verbs: ["get", "watch", "list"]  #允许动作

如果是Role，代表能访问default空间下的所有Pod，如果是ClusterRolo代表能访问所有空间下的Pod

-指定固定某个资源名称

rules:
- apiGroups: [""]
  # 在 HTTP 层面，用来访问 ConfigMap 资源的名称为 "configmaps"
  resources: ["configmaps"]
  resourceNames: ["my-configmap"]
  verbs: ["update", "get"]

-指定非资源端点

rules:
- nonResourceURLs: ["/healthz", "/healthz/*"] # nonResourceURL 中的 '*' 是一个全局通配符
  verbs: ["get", "post"]

RoleBinding 将Role定义的权限授予用户/用户组/服务账号（统称主体subject）

ClusterRoleBinding 只能将ClusterRole定义的权限授予用户/用户组/服务账号（统称主体subject）
将pod-reader角色授予普通用户myuser

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User       #支持User，Group，ServiceAccount 三种类型
  name: myuser
  apiGroup: rbac.authorization.k8s.io
roleRef:
   kind: Role
   name: pod-reader
   apiGroup: rbac.authorization.k8s.io

一个 RoleBinding 也可以引用某 ClusterRole 并将该 ClusterRole 绑定到 RoleBinding 所在的名字空间

聚合的ClusterRole

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring
aggregationRule:
  clusterRoleSelectors:
  - matchLabels:
      rbac.example.com/aggregate-to-monitoring: "true"
rules: [] # 控制面自动填充这里的规则

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: monitoring-endpoints
  labels:
    rbac.example.com/aggregate-to-monitoring: "true"
# 当你创建 "monitoring-endpoints" ClusterRole 时，
# 下面的规则会被添加到 "monitoring" ClusterRole 中
rules:
- apiGroups: [""]
  resources: ["services", "endpointslices", "pods"]
  verbs: ["get", "list", "watch"]

相关核心内置对象

所有system:前缀都是系统自带命名规则

1.主体Subject

名称	类型	说明
default	ServiceAccount	每个命名空间自带
system:anonymous	User	匿名用户
system:serviceaccounts	Group	任务名字空间的服务账号都属于这个组
system:serviceaccounts:空间名字	Group	该名字空间下的服务账号都属于这个组
system:authenticated	Group	所有通过身份认证的用户都属于这个组
system:unauthenticated	Group	所有未通过身份认证的用户都属于这个组
system:masters	Group	超级管理员cluster-admin所属的组

system:serviceaccount: （单数）是用于服务账户用户名的前缀；
system:serviceaccounts: （复数）是用于服务账户组名的前缀。

2.默认ClusterRole/ClusterRoleBinding

默认 ClusterRole 和 ClusterRoleBinding 都有kubernetes.io/bootstrapping=rbac-defaults 标签
自动协商：在每次启动时，API 服务器都会更新默认 ClusterRole 以添加缺失的各种权限，并更新默认的 ClusterRoleBinding 以增加缺失的各类主体。禁止可设置注解rbac.authorization.kubernetes.io/autoupdate=false

默认ClusterRole	对应默认ClusterRoleBinding	说明
cluster-admin	cluster-admin，绑定system:master组	超级管理员角色
admin	无	大多数对象进行读/写操作包括角色和角色绑定
edit	无	大多数对象进行读/写操作角色
view	无	只有访问权限角色
system:discovery	system:discovery,绑定组 system:authenticated	允许以只读方式访问 API 发现端点

如果要禁用匿名的未经过身份验证的用户访问，请在 API 服务器配置中中添加 --anonymous-auth=false 的配置选项

创建一个dev空间的管理员dev-admin

kubectl create rolebinding dev-admin --clusterrole=cluster-admin --user=dev-admin -n dev

二、Node鉴权

节点鉴权是一种特殊用途的鉴权模式，专门对 kubelet 发出的 API 请求进行授权,通过--authorization-mode=Node 启动API服务器开启
为了获得节点鉴权器的授权，kubelet 必须使用一个凭证以表示它在 system:nodes 组中，用户名为 system:node:<nodeName>

三、ABAC鉴权

基于属性的访问控制（Attribute-based access control - ABAC）定义了访问控制范例，其中通过使用将属性组合在一起的策略来向用户授予访问权限

指定策略文件 --authorization-policy-file=SOME_FILENAME

文件内容格式JSON lines，例如：

Alice 可以对所有资源做任何事情

{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "alice", "namespace": "*", "resource": "*", "apiGroup": "*"}}

kubelet 可以读取任何 pod

{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "Policy", "spec": {"user": "kubelet", "namespace": "*", "resource": "pods", "readonly": true}}