其他分享
首页 > 其他分享> > Kubernetes——访问控制

Kubernetes——访问控制

作者:互联网

访问控制

  在用户租户的系统上,认证和授权都是两个必不可少的功能。认证用于身份鉴别,授权是用于实现权限分派。

  Kubernetes 以插件化方式实现了这两种功能,且分别存在多种可用的插件。

  API Server 是 Kubernetes 集群系统的唯一网关入口,像 kube-controller-manager、kube-scheduler、kubelet、kubeclt 和 kube-proxy 等集群组件、CoreDNS 等集群的附加组件都需要经由 API Server 网关进行集群访问和管理。这些客户端均要经由 API Server 访问或改变集群状态并完成 etcd 数据存储,API Server 会对每次访问请求进行合法校验,包括身份鉴权,操作权限验证,以及操作是否符合全局规范约束等。

  API Server 通过一个或者多个认证插件完成访问控制。当收到客户端请求后,API Server 依次调用为其配置的认证插件来认证客户端身份,直到其中一个插件可以识别出请求者的身份为止。授权操作也是由一个或多个授权插件完成。通过认证、授权检测的用户请求,还要经过一个到多个的准入控制器插件的遍历检查。

一、用户帐号与用户组

  Kubernetes 并不会存储由认证插件从客户端请求中提取出的用户及所属组的信息,它们仅仅用于检验用户是否有权限执行其所请求的操作。

  客户端访问 API 服务的途径通常有三种:

  客户端请求的主体一般分为两类(也就是Kubernetes系统中 User Account 和 Service Account):

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

  Kubernetes 有以下几个内建的组:

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

二、API Server 常见认证方式

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

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

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

  API Server 支持同时启用多种认证机制,但至少应该分别为 Service Account 和 User Account 各自启用一个认证插件。启用多种认证机制时,认证过程会以串行的方式进行,直到一种认证机制成功完成即结束。若认证失败,则服务器会响应 401 状态码,反之,请求者就会被识别为某个具体的用户(以其用户名进行标识),并且随后的操作都将以此用户身份来进行。

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

1)X509客户端证书认证

  客户端在请求报文中携带 X509 格式的数字证书用于认证,认证通过之后,证书中的主体标识(Subject)将被识别为用户标识,其中的 CN(CommonName)字段是用户名,O(Organization)是用户所属的组,如 "/CN=iliux/O=opmasters/O=admin"中,用户名为 ilinux,其属于 opmasters 和 admin 两个组。

2)静态令牌文件(Static Token File)

  即保存着令牌信息的文件,由 kube-apiserver 的命令行选项 --token-auth-file 加载,且服务器启动后不可更改;HTTP 客户端也能使用承载令牌进行身份验证,将令牌进行编码后,通过请求报文中的 Authorization 首部承载传递给 API Server 即可。

3)引导令牌(Bootstrap Token)

  一种动态管理承载令牌进行身份认证的方式,常用于简化新建 Kubernetes 集群的节点认证过程,需要通过 --experimental-bootstrap-token-auth 选项启用。

  有新的个工作节点首次加入时,Master 使用引导令牌确认节点身份的合法性之后自动为其签署数字证书以用于后续的安全通信,使用 kubeadm join 命令将节点加入 kubeadm 初始化的集群时使用的就是这种认证方式。

  这些令牌作为 Secret 存储在 kube-system 命名空间中时,可以动态管理和创建它们,而 Controller Manager 包含一个 TokenCleaner 控制器,用于删除过期的引导令牌。

4)静态密码文件

  用户名和密码等令牌以明文格式存储的 CSV 格式文件,由 kube-apiserver 使用 --basic-auth-file 选项进行加载。客户端在 HTTP basic 认证中将认证用户的用户名和密码编码后以承载令牌的格式进行认证。

5)服务账户令牌

  由 kube-apiserver 自动启用,并可使用可选选项加载 --service-account-key-file 验证承载令牌的密钥,省略时将使用 kube-apiserver 自己的证书匹配的私钥文件。

  Service Account 通常由 API Server 自动创建,并通过 ServiceAccount 准入控制器将其注入 Pod 对象,包括 Service Account 上的承载令牌,容器中的应用程序请求 API Server 的服务时将以此完成身份认证。

6)OpenID 连接令牌

  OAuth2 的一种认证风格,由 Azure AD、Salesfore 和 Google 等 OAuth2 服务商所支持,协议的主要扩展是返回的附加字段,其中的访问令牌也称为 ID 令牌。

  它属于 JSON Web 令牌(JWT)类型,有着服务器签名过的常用字段,如 email 等。

  kube-apiserver 启用这种认证功能的相关选项较多。

7)Webhook 令牌

  HTTP 身份验证允许将服务器的 URL 注册为 Webhook,并接收带有承载令牌的 POST 请求进行身份认证。

  客户端使用 kubeconfig 格式的配置文件,在文件中,"user" 指的是 API 服务器 Webhook,"cluster" 指的是 API Server。

 8)认证代理

  API Server 支持从请求首部的值中识别用户,如 X-Remote-User 首部,它旨在与身份验证代理服务结合,并由该代理设置相应的请求首部。

9)Keystone 密码

  借助于外部的 Keystone 服务器进行身份验证。

10)匿名请求

  未被任何验证机制明确拒绝的用户即为匿名用户,其会被自动标识为用户名为 system:anonymous,并隶属于 system:unauthenticated 用户组。

  在 API Server 启用了除 AlwaysAllow 以外的认证机制时,匿名用户处于启用状态,不过管理员可以通过 --anonymous-auth=false 选项将其禁用。

三、API Server 请求报文信息格式

  API Server 是一种 REST API,除了身份认证信息之外,一个请求报文还需要提供操作方法及目标对象,如针对某 Pod 资源对象进行的创建、查看、修改或删除操作等,具体来说,请求报文包含如下信息:

 四、API Server 四种内建授权插件

  为了核验用户的操作许可,成功通过身份认证后的操作请求还需要转交给授权插件进行许可权限检查,以确保其拥有执行相应的操作的许可。API Server 主要支持使用四中内建的授权插件来定义用户的操作权限。

五、AlwaysDeny 和 AlwaysAllow 两种特殊授权插件

  AlwaysDeny 和 AlwaysAllow 两个是特殊的插件,其中 AlwaysDeny(总是拒绝)仅用于测试,而 AlwaysAllow(总是允许)则用于不期望进行授权检查时直接于授权检查阶段放行的所有操作请求。

  启动 API Server 时,"--authorization-mode" 选项用于定义要启用的授权机制,多个选项彼此之间以逗号分隔。

六、API Server 内置准入控制器

  准入控制器(Admission Controller)则用于在客户端请求经过身份验证和授权检查之后,但在对象持久化存储 etcd 之前拦截请求,用于实现在资源的创建、更新和删除操作期间强制执行对象的语义验证等功能,读取资源信息的操作请求不会经由准入控制器的检查。

  API Server 内置了许多准入控制器,常用的包含如下几种:

标签:令牌,请求,Kubernetes,访问控制,用户,Server,API,认证
来源: https://www.cnblogs.com/zuoyang/p/16435121.html