鉴权是确定哀求方有哪些资源的权限，API Server现在支持RBAC鉴权、Node鉴权、ABAC鉴权 和 Webhook模式
一、RBAC鉴权
基于脚色（Role）的访问控制（RBAC）是一种基于构造中用户的脚色来调治控制对盘算机或网络资源的访问的方法。
要启用 RBAC，在启动 API 服务器时将 --authorization-mode 参数设置为一个逗号分隔的列表并确保此中包罗 RBAC
API对象
RBAC API 声明白四种 Kubernetes 对象：Role、ClusterRole、RoleBinding 和 ClusterRoleBinding
- Role 或 ClusterRole 中包罗一组代表相干权限的规则。 这些权限是纯粹累加的（不存在拒绝某操纵的规则）
- Role 界说定名空间内权限，ClusterRole是界说跨定名空间的权限
Role界说例子如下：
kind: RoleapiVersion: rbac.authorization.k8s.io/v1metadata: namespace: default ##假如kind是ClusterRole，无须指定，代表集群级别 name: pod-readerrules:- 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: RoleBindingapiVersion: rbac.authorization.k8s.io/v1metadata: name: read-pods namespace: defaultsubjects:- kind: User #支持User，Group，ServiceAccount 三种范例 name: myuser apiGroup: rbac.authorization.k8s.ioroleRef: kind: Role name: pod-reader apiGroup: rbac.authorization.k8s.io
一个 RoleBinding 也可以引用某 ClusterRole 并将该 ClusterRole 绑定到 RoleBinding 地点的名字空间
聚合的ClusterRole
apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: name: monitoringaggregationRule: clusterRoleSelectors: - matchLabels: rbac.example.com/aggregate-to-monitoring: "true"rules: [] # 控制面主动添补这里的规则apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata: 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
名称范例阐明defaultServiceAccount每个定名空间自带system:anonymousUser匿名用户system:serviceaccountsGroup使定名字空间的服务账号都属于这个组system:serviceaccounts:空间名字Group该名字空间下的服务账号都属于这个组system:authenticatedGroup全部通过身份认证的用户都属于这个组system:unauthenticatedGroup全部未通过身份认证的用户都属于这个组system:mastersGroup超等管理员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-admincluster-admin， 绑定system:master组超等管理员脚色admin无大多数对象举行读/写操纵包罗脚色和脚色绑定edit无大多数对象举行读/写操纵脚色view无只有访问权限脚色system:discoverysystem:discovery,绑定组 system:authenticated允许以只读方式访问 API 发现端点假如要禁用匿名的未颠末身份验证的用户访问，请在 API 服务器设置中中添加 --anonymous-auth=false 的设置选项
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，比方：
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": " olicy", "spec": {"user": "alice", "namespace": "*", "resource": "*", "apiGroup": "*"}}
{"apiVersion": "abac.authorization.kubernetes.io/v1beta1", "kind": "olicy", "spec": {"user": "kubelet", "namespace": "*", "resource": "pods", "readonly": true}}一样平常都是使用RBAC + Node鉴权
|
