Kubernetes Kubelet 认证与授权机制深度解析

Kubernetes Kubelet 认证与授权机制深度解析

website Kubernetes website and documentation repo: website 项目地址: 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 集群中最常用的认证方式之一:

  1. 配置 Kubelet:

    --client-ca-file=/path/to/ca.crt
    

    此参数指定用于验证客户端证书的 CA 证书包

  2. 配置 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)进行认证:

  1. 确保 API Server 已启用 authentication.k8s.io/v1beta1 API 组
  2. 启动 Kubelet 时添加以下参数:
    --authentication-token-webhook=true
    --kubeconfig=/path/to/kubeconfig
    
    配置后,Kubelet 会通过调用 API Server 的 TokenReview API 来验证 Bearer Token

Kubelet 授权机制

默认授权模式

默认授权模式为 AlwaysAllow,即允许所有已认证(包括匿名)请求。这种宽松的授权策略不适合生产环境。

Webhook 授权模式

要实现细粒度的访问控制,可以委托 API Server 进行授权决策:

  1. 确保 API Server 已启用 authorization.k8s.io/v1beta1 API 组
  2. 启动 Kubelet 时添加以下参数:
    --authorization-mode=Webhook
    --kubeconfig=/path/to/kubeconfig
    
    配置后,Kubelet 会通过调用 API Server 的 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,使其包含上述所有子资源的访问权限。

最佳实践建议

  1. 生产环境应始终禁用匿名访问(--anonymous-auth=false
  2. 推荐使用 Webhook 授权模式替代默认的 AlwaysAllow
  3. 为 Kubelet API 访问配置专门的 RBAC 角色,遵循最小权限原则
  4. 定期审计 Kubelet 的访问日志和授权决策
  5. 考虑启用细粒度授权特性以获得更好的安全控制

通过合理配置 Kubelet 的认证和授权机制,可以显著提升 Kubernetes 集群的安全性,防止未授权访问和潜在的攻击行为。

website Kubernetes website and documentation repo: website 项目地址: https://gitcode.com/gh_mirrors/webs/website

创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

施谨贞Des

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值