授权概述

在Kubernetes中，您必须在授权（授予访问权限）之前进行身份验证（登录），有关身份验证的信息，请参阅 访问控制概述.

Kubernetes期望REST API请求中常见的属性。这意味着Kubernetes授权适用于现有的组织范围或云提供商范围的访问控制系统，除了Kubernetes API之外，它还可以处理其他API。

Kubernetes 使用 API ​​服务器授权 API 请求。它根据所有策略评估所有请求属性来决定允许或拒绝请求。一个API请求的所有部分必须被某些策略允许才能继续。这意味着默认情况下拒绝权限。

（尽管 Kubernetes 使用 API ​​服务器，但是依赖于特定种类对象的特定字段的访问控制和策略由准入控制器处理。）

配置多个授权模块时，将按顺序检查每个模块。如果任何授权模块批准或拒绝请求，则立即返回该决定，并且不会与其他授权模块协商。如果所有模块对请求没有意见，则拒绝该请求。一个拒绝响应返回 HTTP 状态代码 403 。

审查您的请求属性

  • user - 身份验证期间提供的字符串。
  • group - 经过身份验证的用户所属的组名列表。
  • extra - 由身份验证层提供的任意字符串键到字符串值的映射。
  • Request path - 各种非资源端点的路径，如/api或/healthz。
  • API request verb - API 动词get，list，create，update，patch，watch，proxy，redirect，delete和deletecollection用于资源请求。要确定资源API端点的请求动词，请参阅确定请求动词。
  • HTTP request verb - HTTP 动词get，post，put和delete用于非资源请求。
  • Resource - 正在访问的资源的 ID 或名称（仅限资源请求） - 对于使用，update，patch和delete动词的资源请求，您必须提供资源名称。
  • Subresource - 正在访问的子资源（仅限资源请求）。
  • Namespace - 正在访问的对象的名称空间（仅适用于命名空间资源请求）。
  • API group - 正在访问的 API 组（仅限资源请求）。空字符串表示。

要确定资源API端点的请求谓词，请检查所使用的 HTTP 动词以及请求是否对单个资源或资源集合起作用：

Kubernetes有时使用专门的动词检查授权以获得额外的权限。例如：

  • Pod安全策略 检查policy API组中podsecuritypolicies资源的use动词的授权。
  • 检查rbac.authorization.k8s.io API 组中roles和clusterroles资源的bind动词的授权。
  • 认证 layer检查核心API组中users，groups和serviceaccounts的impersonate动词的授权，以及authentication.k8s.io API组中的userextras。

授权模块

  • Node - 一个专用授权程序，根据计划运行的 pod 为 kubelet 授予权限。了解有关使用节点授权模式的更多信息，请参阅节点授权.
  • ABAC - 基于属性的访问控制（ABAC) 定义了一种访问控制范例，通过使用将属性组合在一起的策略，将访问权限授予用户。策略可以使用任何类型的属性（用户属性，资源属性，对象，环境属性等）。要了解有关使用 ABAC 模式的更多信息，请参阅。
  • Webhook - WebHook 是一个 HTTP 回调: 发生某些事情时调用的 HTTP POST;通过 HTTP POST 进行简单的事件通知。实现 WebHooks 的 Web 应用程序会在发生某些事情时将消息发布到URL。要了解有关使用 Webhook 模式的更多信息，请参阅Webhook 模式。

检查API访问

kubectl提供auth can-i子命令，用于快速查询 API 授权层。该命令使用SelfSubjectAccessReview API来确定当前用户是否可以执行给定操作，并且无论使用何种授权模式都可以工作。

管理员可以将此与用户模拟结合使用，以确定其他用户可以执行的操作。

SelfSubjectAccessReview是authorization.k8s.io API组的一部分，它将 API 服务器授权公开给外部服务。该组中的其他资源包括：

  • SubjectAccessReview - 访问任何用户的 Review ，而不仅仅是当前用户。用于将授权决策委派给API服务器。例如，kubelet 和扩展 API 服务器使用它来确定用户对自己的API的访问权限。
  • LocalSubjectAccessReview - 与SubjectAccessReview类似，但仅限于特定的命名空间。
  • SelfSubjectRulesReview - 返回用户可在命名空间内执行的操作集的审阅。用户可以快速汇总自己的访问权限，或者用于隐藏/显示操作的UI。

您必须在策略中包含一个标志，以指明您的策略包含哪个授权模块：

可以使用以下标志：

  • —authorization-mode=ABAC 基于属性的访问控制（ABAC）模式允许您使用本地文件配置策略。
  • —authorization-mode=RBAC 基于角色的访问控制（RBAC）模式允许您使用 Kubernetes API 创建和存储策略。
  • —authorization-mode=Webhook WebHook 是一种 HTTP 回调模式，允许您使用远程REST端点管理授权。
  • —authorization-mode=Node 节点授权是一种特殊用途的授权模式，专门授权由 kubelet 发出的API请求。
  • —authorization-mode=AlwaysDeny 该标志阻止所有请求。仅将此标志用于测试。
  • —authorization-mode=AlwaysAllow 此标志允许所有请求。仅在您不需要 API 请求的授权时才使用此标志。

您可以选择多个授权模块。按顺序检查模块，以便较早的模块具有更高的优先级来允许或拒绝请求。

通过pod创建权限升级

能够在命名空间中创建 pod 的用户可能会升级其在该命名空间内的权限。他们可以创建在该命名空间内访问其权限的 pod 。他们可以创建用户无法自己读取 secret 的 pod ，或者在具有不同/更高权限的服务帐户下运行的 pod 。

反馈

感谢反馈。如果您有一个关于如何使用 Kubernetes 的特定的、需要答案的问题，可以访问Stack Overflow.在 GitHub 仓库上登记新的问题或者提出改进建议.