了解有关 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 。
Caution:注意: 系统管理员在授予对 pod 创建的访问权限时要小心。 授予在命名空间中创建 pod(或创建pod的控制器)的权限的用户可以: 读取命名空间中的所有秘密;读取命名空间中的所有配置映射; 并模拟命名空间中的任何服务帐户并执行帐户可以执行的任何操作。 无论采用何种授权方式,这都适用。
此页是否对您有帮助?
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.