# k8s 授权概述

在 k8s 中必须经过认证阶段,才到授权请求(授权访问权限)。有关认证的信息,请参阅访问控制概述。

# 确定请求是否通过

k8s 使用 APIserver 授权 API 请求。它根据策略来评估所有请求属性,是否给于通过。

(k8s 使用 APIserver,访问控制和依赖特定资源对象的策略由(Admission Controllers)准入控制器处理。)

当配置多个授权模块时,会按顺序检查每个模块,如果有任何模块授权通过,则继续执行下一步的请求。如果所有模块拒绝,则该请求授权失败(返回 HTTP 403)。

# 查看请求属性

k8s 只对以下的 API 请求属性进行检查:

  • user - 认证期间提供的 user 字符串
  • group - 认证用户所属的组名列表
  • “extra” - 由认证层提供的任意字符串键到字符串值的映射
  • API - 指示请求是否为 API resource
  • Request path - 到其他非 request 端点的路径,如/api 或/healthz。
  • API request verb - API verbs get,list,create,update,patch,watch,proxy,redirect,delete,和 deletecollection 用于请求 resource。要确定 resource API 端点的请求 verbs。
  • HTTP request verb - HTTP verbs get,post,put,和 delete 用于非资源请求
  • Resource -被访问(仅用于 resource 请求)的 resource 的 ID 或名字- *对于使用 resource 的请求 get,update,patch,和 delete,必须提供 resource 名称。
  • Subresource - 正在访问的 subresource (仅用于请求 resource )
  • Namespace - 正在访问对象的命名空间(仅针对命名空间的请求资源)
  • API group - 正在访问的 API 组(仅用于请求资源)。空字符串指定核心 API 组。

# Determine the Request Verb

要确定资源对象 API 端点请求的动词,请查看 HTTP 动词以及请求是否对单个资源或资源集合进行操作:

参考下表:

HTTP Verb Request Verb
POST create
GET,HEAD get (for individual resources), list (for collections)
PUT update
PATCH patch
DELETE delete (for individual resources), deletecollection (for collections)

k8s 会使用专门的动词检查授权。例如:

  • PodSecurityPolicy
  • RBAC
  • Authentication

# 授权模块

  • Node - v1.7+支持 Node 授权,配合 NodeRestriction 准入控制来限制 kubelet 仅可访问 node、endpoint、pod、service 以及 secret、configmap、PV 和 PVC 等相关的资源,了解更多 Node 授权模式的信息,请参阅 Node 授权
  • ABAC - 基于属性的访问控制(ABAC)定义了访问控制范例,通过将属性组合在一起的策略来授予用户访问权限。ABAC 策略可以使用任何类型的属性(用户属性,资源属性,对象,环境属性等)。了解更多 ABAC 模式的信息,请参阅 ABAC 模式
  • RBAC - 在 k8s1.6 版本中新增角色访问控制机制(Role-Based Access,RBAC)让集群管理员可以针对特定使用者或服务账号的角色,进行更精确的资源访问控制。在 RBAC 中,权限与角色相关联,用户通过成为适当角色的成员而得到这些角色的权限。这就极大地简化了权限的管理。在一个组织中,角色是为了完成各种工作而创造,用户则依据它的责任和资格来被指派相应的角色,用户可以很容易地从一个角色被指派到另一个角色。要了解有关使用 RBAC 模式的更多信息,请参阅 RBAC 模式 .. *截至 1.6 版本 RBAC 模式还是 beta 版本。
  • Webhook - WebHook 是一个自定义 HTTP 回调方法:事件发生时发送 HTTP POST; 通过 HTTP POST 进行简单的事件通知。实现 WebHooks 的 Web 应用程序将在某些事件发生时向 URL 发送消息。了解如何使用 Webhook 模式的更多信息,请参阅 Webhook 模式
  • Custom Modules - 可以创建 k8s 的(Custom Modules)自定义模块。要了解更多信息,请参阅下面的“自定义模块”。

# 自定义模块

APIserver 调用 Authorizer 接口:

type Authorizer interface {
  Authorize(a Attributes) error
}

来确定是否允许 API 的操作。

Authorizer 插件是实现此接口的模块。Authorizer 插件代码在 pkg/auth/authorizer/$MODULENAME。

# 为授权模块使用 flags

策略中需要包含一个 flag,来指定你的策略包含的哪种授权模块:

使用以下 flags:

    • --authorization-mode=ABAC 基于属性的访问控制(ABAC)模式允许使用本地文件配置策略。
    • --authorization-mode=RBAC 基于角色的访问控制(RBAC)模式允许使用 k8s API 创建和存储策略。
    • --authorization-mode=WebhookWebHook 是一种 HTTP 回调模式,允许使用远程 REST 管理授权。
    • --authorization-mode=AlwaysDeny 此 flag 阻止所有请求。仅使用此 flag 进行测试。
    • --authorization-mode=AlwaysAllow 此标志允许所有请求。只有在不需要 API 请求授权的情况下才能使用此标志。

可以选择多个授权模块。如果其中一种模式是 AlwaysAllow,则覆盖其他模式,并允许所有的 API 请求。

# 版本说明

对于 1.2 版本,由 kube-up.sh 配置创建的集群,任何请求都不需要授权。

从 1.3 版本开始,由 kube-up.sh 配置创建的集群,默认 ABAC 授权模块处于启用状态,其输入文件最初设置为允许所有用户执行所有操作。集群管理员需要编辑该文件,或者配置不同的授权器来限制用户可以执行的操作。

Last Updated: 6/17/2023, 6:57:19 PM