授权概述

了解有关 Kubernetes 授权的更多信息，包括使用支持的授权模块创建策略的详细信息。

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

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

确定是允许还是拒绝请求

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

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

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

审查您的请求属性

Kubernetes仅审查以下API请求属性：

  • user - 身份验证期间提供的user字符串。
  • group - 经过身份验证的用户所属的组名列表。
  • extra - 由身份验证层提供的任意字符串键到字符串值的映射。
  • API - 指示请求是否针对 API 资源。
  • 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 或名称（仅限资源请求） - 对于使用get，update，patch和delete动词的资源请求，您必须提供资源名称。
  • Subresource - 正在访问的子资源（仅限资源请求）。
  • Namespace - 正在访问的对象的名称空间（仅适用于命名空间资源请求）。
  • API group - 正在访问的 API 组（仅限资源请求）。空字符串表示核心API组。

确定请求动词

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

HTTP 动词request 动词
POSTcreate
GET, HEADget (单个资源), list (资源集合)
PUTupdate
PATCHpatch
DELETEdelete (单个资源), deletecollection (资源集合)

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

  • Pod安全策略 检查policy API组中podsecuritypolicies资源的use动词的授权。
  • RBAC 检查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 模式的更多信息，请参阅ABAC 模式。
  • RBAC - 基于角色的访问控制（RBAC）是一种基于企业内个人用户的角色来管理对计算机或网络资源的访问的方法。在此上下文中，权限是单个用户执行特定任务的能力，例如查看，创建或修改文件。要了解有关使用 RBAC 模式的更多信息，请参阅RBAC 模式。
    • 当指定的RBAC（基于角色的访问控制）使用rbac.authorization.k8s.io API 组来驱动授权决策时，允许管理员通过 Kubernetes API 动态配置权限策略。
    • 要启用RBAC，请使用—authorization-mode = RBAC启动 apiserver 。
  • Webhook - WebHook 是一个 HTTP 回调: 发生某些事情时调用的 HTTP POST;通过 HTTP POST 进行简单的事件通知。实现 WebHooks 的 Web 应用程序会在发生某些事情时将消息发布到URL。要了解有关使用 Webhook 模式的更多信息，请参阅Webhook 模式。

检查API访问

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

  1. $ kubectl auth can-i create deployments --namespace dev
  2. yes
  3. $ kubectl auth can-i create deployments --namespace prod
  4. no

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

  1. $ kubectl auth can-i list secrets --namespace dev --as dave
  2. no

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

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

可以通过创建普通 Kubernetes 资源来查询这些 API ，其中返回对象的响应“status”字段是查询的结果。

  1. $ kubectl create -f - -o yaml << EOF
  2. apiVersion: authorization.k8s.io/v1
  3. kind: SelfSubjectAccessReview
  4. spec:
  5.   resourceAttributes:
  6.     group: apps
  7.     name: deployments
  8.     verb: create
  9.     namespace: dev
  10. EOF
  12. apiVersion: authorization.k8s.io/v1
  13. kind: SelfSubjectAccessReview
  14. metadata:
  15.   creationTimestamp: null
  16. spec:
  17.   resourceAttributes:
  18.     group: apps
  19.     name: deployments
  20.     namespace: dev
  21.     verb: create
  22. status:
  23.   allowed: true
  24.   denied: false

为您的授权模块使用标志

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

可以使用以下标志：

  • —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 。

警告:

注意： 系统管理员在授予对 pod 创建的访问权限时要小心。授予在命名空间中创建 pod（或创建pod的控制器）的权限的用户可以：读取命名空间中的所有秘密;读取命名空间中的所有配置映射;并模拟命名空间中的任何服务帐户并执行帐户可以执行的任何操作。无论采用何种授权方式，这都适用。

接下来

反馈

此页是否对您有帮助？

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