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 授权模块处于启用状态，其输入文件最初设置为允许所有用户执行所有操作。集群管理员需要编辑该文件，或者配置不同的授权器来限制用户可以执行的操作。