在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