Kubernetes的鉴权体系

API Server中的鉴权框架及启用的鉴权模块负责鉴权

支持的鉴权模块

Node：专用的授权模块，它基于kubelet将要运行的Pod向kubelet进行授权；
ABAC：通过将属性（包括资源属性、用户属性、对象和环境属性等）组合在一起的策略，将访问权限授予用户
- 使用太复杂
- 零信任场景
- 需要鉴权引擎配合使用
RBAC：基于企业内个人用户的角色来管理对计算机或网络资源的访问的鉴权方法
- 公司内不同职位的人有不同的权限
- 基于角色的授权
Webhook：用于支持同Kubernetes外部的授权机制进行集成

另外两个特殊的鉴权模块是

AlwaysDeny 一直拒绝
AlwaysAllow 一直允许

配置方法

在kube-apiserver上使用 --authorization-mode 选项进行定义
kubeadm部署的集群，默认启用了Node和RBAC
多个模块彼此间以逗号分隔

RBAC术语

基于角色的授权

实体（Entity）

在RBAC也称为Subject，通常指的是User、Group或者是ServiceAccount

角色(Role)

承载资源操作权限的容器

资源（Resource)

在RBAC中也称为Object，指代Subject期望操作的目标，例如Secret、Pod及Service对象等

仅限于/api/v1/…及/apis///…起始的路径
其它路径对应的端点均被视作“非资源类请求（Non-Resource Requests）”，例如/api或/healthz等端点

动作（Actions)

Subject可以于Object上执行的特定操作，具体的可用动作取决于Kubernetes的定义

资源型对象
- 只读操作：get、list、watch等
- 读写操作：create、update、patch、delete、deletecollection等
非资源型端点仅支持get操作
- “非资源类请求（Non-Resource Requests）”，例如/api或/healthz等端点

角色绑定（Role Binding）

将角色关联至实体上，它能够将角色具体的操作权限赋予给实体 RoleBinding ClusterRoleBinding

RBAC 的基础概念

角色的类型

Cluster级别

称为ClusterRole，定义集群范围内的资源操作权限集合，包括

集群级别
名称空间级别的资源对象

Namespace级别

称为Role，定义名称空间范围内的资源操作权限集合包括

名称空间级别的资源对象

角色绑定的类型

ClusterRoleBinding

Cluster级别可以将实体（User、Group或 ServiceAccount）关联至ClusterRole

RoleBinding

Namespace级别可以将实体（User、Group或 ServiceAccount）关联至 Role

特殊地可以实体（User、Group或 ServiceAccount）关联至 ClusterRole

即便将Subject使用RoleBinding关联到了ClusterRole上，该角色赋予到Subject的权限
也会降级到RoleBinding所属的Namespace范围之内只会在交集内的权限生效

权限范围的描述

RBAC默认启用后 apiserver所有的客户端, 其请求都需要得到明确的许可授权才能执行对应的动作内置了很多clusterrole 和clusterrolebinding

RBAC的基本工作逻辑

默认的ClusterRole及ClusterRoleBinding

启用RBAC鉴权模块时，API Server会自动创建一组ClusterRole和ClusterRoleBinding对象

多数都以“system:”为前缀，也有几个面向用户的ClusterRole未使用该前缀，如cluster-admin、admin等
它们都默认使用“kubernetes.io/bootstrapping: rbac-defaults”这一标签

ClusterRole的类别

都有哪些clusterrole资源

kubectl get clusterrole

1、API发现相关的角色

system:basic-user
system:discovery
system:public-info-viewer

2、面向用户的角色

cluster-admin
admin
edit
view

3、核心组件专用的角色

system:kube-scheduler
system:volume-scheduler
system:kube-controller-manager
system:node
system:node-proxier

4、其它组件专用的角色

system:kube-dns
system:node-bootstrapper
system:node-problem-detector 节点问题探测 cpu负载磁盘打满的问题探测
system:monitoring 监控相关的

5、内置控制器专用的角色

...省略

命令使用

查看clusterrole 可以执行的权限细节

kubectl get clusterrole flannel -o yaml

查看当前的clusterrolebinding 关联情况

kubectl get clusterrolebinding

kubectl get clusterrolebinding cluster-admin -o yaml

让tom成为管理员

kubectl create clusterrolebinding  make_tom_as_clusteradmin --user=tom --clusterrole=cluster-admin

tom 有权限操作了

给mason用户绑定读权限

kubectl create role pods-reader --verb=get --verb=list --verb=watch --resource=pods

--resource 指定资源类型 --resource-name 指定对象

kubectl create rolebinding mason-as-reading --user=mason --role pods-reader

可以看到mason能够get pods

但是mason 不能看别的资源

给mason用户绑定一个view权限仅限default空间

kubectl create rolebinding mason-as-reading --user=mason --clusterrole view

mason 可以只可以查看default空间下的所有资源

给mason用户绑定一个view权限整个集群的名称空间都要看到

kubectl create clusterrolebinding mason-as-reading --user=mason --clusterrole view

mason 只可以查看所有空间下的所有资源

面向用户的角色

clusterrole 角色种类介绍

cluster-admin

system:masters 组集群级别的管理权限

允许用户在目标范围内的任意资源上执行任意操作；使用ClusterRoleBinding关联至用户时，授权操作集群及所有名称空间中任何资源；使用RoleBinding关联至用户时，授权控制其所属名称空间中的所有资源，包括Namespace资源自身；

admin

管理员权限名称空间级别的管理权限

主要用于结合RoleBinding为特定名称空间快速授权生成管理员用户
它能够将RoleBinding所属名称空间中的大多数资源的读/写权限授予目标用户
包括创建Role和RoleBinding的能力；
但不支持对ResourceQuota及Namespace本身进行操作；

edit

接近于admin的权限

支持对名称空间内的大多数对象进行读/写操作包括Secret
但不允许查看或修改Role及RoleBinding；

view

允许以只读方式访问名称空间中的大多数对象，但不包括Role、RoleBinding和Secret

Role 资源

命令式命令

kubectl create role NAME --verb=verb --resource=resource.group/subresource [--resource-name=resourcename] 
# verb：允许在资源上使用的操作（verb）列表 
# resources.group/subresource：操作可施加的目标资源类型或子资源列表 
# resourcename：特定的资源对象列表，可选

示例

kubectl create role pods-viewer --verb="get,list,watch" --resource="pods" --namespace=default

生成的资源对象的资源配置

ClusterRole和ClusterRoleBinding

命令式命令

ClusterRole：kubectl create clusterrole NAME --verb=verb --resource=resource.group [--resource-name=resourcename]

ClusterRoleBinding：kubectl create clusterrolebinding NAME --clusterrole=NAME [--user=username] [--group=groupname] [-- serviceaccount=namespace:serviceaccountname]

示例

kubectl create clusterrolebinding mason --clusterrole=view --group=developers

资源规范

ClusterRole的资源规范同Role相似 ClusterRoleBidning的资源规范跟RoleBinding相似

案例：Prometheus Server的权限需求

将Prometheus部署运行于Kubernetes之上并监控集群时，需要使用专用的ServiceAccount运行prometheus-server相关的Pod；

apiVersion: v1
kind: ServiceAccount
metadata:
  name: jenkins-master
  namespace: jenkins

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: jenkins-master
rules:
  - apiGroups: ["extensions", "apps"]
    resources: ["deployments"]
    verbs: ["create", "delete", "get", "list", "watch", "patch", "update"]
  - apiGroups: [""]
    resources: ["services"]
    verbs: ["create", "delete", "get", "list", "watch", "patch", "update"]
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["create","delete","get","list","patch","update","watch"]
  - apiGroups: [""]
    resources: ["pods/exec"]
    verbs: ["create","delete","get","list","patch","update","watch"]
  - apiGroups: [""]
    resources: ["pods/log"]
    verbs: ["get","list","watch"]
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: jenkins-master
roleRef:
  kind: ClusterRole
  name: jenkins-master
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  name: jenkins-master
  namespace: jenkins

案例：Jenkins Master 的权限需求

运行于Kubernetes之上的Jenkins，为了能够动态创建jenkins

github.com/iKubernetes…

apiVersion: v1
kind: ServiceAccount
metadata:
  name: jenkins-master
  namespace: jenkins

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: jenkins-master
rules:
  - apiGroups: ["extensions", "apps"]
    resources: ["deployments"]
    verbs: ["create", "delete", "get", "list", "watch", "patch", "update"]
  - apiGroups: [""]
    resources: ["services"]
    verbs: ["create", "delete", "get", "list", "watch", "patch", "update"]
  - apiGroups: [""]
    resources: ["pods"]
    verbs: ["create","delete","get","list","patch","update","watch"]
  - apiGroups: [""]
    resources: ["pods/exec"]
    verbs: ["create","delete","get","list","patch","update","watch"]
  - apiGroups: [""]
    resources: ["pods/log"]
    verbs: ["get","list","watch"]
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get"]

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: jenkins-master
roleRef:
  kind: ClusterRole
  name: jenkins-master
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  name: jenkins-master
  namespace: jenkins

promethues创建

github.com/iKubernetes…

kubernetes-鉴权体系、RBAC介绍、role、rolebing、clusterrolebing示例

Kubernetes的鉴权体系

支持的鉴权模块

配置方法

RBAC术语

实体（Entity）

角色(Role)

资源（Resource)

动作（Actions)

角色绑定（Role Binding）

RBAC 的基础概念

角色的类型

Cluster级别

Namespace级别

角色绑定的类型

ClusterRoleBinding

RoleBinding

权限范围的描述

RBAC的基本工作逻辑

默认的ClusterRole及ClusterRoleBinding

ClusterRole的类别

都有哪些clusterrole资源

1、API发现相关的角色

2、面向用户的角色

3、核心组件专用的角色

4、其它组件专用的角色

5、内置控制器专用的角色

命令使用

查看clusterrole 可以执行的权限细节

查看当前的clusterrolebinding 关联情况

让tom成为管理员

给mason用户 绑定读权限

给mason用户绑定一个view权限 仅限default空间

给mason用户绑定一个view权限 整个集群的 名称空间都要看到

面向用户的角色

clusterrole 角色种类介绍

cluster-admin

admin

edit

view

Role 资源

命令式命令

示例

生成的资源对象的资源配置

ClusterRole和ClusterRoleBinding

命令式命令

示例

资源规范

案例：Prometheus Server的权限需求

案例：Jenkins Master 的权限需求

promethues创建

给mason用户绑定读权限

给mason用户绑定一个view权限仅限default空间

给mason用户绑定一个view权限整个集群的名称空间都要看到