Black lives matter.
We stand in solidarity with the Black community.
Racism is unacceptable.
It conflicts with the core values of the Kubernetes project and our community does not tolerate it.
We stand in solidarity with the Black community.
Racism is unacceptable.
It conflicts with the core values of the Kubernetes project and our community does not tolerate it.
了解有关 Kubernetes 授权的更多信息,包括使用支持的授权模块创建策略的详细信息。
在 Kubernetes 中,您必须在授权(授予访问权限)之前进行身份验证(登录),有关身份验证的信息, 请参阅 访问控制概述.
Kubernetes 期望 REST API 请求中常见的属性。 这意味着 Kubernetes 授权适用于现有的组织范围或云提供商范围的访问控制系统, 除了 Kubernetes API 之外,它还可以处理其他 API。
Kubernetes 使用 API 服务器授权 API 请求。它根据所有策略评估所有请求属性来决定允许或拒绝请求。 一个 API 请求的所有部分必须被某些策略允许才能继续。这意味着默认情况下拒绝权限。
(尽管 Kubernetes 使用 API 服务器,但是依赖于特定种类对象的特定字段的访问控制和策略由准入控制器处理。)
配置多个授权模块时,将按顺序检查每个模块。 如果任何授权模块批准或拒绝请求,则立即返回该决定,并且不会与其他授权模块协商。 如果所有模块对请求没有意见,则拒绝该请求。一个拒绝响应返回 HTTP 状态代码 403 。
Kubernetes 仅审查以下 API 请求属性:
user
字符串。/api
或 /healthz
。get
,list
,create
,update
,patch
,watch
,proxy
,redirect
,delete
和 deletecollection
用于资源请求。要确定资源 API 端点的请求动词,请参阅确定请求动词。get
,post
,put
和 delete
用于非资源请求。get
,update
,patch
和 delete
动词的资源请求,您必须提供资源名称。要确定资源 API 端点的请求谓词,请检查所使用的 HTTP 动词以及请求是否对单个资源或资源集合起作用:
HTTP 动词 | request 动词 |
---|---|
POST | create |
GET, HEAD | get (单个资源),list (资源集合) |
PUT | update |
PATCH | patch |
DELETE | delete (单个资源),deletecollection (资源集合) |
Kubernetes 有时使用专门的动词检查授权以获得额外的权限。例如:
policy
API 组中 podsecuritypolicies
资源的 use
动词的授权。rbac.authorization.k8s.io
API 组中 roles
和 clusterroles
资源的 bind
动词的授权。users
,groups
和 serviceaccounts
的 impersonate
动词的授权,以及 authentication.k8s.io
API 组中的 userextras
。rbac.authorization.k8s.io
API 组来驱动授权决策时,允许管理员通过 Kubernetes API 动态配置权限策略。--authorization-mode = RBAC
启动 apiserver 。kubectl
提供 auth can-i
子命令,用于快速查询 API 授权层。
该命令使用 SelfSubjectAccessReview
API 来确定当前用户是否可以执行给定操作,并且无论使用何种授权模式都可以工作。
$ kubectl auth can-i create deployments --namespace dev
yes
$ kubectl auth can-i create deployments --namespace prod
no
管理员可以将此与用户模拟结合使用,以确定其他用户可以执行的操作。
$ kubectl auth can-i list secrets --namespace dev --as dave
no
SelfSubjectAccessReview
是 authorization.k8s.io
API 组的一部分,它将 API 服务器授权公开给外部服务。
该组中的其他资源包括:
SubjectAccessReview
- 访问任何用户的 Review ,而不仅仅是当前用户。用于将授权决策委派给 API 服务器。例如,kubelet 和扩展 API 服务器使用它来确定用户对自己的 API 的访问权限。LocalSubjectAccessReview
- 与 SubjectAccessReview
类似,但仅限于特定的命名空间。SelfSubjectRulesReview
- 返回用户可在命名空间内执行的操作集的审阅。用户可以快速汇总自己的访问权限,或者用于 UI 中的隐藏/显示动作。可以通过创建普通 Kubernetes 资源来查询这些 API ,其中返回对象的响应 “status” 字段是查询的结果。
$ kubectl create -f - -o yaml << EOF
apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview
spec:
resourceAttributes:
group: apps
name: deployments
verb: create
namespace: dev
EOF
apiVersion: authorization.k8s.io/v1
kind: SelfSubjectAccessReview
metadata:
creationTimestamp: null
spec:
resourceAttributes:
group: apps
name: deployments
namespace: dev
verb: create
status:
allowed: true
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 。 他们可以创建用户无法自己读取 secret 的 Pod ,或者在具有不同/更高权限的服务帐户下运行的 Pod 。
警告:注意: 系统管理员在授予对 Pod 创建的访问权限时要小心。 授予在命名空间中创建 Pod(或创建 Pod 的控制器)的权限的用户可以: 读取命名空间中的所有 secret;读取命名空间中的所有 ConfigMap; 并模拟命名空间中的任何服务帐户并执行帐户可以执行的任何操作。 无论采用何种授权方式,这都适用。