Kubelet Authentication & Authorization
Kubelet身份验证
默认情况下,对kubelet的HTTPS端点的请求如果未被其他配置的身份验证方法拒绝,则被视为匿名请求,并被赋予用户名为system:anonymous
和组为system:unauthenticated
。
有3种身份验证方法:
匿名(默认):使用设置参数**
--anonymous-auth=true
或配置:**
Webhook: 这将启用 kubectl API 令牌作为授权(任何有效令牌都将有效)。允许它使用:
确保在 API 服务器中启用了
authentication.k8s.io/v1beta1
API 组使用以下设置启动 kubelet,带有
--authentication-token-webhook
和--kubeconfig
标志或使用以下设置:
kubelet调用配置的API服务器上的**TokenReview
API来确定用户信息**从bearer tokens
X509客户端证书: 允许通过X509客户端证书进行身份验证
有关更多详细信息,请参阅apiserver身份验证文档
使用
--client-ca-file
标志启动kubelet,提供一个CA捆绑包来验证客户端证书。或者使用以下配置:
Kubelet 授权
任何成功认证的请求(包括匿名请求)随后将被授权。默认的授权模式是**AlwaysAllow
,它允许所有请求**。
然而,另一个可能的值是**webhook
(这是你大部分时间会发现的**)。这种模式将检查已认证用户的权限以允许或拒绝一个操作。
请注意,即使启用了匿名认证,匿名访问可能没有任何权限执行任何操作。
通过 webhook 进行授权可以使用**参数 --authorization-mode=Webhook
**进行配置,或者通过配置文件:
kubelet调用配置的API服务器上的**SubjectAccessReview
** API来确定每个请求是否被授权。
kubelet使用与apiserver相同的请求属性方法来授权API请求:
操作
HTTP动词 | 请求动词 |
---|---|
POST | create |
GET, HEAD | get(用于单个资源),list(用于集合,包括完整对象内容),watch(用于监视单个资源或资源集合) |
PUT | update |
PATCH | patch |
DELETE | delete(用于单个资源),deletecollection(用于集合) |
与Kubelet API通信的资源始终为nodes,子资源根据传入请求的路径确定:
Kubelet API | 资源 | 子资源 |
---|---|---|
/stats/* | nodes | stats |
/metrics/* | nodes | metrics |
/logs/* | nodes | log |
/spec/* | nodes | spec |
所有其他 | nodes | proxy |
例如,以下请求尝试未经授权访问kubelet的pods信息:
我们收到了一个Forbidden,所以请求通过了身份验证检查。如果没有通过,我们将只会收到一个
未经授权
的消息。我们可以看到用户名(在这种情况下是从令牌中获取的)
检查资源是如何节点和子资源是代理(这与先前的信息相符)
参考
Last updated