《Kubernetes进阶实战》第十章《认证，授权与准入控制》

待我称王封你为后i 2022-03-10 00:47 231阅读 0赞

在任何将资源或服务提供给有限使用者的系统上，认证和授权都是两个必不可少的功能，认证用于身份鉴别，而授权则实现权限分派。

API Server 作为 Kubernetes 集群系统的网关，是访问及管理资源对象的唯一人口，余下所有需要访问集群资源的组件，包括 kube-controller-manager ，kube-scheduler kubelet和kube-proxy 等集群基础组件 ，CoreDNS 等集群的附加组件以及此前使用的 kubectl命令等都要经由此网关进行集群访问和管理

客户端访问 API服务的途径通常有三种： kubectl， 客户端库或者直接使用 REST 接口进行请求，而可以执行此类请求的主体也被Kubernetes 分为两类：现实中的“人”和 Pod 象，它们的用户身份分别对应于常规用户(User Account ）和服务账号（ Service Account）

*  Use Account （用户账号）： 一般是指由独立于 ub rnete 之外的其他服务管理的用户账号，例如由管理员分发的密钥 Keystone 一类的用户存储（账号库）、甚至是包含有用户名和密码列表的文件等 kbernetes中不存在表示 类用户账号的对象，因此不能被直接添加进 Kubernetes 系统中
 *  Service Account （服务账号） 是指 由kubernetes API 管理的账号，用于为 Pod 之中的服务进程在访问 Kubernetes API 时提供身份标识（ identity Service Account) 通常要绑定于特定的名称空间，它们由 API Server 建，或者通过 API 用于动创附带着一组存储为sercret 的用于访问 API Server 的凭据

User Account 通常用于复杂的业务逻辑管控，它作用于系统全局，故其名称必须全局唯一

Service Account 隶属于名称空间，仅用于实现某些特定的操作任务，因此要轻量得多

这两类账号都可以隶属于一个或多个用户组 用户组只是用户账号的逻辑集合，它本身并没有操作权限，但附加于组上的权限可由其内部的所有用户继承，以实现高效的授权管理机制

Kubernetes有以下几个内建的用于特殊目的的组

*  system:unauthenticated ：未能通过任何 个授权插件检验的账号，即未通过认证测试的用户所属的组
 *  system :authenticated ：认证成功后的用户自动加入的 个组，用于快捷引用所有正常通过认证的用户账号
 *  system se viceaccounts 当前系统上的所有 Service Account 对象
 *  system :serviceaccou nts :<namespace ＞：特定名称 间内所有的 巳凹ice Account 对象

API 请求要么与普通用户或服务账户进行绑定，要么被视为匿名请求 这意味着群集内部或外部的每个进程，包括由人类用户使用的kubectl ，到节点上的 kubelet ，再到控制平面的成员组件，必须在向 API 服务器发出请求时进行身份验证，否则即被视为匿名用户

API Server 处理请求的过程中，认证插件负责鉴定用户身份，授权插件用于操作权限许可鉴别，而准入控制则用于在资源对象的创建、删除、更新或连接（ proxy ）操作时实现更精细的许可检查

Kubernetes 使用身份验证插件对 API 请求进行身份验证，支持的认证方式包括客户端证书、承载令牌（ bearer tokens ）、身份验证代理（ authenticating proxy ）或 HTTP basic 认证等

API Server 接收到访问请求时，它将调用认证插件尝试将以下属性与访 请求相关联

*  Username 用户名，如 kubernetes admin
 *  UID ：用户的数字标签符，用于确保用户身份的唯一性
 *  Groups 用户所属的组，用于权限指派和继承
 *  Extra 键值数据类型的字符串，用于提供认证时需要用到的额外信息

API Server 支持同时启用多种认证机制，但至少应该分别为 Service Account 和 User Account 各自启用 个认证插件 同时启用多种认证机制时，认证过程会 串行的方式进行，直到一种认证机制成功完成即结束

API Server 支持以下几种具体的认证方式，其中所有的令牌认证机制通常被统称为承载令牌认证

*  X509客户端整数认证
 *  静态令牌文件
 *  引导令牌
 *  静态密码文件
 *  服务账户令牌
 *  OpenID连接令牌
 *  Webhook令牌
 *  认证代理
 *  Keystone密码
 *  匿名请求

API Server 是一种 REST API ，除了身份认证信息之外，一 个请求报文还需要提供操作方法及其目标对象具体来说，请求报文包含如下信息

*  API ：用于定义请求的目标是否为一个 PI 资源
 *  Request path： 请求的非资源型路径，如/api healthz
 *  API group: 要访问的API 组，仅对资源型请求有效 默认为“ core API group”
 *  Namespace: 目标资源所属的名称空间，仅对隶属于名称 空间类型的 资源有效
 *  API request verb : API 请求类的操作，即资源型请求（对资源执行的操作），包括
 *  get list create update patch watch proxy redirect de lete 和出letecollection
 *  HTTP request verb : HTTP 请求类 的操作，即非资源型请求要执行的操作，如 get post put delete
 *  Resource ：请求的目标资源的 ID 或名称
 *  Subresource 请求的子资源

API Server 主要支持使用四类内建的授权插件来定义用户的操作权限

*  Node 基于 Pod 资源的目标调度节点来实现的对 kubelet 的访问控制
 *  ABAC: attribute-based access control 基于属性的访问控制
 *  RBAC: role-based access control ，基于角色的访问控制
 *  Webhook 基于 HTTP 回调机制通过外部 REST 服务检查确认用户授权的访问控制

准入控制器 Admission Controller ）则用于在客户端请求经过身份验证和授权检查之后，但在对象持久化存储 etc 之前拦截请求，用于实现在资源的创建 更新和删除操作期间强制执行对象的语义验证等功 ，读取资源信息的操作请求不会经由准入控制器的检查。API Server 内置了许多准入控制器，常用的包含如下几种

*  1 ) AlwaysAdmit ：允许所有请求
 *  2 ) AlwaysDeny ：拒绝所有请求 ，仅应该用于测试
 *  3 ) AlwaysPulllmages ：总是下载镜像 ，即每次创建Pod 对象之前都要去下载镜像 ，常用于多租户环境中以确保私有镜像仅能够被拥有权限的用户使用
 *  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 ”和“ unreachab le:N oExctute ”类的污点 5分钟时间
 *  11 ) ValidatingAdmission Webhook ：并行调用匹配当前请求的所有验证类的 Webhook,任何一个校验失败，请求即失败
 *  12) MutatingAdmissionWebhook ：串行调用匹配当前请求的所有变异类的 Webhook,每个调用都可能会更改对象

任何 一个准入控制器的拒绝都将导致请求失败

服务账户就是用于让 Pod 对象内的容器进程访问其他服务时提供身份认证信息的账户。一个Service Account 资源一般由用户  
名及相关的 Secret 对象组成。

Service Account 自动化

容器中的进程使用token向 API Server 发起连接请求 ，进而由认证插件完成用户认证并将 用户 传递给授权插件

Kubernetes 系统通过 个独 的组件间的相互协作来实现服务账户的自动化，三个组件具体为： Service Account 准入控制器、令牌控制器（ token controller ）和 Service Account账户控制器 。Service Account 控制器负责为名称空间管理相应的 源，并确保 个名称空间中都存在 个名为“default ”的 Service Account 对象。包括如下操作：

*  若 Pod 没有明确定义使用的 ServiceAccount 对象，则将其设 为“ default“
 *  确保 Pod 明确引用的 ServiceAccount 已存在，否则请求将被拒绝
 *  若 Pod 对象中不包含 Imag PullSecerts ，则把 Service Account和 ImagePullSecrets舔加于其上
 *  为带有访问 API令 牌的 Pod 添加 个存储卷
 *  为 Pod 对象中的 个容器添 加一个volumeMounts ，挂载至／var run/secrets/kubemetes.io/serviceaccount

令牌控制器是 controller-manager 的子组件，工作于异步模式 其负责完成的任务具体如下

*  监控 Service Account 的创键 操作， 并为其添加用 访问 API 的Secret 对象
 *  监控 Service Account 的删除操作，并删除其相关的所有 Service Account 令牌密钥
 *  监控Secret 对象的添 操作，确保其引用的 Service Account 己存在，并在必要时为Secret 对象添加认证令牌
 *  监控 Secret 对象的删除操作，以确保删除每个 Service Account 中对此 Secret 的引用

每个 Pod 对象均可附加其所属名称空间中的一个 Service Account 资源，且只能附加一个  
创建pod 资源时，用户可使用“ spec.serviceAccountName ”属性直接指定要使用的 Service Account 对象，或 省略此宇段而由其自动附加当前名称空 间中默认的 Service Account (default）

创建Pod 象时，可为 Pod对象指定使用自定义的服务账户，从而实现自主控制 pod对象资源的访问权限

ServiceAccount 资源还可以基于 spec.imagePul!Secret 宇段附带一个由下载镜像专用的Secret 资源组成的列表，用于在进行容器创建时，从某私有镜像仓库下载镜像文件之前进行服务认证。

X.509数字证书认证

SSL/TLS 最常见的使用场景是将 X.509 证书与服务器端相关联，但不为客户端使用证书，这意味着客户端可以验证服务端的身份，但服务端无法验证客户端的身份（至少不能通过 SSL/TLS 协议进行）

Kubernetes 集群中各资源的状态信息 包括 Secret 对象中的敏感信息 均以明文方式  
存储于 etcd 中，因此， etcd 集群内各节点间的通信，以及各节点与其客户端（主要是 API sevrver ）之间的通信都应该以加密的方式进行，并需进行身份验证。

使用 ubeadm 初始集群后生成的／etc/kubemetes/admin.conf 文件即为 kubeconfig 格式的配置文件， kubeadm init 命令自动生成，可由 kubectl 载（默认路径为 $HOME/ kube config ）后用于接人服务器 kubectl config view ”命 能够显示 前正在使用的配置文件。事实上 ，任何类型的 API Server 客户端都可以使用 kubeconfig 进行配置

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3ppc2VmZWl6aHU_size_16_color_FFFFFF_t_70][]

kubeconfig 是一个文本文件，虽然支持使用文本处理工具直接进行编辑，但这里建议用户使用“ kubectl config ”命令进行设定，它能够自动进行语法检测等额外功能

kubectl config 令的常用操作包含如下：

*  kubectl config view ：打印 kubeconfig 文件内容
 *  kubectl config set cluster ：设置 kubeconfig clusters 配置段
 *  kubectl config set er dentials 设置 kubeconfig users 配置段
 *  kubectl config set-context 设置 kubeconfig contexts 配置段
 *  kubectl config use-context 设置 kubeconfig的 current-conte 配置段

再往下走：请看以下两篇博文 写的非常详细，亲测很是OK

[认证，授权和准入控制][Link 1]

[认证及serviceaccount,RBAC][serviceaccount_RBAC]

[Kubernetes dashboard 认证访问][Kubernetes dashboard]

[dashboard认证及分级授权][dashboard]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3ppc2VmZWl6aHU_size_16_color_FFFFFF_t_70]: /images/20220310/8d3ddb2174274051bd576a4eede2983f.png
[Link 1]: https://www.cnblogs.com/linuxk/p/9772117.html
[serviceaccount_RBAC]: http://blog.itpub.net/28916011/viewspace-2215100/
[Kubernetes dashboard]: https://www.cnblogs.com/linuxk/p/9783510.html
[dashboard]: http://blog.itpub.net/28916011/viewspace-2215214/