Kubernetes Kubelet 认证与授权机制深度解析
website Kubernetes website and documentation repo: 项目地址: https://gitcode.com/gh_mirrors/webs/website
概述
Kubelet 是 Kubernetes 集群中运行在每个节点上的关键组件,它通过 HTTPS 端点暴露了多种 API。这些 API 既包含敏感数据访问接口,也提供了对节点和容器进行各种操作的能力。本文将深入剖析 Kubelet 的认证与授权机制,帮助管理员和安全工程师正确配置 Kubelet 的安全访问控制。
Kubelet 认证机制
默认认证行为
默认情况下,Kubelet 的 HTTPS 端点会接受所有未被其他认证方法拒绝的请求,并将其视为匿名请求。这些匿名请求会被赋予以下身份标识:
- 用户名:
system:anonymous
- 用户组:
system:unauthenticated
禁用匿名访问
出于安全考虑,生产环境通常需要禁用匿名访问:
# 启动 Kubelet 时添加以下参数
--anonymous-auth=false
启用此选项后,未经认证的请求将收到 401 Unauthorized
响应。
X509 客户端证书认证
这是 Kubernetes 集群中最常用的认证方式之一:
-
配置 Kubelet:
--client-ca-file=/path/to/ca.crt
此参数指定用于验证客户端证书的 CA 证书包
-
配置 API Server:
--kubelet-client-certificate=/path/to/client.crt --kubelet-client-key=/path/to/client.key
这些参数指定 API Server 与 Kubelet 通信时使用的客户端证书
Bearer Token 认证
支持使用 API Bearer Token(包括服务账号 Token)进行认证:
- 确保 API Server 已启用
authentication.k8s.io/v1beta1
API 组 - 启动 Kubelet 时添加以下参数:
配置后,Kubelet 会通过调用 API Server 的--authentication-token-webhook=true --kubeconfig=/path/to/kubeconfig
TokenReview
API 来验证 Bearer Token
Kubelet 授权机制
默认授权模式
默认授权模式为 AlwaysAllow
,即允许所有已认证(包括匿名)请求。这种宽松的授权策略不适合生产环境。
Webhook 授权模式
要实现细粒度的访问控制,可以委托 API Server 进行授权决策:
- 确保 API Server 已启用
authorization.k8s.io/v1beta1
API 组 - 启动 Kubelet 时添加以下参数:
配置后,Kubelet 会通过调用 API Server 的--authorization-mode=Webhook --kubeconfig=/path/to/kubeconfig
SubjectAccessReview
API 进行授权检查
请求属性映射
Kubelet 使用与 API Server 相同的请求属性模型进行授权决策:
HTTP 动词映射
| HTTP 动词 | 请求动词 | |-----------|----------| | POST | create | | GET, HEAD | get | | PUT | update | | PATCH | patch | | DELETE | delete |
API 路径映射
| Kubelet API 路径 | 资源类型 | 子资源 | |------------------|----------|---------| | /stats/* | nodes | stats | | /metrics/* | nodes | metrics | | /logs/* | nodes | log | | /spec/* | nodes | spec | | /checkpoint/* | nodes | checkpoint | | 其他路径 | nodes | proxy |
注意:namespace 和 API group 属性始终为空字符串,资源名称始终是 Kubelet 对应的 Node API 对象名称。
必要的授权权限
使用 Webhook 授权模式时,必须确保 API Server 使用的客户端证书(由 --kubelet-client-certificate
和 --kubelet-client-key
指定)具有以下权限:
- verb=*, resource=nodes, subresource=proxy
- verb=*, resource=nodes, subresource=stats
- verb=*, resource=nodes, subresource=log
- verb=*, resource=nodes, subresource=spec
- verb=*, resource=nodes, subresource=metrics
细粒度授权(KubeletFineGrainedAuthz 特性)
当启用 KubeletFineGrainedAuthz
特性门控时,Kubelet 会对特定端点进行更精细的授权检查:
增强的路径映射
| Kubelet API 路径 | 资源类型 | 子资源 | |------------------|----------|--------------| | /stats/* | nodes | stats | | /metrics/* | nodes | metrics | | /logs/* | nodes | log | | /pods | nodes | pods, proxy | | /runningPods/ | nodes | pods, proxy | | /healthz | nodes | healthz, proxy | | /configz | nodes | configz, proxy | | 其他路径 | nodes | proxy |
必要的授权权限
启用此特性后,需要额外确保以下权限:
- verb=*, resource=nodes, subresource=configz
- verb=*, resource=nodes, subresource=healthz
- verb=*, resource=nodes, subresource=pods
如果使用 RBAC 授权,启用此特性还会自动更新内置的 system:kubelet-api-admin
ClusterRole,使其包含上述所有子资源的访问权限。
最佳实践建议
- 生产环境应始终禁用匿名访问(
--anonymous-auth=false
) - 推荐使用 Webhook 授权模式替代默认的 AlwaysAllow
- 为 Kubelet API 访问配置专门的 RBAC 角色,遵循最小权限原则
- 定期审计 Kubelet 的访问日志和授权决策
- 考虑启用细粒度授权特性以获得更好的安全控制
通过合理配置 Kubelet 的认证和授权机制,可以显著提升 Kubernetes 集群的安全性,防止未授权访问和潜在的攻击行为。
website Kubernetes website and documentation repo: 项目地址: https://gitcode.com/gh_mirrors/webs/website
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考