Kubernetes（K8s）_10_认证机制

认证机制

API Server认证流程：用户请求认证授权准入控制

（1）用户

1）用户分为：UserAccount（管理员使用）、ServiceAccount**（**Pod使用）

2）UserAccount和ServiceAccout均属于一个或多个组；

3）Kubernetes集群中有以下默认组：

组名	说明
system:unauthenticated	用于所有认证插件 都不会认证用户身份的请求
system:authenticated	自动分配一个成功通过认证的用户
system:serviceaccounts	包含系统中所有的ServiceAccount
system:serviceaccounts:命名空间	包含指定命名空间中 所有的ServiceAccount

//Kubernetes集群中并不存在真实的用户

（2）认证

1）作用：通过一个或多个认证插件以确定用户身份；

2）认证插件会返回用户名、用户ID和用户所在组的信息；

3）常用的认证方式如下：

认证方式	说明
token	通过共享密钥
TLS	通过API Server和用户做双向证书认证
HTTP	通过基础的HTTP连接认证

//若存在多个认证插件，用户只需通过其中一个即可进入授权阶段

//默认在~/.kube/config保存用户访问API Server的密钥相关信息，当kubectl访问API Server时，会自动读取该文件以完成API Server认证

（3）授权

1）作用：通过一个或多个授权插件确定用户的可执行权限；

2）授权插件主要使用RBAC（默认无任何权限）；

3）授权时可使用以下授权词：

授权词	说明
get	列出单个资源
list	列出资源类型的集合
create	创建
update	修改全部资源
patch	修改部分资源
watch	动态监控
proxy	代理
redirect	重定向
use	调用
delete	删除
deletecollection	级联删除

//若存在多个授权插件，用户只需通过其中一个即可进入准入控制阶段

//RBAC只能允许授权，不能拒绝授权

（4）准入控制

1）作用：验证创建、修改和删资源的请求（指定可操作资源对象）；

如：API Server认证流程

Kubernetes集群中接收到任意的API请求，在其内部都被转换成URL请求路径

1）操作Kubernetes中的资源时，本质是在对URL进行CURD操作；

2）授权的权限可应用于URL路径资源和non-resource URL路径资源；

//API Server对外暴露的URL路径并不一定映射到对应的资源

ServiceAccount

ServiceAccount（SA）：为Kuberntes集群中的Pod提供身份

1）ServiceAccount属于Kubernetes的一种资源类型；

2）每个命名空间在创建时，会创建一个默认的ServiceAccount；

3）每个命名空间中可创建无限多个ServiceAccount；

每个Pod都会与一个SA相绑定

1）两者需在同一个命名空间；

2）SA可绑定多个Pod，但单个Pod仅能绑定一个SA；

3）可将不同的SA与Pod绑定，以实现控制Pod的可访问资源权限；

如：Pod和SA的关系

Pod通过SA和API Server通信的流程：

1）Pod与一个SA绑定（身份证明）；

2）认证插件对Pod容器中存储SA认证的token进行认证；

3）认证通过后，认证插件将SA用户名传递给API Server；

//token默认存储位：/var/run/secrets/kubernetes.io/serviceaccount/token

//默认返回格式：system：serviceaccount：命名空间：SA用户名

创建ServiceAccount

ServiceAccount的创建方式分为：create命令和YAML文件

1）使用YAML文件创建SA较为麻烦，一般使用create命令创建；

//或者使用create命令重定向生成YAML文件，再通过YAML文件创建

（1）create命令创建ConfigMap格式：

kubectl create serviceaccount SA名

1）若强制Pod仅可挂载SA中指定的密钥，则需加上该选项：

kubernetes.io/enforce-mountable-secrets=“true”

如：通过create命令创建SA，并查看其详细信息

//SA中使用身份认证的token是JWT token

（2）将创建后的SA与Pod绑定：

1）Pod的YAML文件中的spec字段下的serviceAccountName指定，格式如下：

spec：
  serviceAccountName：SA名

2）必须在Pod创建时与SA绑定（Pod创建后，不能修改其绑定的SA）；

RBAC

RBAC（Role-Based Access Control）：基于角色的访问控制

1）原理：用户通过成为角色（Role）而得到这些角色所具有的权限

2）RBAC默认阻止未授权用户查看和修改集群状态；

//默认创建的SA不可查看和修改集群状态

//Kubernetes1.8.0版本后RBAC插件升级为GA（通用可用性），且默认开启

Kubernetes集群通过4种资源类型实现RBAC：

资源类型名	作用
Role（角色）	配置在指定资源的权限
ClusterRole（集群角色）
RoleBinding（角色绑定）	将角色和用户、SA或组绑定
ClusterRoleBinding（集群角色绑定）

1）Role和RoleBinding属于命名空间级别的资源；

2）ClusterRole和ClusterRoleBinding属于集群级别的资源；

如：通过RBAC实现的对指定资源的操作权限控制

Role/RoleBinding

Role的创建方式分为：create命令和YAML文件

1）普通Role不可对集群级别的资源和非自愿类型的URL进行授权；

（1）通过YAML文件创建Role的格式：

apiVersion:  rbac.authorization.k8s.io/v1
kind:  Role
metadata:
  namespace:  所属命名空间
  name:  Role 名
rules:
 - apiGroups:  [“组名”]
   resources:  [“资源类型”]
   verbs:  [“授权词1”， “授权词N”]

1）若省略命名空间，则默认在当前命名空间中建立；

2）资源类型必须是复数形式（资源类型名后加s）；

如：创建Role，其名为service-reader

1）编写YAML文件；

2）创建Role；

（2）通过create命令创建Role的格式：

kubectl create role Role名 --verb=授权词1，授权词N --resource=资源类型 -n
所属命名空间

RoleBinding的创建方式分为：create命令和YAML文件

1）使用YAML文件创建较为麻烦，一般使用create命令创建；

//或者使用create命令重定向生成YAML文件，再通过YAML文件创建

（1）通过create命令创建RoleBinding：

kubectl create rolebinding RoleBinding名 --role=绑定的Role serviceaccount=被绑定的SA -n 命名空间

1）若指定其所属用户，可通过选项：–user

2）若指定其所属组，可通过选项：–group

3）可绑定其他命名空间的SA，实现该Role下的Pod可访问其他命名空间；

如：通过create 命令创建RoleBinding

如：续上，将Role和RoleBinding绑定后实现的访问

如：RoleBinding绑定其他命名空间的SA实现Pod跨命名空间访问资源

ClusterRole/ClusterRoleBinding

ClusterRole的创建方式分为：create命令和YAML文件

1）集群Role可对集群级别的资源和非自愿类型的URL进行授权；

2）集群Role也可作为单个命名空间内部绑定的公共Role；

（1）通过YAML文件创建ClusterRole的格式：

apiVersion:  rbac.authorization.k8s.io/v1
kind:  ClusterRole
metadata:
  namespace:  所属命名空间
  name:  Role 名
rules:
 - apiGroups:  [“组名”]
   resources:  [“资源类型”]
   verbs:  [“授权词1”， “授权词N”]

1）若省略命名空间，则默认在当前命名空间中建立；

2）资源类型必须是复数形式（资源类型名后加s）；

（2）通过create命令创建ClusterRole的格式：

kubectl create clusterrole ClusterRole名 --verb=授权词1，授权词N --resource=资源类型 -n 所属命名空间

ClusterRoleBinding的创建方式分为：create命令和YAML文件

1）使用YAML文件创建较为麻烦，一般使用create命令创建；

//或者使用create命令重定向生成YAML文件，再通过YAML文件创建

（1）通过create命令创建ClusterRoleBinding：

kubectl create clusterrolebinding ClusterRoleBinding名 --clusterrole=绑定的Role serviceaccount=被绑定的SA -n 命名空间

1）若指定其所属用户，可通过选项：–user

2）若指定其所属组，可通过选项：–group

3）可绑定其他命名空间的SA，实现该Role下的Pod可访问其他命名空间；

如：通过创建ClusterRole/ClusterRoleBinding实现对集群中任意资源的访问

4种资源类型的不同组合方式可实现对不同资源的访问控制：

角色类型	绑定类型	可访问资源
Role	RoleBinding	可访问Role所在命名空间的资源
ClusterRole	RoleBinding	可访问RoleBinding所在命名空间的资源
ClusterRole	ClusterRoleBinding	可访问集群级别的、非资源类型URL的和任意命名空间中的资源

1）Role和ClusterRoleBinding绑定无实际意义

2）通过ClusterRole和RoleBinding的绑定可实现多个角色公用一个绑定；

如：Role、RoleBinding、ClusterRole和ClusterRoleBinding属于不同级别的资源

默认ClusterRole/ClusterRoleBinding

API Server默认创建ClusterRole/ClusterRoleBinding以实现集群控制面管理

1）由API Server创建的，大部分前缀为“system：”

2）所有默认创建都有标签“kubernetes.io/bootstrapping=rbac-defaults”

（1）默认集群级别的ClusterRole/ClusterRoleBinding

默认ClusterRole	默认ClusterRoleBinding	说明
system：basic-user	system：authenticated	允许用户以只读方式访问基本信息
system：discovery	system：authenticated	允许以只读方式访问API发现端点
system：public-info-viewer	system：authenticated system：unauthenticated	允许以只读方式访问集群非敏感信息

（2）默认用户级别的ClusterRole/ClusterRoleBinding

默认ClusterRole	默认ClusterRoleBinding	说明
cluster-admin	system：masters	拥有超级管理员权限
admin	无	拥有管理员权限
edit	无	可对命名空间中的大部分资源进行读写操作（不可修改Role和RoleBinding）
view	无	可对命名空间中大部分资源进行读操作（不允许查看Role和RoleBinding）

1）cluster-admin：Kubernetes集群中超级管理员用户，可操作集群中任意资源；

2）管理员权限：在对应RoleBinding所在的命名空间中对大部分资源拥有读写操作权限（包括Role和RoleBinding）

（3）集群的主要组件相关的ClusterRole/ClusterRoleBinding

默认ClusterRole	默认ClusterRoleBinding	说明
system：kube-scheduler	system：kube-scheduler	允许访问 scheduler组件 所需的资源
system：volume-scheduler	system：kube-scheduler	允许访问 kube-scheduler组件所需的卷资源
system：kube-controller-manager	system：kube-controller-manager	允许访问 Controller组件 所需的资源
system：node	无	允许访问 kubelet组件 所需的资源
system：node-proxier	system：kube-proxy	允许访问 kube-proxy组件 所需的资源

（4）附加组件相关的ClusterRole/ClusterRoleBinding

默认ClusterRole	默认ClusterRoleBinding	说明
system：auth-delegator	无	允许将认证和授权操作外包出去
system：kube-aggregator	无	为kube-aggregator组件定义的Role
system：kube-dns	无	为kube-dns组件定义的Role
system：kubelet-api-admin	无	允许kubelet API的完全访问权限
system：node-bootstrapper	无	允许访问执行kubelet TLS启动引导所需的资源
system：node-problem-detector	无	为node-problem-detector组件定义的Role
system：persistent-volume-provisioner	无	允许访问大部分动态卷驱动所需资源
system：monitoring	system：monitoring	允许对控制平面短短的读操作