认证授权与准入控制

Posted 2021-03-22 jayce9102

一、访问控制概述

1. API server作为访问kubernetes集群的网关，也是唯一入口
2. 所有客户端访问集群都必须进行合法性检验：
   1）用户身份鉴别
   2）操作权限验证
   3）是否符合全局约束
   4）所有验证均通过才能访问或存入数据到etcd中
3. 客户端认证操作：由 API Server 配置的一到多个认证插件完成。收到请求后， API Server 依次调用为其配置的认证插件来认证客户端身份，直到其中一个插件可以识别出请求者的身 份为止
4. 授权操作由一到多个授权插件进行，它负责确定那些通过认证的用户是否有权限 执行其发出的资源操作请求

二、用户账户与用户组

1. User Account（用户账号）：
   1）一般是指由独立于Kubernete 之外的其他服务管理的用户账号（其他集群管理员，一般适用第三方插件管理，kubernetes不存在此类对象）
   2）User Account 通常用于复杂的业务逻辑管控，它作用于系统全局，其名称必须全局唯一
2. Service Account（服务账号）：
   1）指由Kubernetes API管理的账户，用于为Pod之中的服务进程在访问Kubernetes API时提供身份标识（identity）
   2）Service Account通常要绑定于特定的名称空间，他们由API Server或者通过手动创建，附带着一组存储为secret的用于访问API Server的凭据
   3）Service Account隶属于名称空间，仅用于实现某些特定的操作任务
3. 用户组
   1）Service Account与User Account都可以隶属于一个或多个组
   2）用户组只是用户账号的逻辑集合，本身没有操作权限。但是附加于组上的权限可由其内部的所有用户继承
4. 特殊的组
   1）system:unauthenticated ：未能通过任何一个授权插件检验的账号，即未通过认证测试的用户所属的组
   2）system :authenticated ：认证成功后的用户自动加入的一个组，用于快捷引用所有正 常通过认证的用户账号
   3）system:serviceaccounts：当前系统上的所有 Service Account 对象
   4）system :serviceaccounts :<namespace ＞：特定名称空间内所有的Service Account 对象

三、整体流程梳理

1. 认证插件负责鉴定用户身份（认证方式：客户端证书、承载令牌、身份验证代理或HTTP basic认证等）
   1）API Server接收到访问请求时，将调用认证插件尝试与以下属性关联
        Username：用户名
        UID：用户ID
        Groups：用户所属组
        Extra：键值对数据
   2）API Server 支持同时启用多种认证机制，但至少应该分别为 Service Account和User Account 各自启用一个认证插件
   3）同时启用多种认证机制时，认证过程会以串行的方式进行，直到一种认证机制成功完成即结束
   4）若认证失败，则服务器会响应 401 状态码，反之， 请求者就会被识别为某个具体的用户（以其用户名进行标识），并且随后的操作都将以此用 户身份来进行
2. 授权插件用于操作权限许可鉴别
   1）成功通过身份认证后的操作请求还需要转交给授权插件进行许可权限检查，以确保其拥有执行相应的操作的许可
   2）主要的授权插件
   　　（1）Node：基于Pod资源的目标调度节点来实现的对kubelet的访问控制
   　　（2）ABAC：attrubute-based access control，基于属性的访问控制
   　　（3）RBAC：role-based access control，基于角色的访问控制
   　　（4）Webhook：基于HTTP回调机制通过外部REST服务检查确认用户授权的访问控制
   　　（5）AlwaysDeny：总是拒绝（用于测试）
   　　（6）AlwaysAllow：总是运行（用于跳过授权验证）
   　　（7）补充：启动API Server时使用--authorzation-mode选项定义要启用的授权机制，多个之间使用逗号分隔
3. 准入控制用于在资源对象的创建、删除、更新或连接（proxy）操作时进行更精细的许可检查
   1）在客户端请求经过身份验证和授权检查之 后，但在对象持久化存储 etcd之前拦截请求
   2）用于实现在资源的创建、更新和删除操作期间强制执行对象的语义验证等功能，读取资源信息的操作请求不会经由准入控制器的检查
   3）常用准入控制器
   　　（1）AlwaysAdmit ：允许所有请求
   　　（2）AlwaysDeny ：拒绝所有请求 ，仅应该用于测试
   　　（3）AlwaysPulllmages ：总是下载镜像
   　　（4）NamespaceLifecycle ：拒绝于不存在的名称空间中创建资源 ，而删除名称空间将会级联删除其下的所有其他资源
   　　（5）LimitRanger ：可用资源范围界定，用于监控对设置了 LimitRange 的对象所发出的 所有请求，以确保其资源、请求不会超限
   　　（6）ServiceAccount ：用于实现 Service Account 管控机制的自动化，实现创建 Pod 对象 时自动为其附加相关的 Service Account 对象
   　　（7）Pers stentVolumeLabel ：为那些由云计算服务商提供的 PV 自动附加 region或zone 标签，以确保这些存储卷能够正确关联且仅能关联到所属的 region或zone
   　　（8）DefaultStorageClass ：监控所有创建 PVC 对象的请求，以保证那些没有附加任何专用Storag Class 的请求会自动设定一个默认值
   　　（9）ResourceQuota：用于对名称空间设置可用资源的上限，并确保在其中创建的任何设置了资源限额的对象都不会超出名称空间的资源配额
   　　（10）DefaultTolerationSeconds ：如果 Pod 对象上不存在污点宽容期限，则为它们设置默认的宽容期，以宽容“ notready: N oExecute ”和“ unreachable:NoExctute ”类的污点5分钟时间
   　　（11）ValidatingAdmission Webhook ：并行调用匹配当前请求的所有验证类的 Webhook, 任何一个校验失败，请求即失败
   4）检查期间，只有那些顺利通过所有准入控制器检查的资源操作请求的结果 才能保存到 etcd 中，实现持久存储