在Kubernetes中必须经过认证阶段，才到授权请求（授权访问权限）。有关认证的信息，请参阅访问控制概述。
确定请求是否通过
Kubernetes使用APIserver授权API请求。它根据策略来评估所有请求属性，是否给于通过。
（Kubernetes使用APIserver，访问控制和依赖特定资源对象的策略由（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接口：
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）模式允许使用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授权模块处于启用状态，其输入文件最初设置为允许所有用户执行所有操作。集群管理员需要编辑该文件，或者配置不同的授权器来限制用户可以执行的操作。
下一步
- 了解更多关于身份验证，参考Kubernetes API访问控制。
- 了解有关准入控制信息，参考使用准入控制器。
