在Kubernetes中必须经过认证阶段，才到授权请求（授权访问权限）。有关认证的信息，请参阅访问控制概述。

确定请求是否通过

Kubernetes使用API​​server授权API请求。它根据策略来评估所有请求属性，是否给于通过。

（Kubernetes使用API​​server，访问控制和依赖特定资源对象的策略由（Admission Controllers）准入控制器处理。）

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

查看请求属性

Kubernetes只对以下的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)

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

授权模块

  • Node - v1.7+支持Node授权，配合NodeRestriction准入控制来限制kubelet仅可访问node、endpoint、pod、service以及secret、configmap、PV和PVC等相关的资源，了解更多Node授权模式的信息，请参阅Node授权
  • ABAC - 基于属性的访问控制（ABAC）定义了访问控制范例，通过将属性组合在一起的策略来授予用户访问权限。ABAC策略可以使用任何类型的属性（用户属性，资源属性，对象，环境属性等）。了解更多ABAC模式的信息，请参阅ABAC模式
  • RBAC - 在Kubernetes1.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 - 可以创建Kubernetes的（Custom Modules）自定义模块。要了解更多信息，请参阅下面的“自定义模块”。

自定义模块

APIserver调用Authorizer接口：

  1. type Authorizer interface {
  2.   Authorize(a Attributes) error
  3. }

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

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

为授权模块使用flags

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

使用以下flags：

    • —authorization-mode=ABAC 基于属性的访问控制（ABAC）模式允许使用本地文件配置策略。
    • —authorization-mode=RBAC 基于角色的访问控制（RBAC）模式允许使用Kubernetes 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授权模块处于启用状态，其输入文件最初设置为允许所有用户执行所有操作。集群管理员需要编辑该文件，或者配置不同的授权器来限制用户可以执行的操作。

下一步

原文: http://docs.kubernetes.org.cn/80.html