鉴权是确定请求方有哪些资源的权限，API Server目前支持RBAC鉴权、Node鉴权、ABAC鉴权 和 Webhook模式

一、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

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

2.默认ClusterRole/ClusterRoleBinding

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

如果要禁用匿名的未经过身份验证的用户访问，请在 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}}

一般都是使用RBAC + Node鉴权