学习有关 Kubernetes 授权的更多信息,包括有关使用支持的授权模块创建策略的详细信息。
在 Kubernetes 里,您必须经过身份验证 ( 登录 ),才能授权您的请求 ( 授予访问权限 ).。有关认证的信息,请参阅访问控制概述。
Kubernetes 提供通用的 REST API 请求。这意味着 Kubernetes 授权可以与现有的组织或云提供商的访问控制系统一起使用,该系统可以处理除 Kubernetes API 之外的其他 API。
Kubernetes 使用 API 服务器授权 API 请求。它根据所有策略评估所有请求属性,并允许或拒绝请求。某些策略必须允许 API 请求的所有部分继续进行,这意味着默认情况下是拒绝权限。
( 虽然 Kubernetes 使用 API 服务器,访问控制和依赖特定类型对象的特定领域策略由 Admission 控制器处理。)
当配置多个授权模块时,按顺序检查每个模块,如果有任何模块授权请求,则可以继续执行该请求。如果所有模块拒绝请求,则拒绝该请求 (HTTP 状态代码 403)。
Kubernetes 仅查看以下 API 请求属性 :
user
字符串/api
或 /healthz
的其他非资源端点的路径 ( 请参阅kubectl).get
,list
,create
,update
,patch
,watch
,proxy
,redirect
,delete
和 deletecollection
用于资源请求。要确定资源 API 端点的请求动词,请参阅确定下面的请求动词.get
,post
,put
和 delete
用于非资源请求get
, update
, patch
, 和 delete
动词的资源请求,您必须提供资源名称。要确定资源 API 端点的请求动词,请查看所使用的 HTTP 动词以及请求是否对单个资源或资源集合进行操作 :
HTTP 动词 | 请求动词 |
---|---|
POST | 创建 |
GET,HEAD | 获取 ( 个人资源 ),列表 ( 集合 ) |
PUT | 更新 |
PATCH | 补丁 |
DELETE | 删除 ( 个人资源 ),删除 ( 收藏 ) |
Kubernetes 有时会使用专门的动词检查授权以获得额外的权限。例如 :
extensions
API 组中的 podsecuritypolicies
资源上检查 use
动词的授权。rbac.authorization.k8s.io
API 组中的 roles
和 clusterroles
资源上检查 bind
动词的授权。users
,groups
和 serviceaccounts
上的 impersonate
动词的授权以及 authentication.k8s.io
API 组中的 userextras
进行层次检查。--authorization-mode=RBAC
启动 apiserver.可以相当容易地开发其他实现 ,APIserver 调用 Authorizer 接口:
type Authorizer interface {
Authorize(a Attributes) error
}
以确定是否允许每个 API 操作 .
授权插件是实现此接口的模块 . 授权插件代码位于 pkg/auth/authorizer/$MODULENAME
中。
授权模块可以完全实现,也可以拨出远程授权服务。 授权模块可以实现自己的缓存,以减少具有相同或相似参数的重复授权调用的成本。 开发人员应该考虑缓存和撤销权限之间的交互。
Kubernetes 将 subjectaccessreviews.v1.authorization.k8s.io
资源公开为允许外部访问 API 授权者决策的普通资源。 无论您选择使用哪个授权器,您都可以使用 SubjectAccessReview
发出一个 POST
,就像 webhook 授权器的 apis/authorization.k8s.io/v1/subjectaccessreviews
端点一样,并回复一个响应。 例如:
kubectl create --v=8 -f - << __EOF__
{
"apiVersion": "authorization.k8s.io/v1",
"kind": "SubjectAccessReview",
"spec": {
"resourceAttributes": {
"namespace": "kittensandponies",
"verb": "get",
"group": "unicorn.example.org",
"resource": "pods"
},
"user": "jane",
"group": [
"group1",
"group2"
],
"extra": {
"scopes": [
"openid",
"profile"
]
}
}
}
__EOF__
--- snip lots of output ---
I0913 08:12:31.362873 27425 request.go:908] Response Body: {"kind":"SubjectAccessReview","apiVersion":"authorization.k8s.io/v1","metadata":{"creationTimestamp":null},"spec":{"resourceAttributes":{"namespace":"kittensandponies","verb":"GET","group":"unicorn.example.org","resource":"pods"},"user":"jane","group":["group1","group2"],"extra":{"scopes":["openid","profile"]}},"status":{"allowed":true}}
subjectaccessreview "" created
这对于调试访问问题非常有用,因为您可以使用此资源来确定授权者授予哪些访问权限。
您的策略中必须包含一个标志,以指出您的策略包含哪个授权模块 :
可以使用以下标志 :
- --authorization-mode=ABAC
基于属性的访问控制 (ABAC) 模式允许您使用本地文件配置策略。
- --authorization-mode=RBAC
基于角色的访问控制 (RBAC) 模式允许您使用 Kubernetes API 创建和存储策略 .
- --authorization-mode=Webhook
WebHook 是一种 HTTP 回调模式,允许您使用远程 REST 管理授权。
- --authorization-mode=AlwaysDeny
此标志阻止所有请求 . 仅使用此标志进行测试。
- --authorization-mode=AlwaysAllow
此标志允许所有请求 . 只有在您不需要 API 请求授权的情况下才能使用此标志。
您可以选择多个授权模块,如果其中一种模式为 AlwaysAllow
,则覆盖其他模式,并允许所有 API 请求。
对于版本 1.2,配置了 kube-up.sh 创建的集群,以便任何请求都不需要授权。
从版本 1.3 开始,配置由 kube-up.sh 创建的集群,使得 ABAC 授权模块处于启用状态。但是,其输入文件最初设置为允许所有用户执行所有操作,集群管理员需要编辑该文件,或者配置不同的授权器来限制用户可以执行的操作。
此页是否对您有帮助?
Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on Stack Overflow. Open an issue in the GitHub repo if you want to report a problem or suggest an improvement.