NCC-E003660-F9W:客户端证书颁发机构可能用于客户端CA和请求头CA
这个问题在Kubernetes 1.24 Security Audit Report中被报告。
影响
API服务器的配置错误可能导致任何经过身份验证的用户都可以升级到集群管理员权限的情况。
描述
Kubernetes API服务器允许指定一个证书颁发机构(CA)(使用-- client-ca-file flag),该CA将用于在熟悉的X.509客户端证书认证方案下验证客户端证书。另一个CA(使用-- requestheader-client-ca-file)可以指定，该CA将用于验证使用请求头方案(在文档中描述为“认证代理”)进行身份验证的请求。如果这两个CA是相同的，并且没有使用--requestheader-allowed-names标志来指定允许请求头认证的特定证书通用名称，那么任何持有来自共享CA的客户端证书的持有者都可以轻易地使用他们的证书通过请求头方案对API服务器进行身份验证，就像任何用户一样。虽然这不是为了使这些CA相同而设计的，而且常见的Kubernetes部署方法也没有以这种方式配置部署，但有可能管理员们并不知道这个陷阱。Kubernetes文档确实包含了一些关于不共享CA的建议，但并没有明确说明这种特定情况的安全影响。
例如，请参阅原始发现，位于Kubernetes 1.24 Security Audit Report第18页。
建议
Kubernetes API服务器应该拒绝将--client-ca-file和--requestheader-client-ca-file设置为相同值的任何配置，除非--requestheaderallowed- names已经被设置为特定的值。
更新Kubernetes文档以更明确地说明共享证书颁发机构的具体风险可能是明智的。例如，对于etcd的身份验证使用相同的CA,这将允许任何经过身份验证的用户直接访问etcd(尽管这种情况比共享客户端CA和请求头CA的可能性要小)。
组件
kube-apiserver
我们需要了解其他信息吗？
查看 umbrella issue #118980 以了解这些问题发现的当前状态。供应商给了这个问题一个ID:NCC-E003660-F9W,它在kube-apiserver部分找到了5个报告。供应商认为这个问题的风险中等、影响严重、利用难度低。
要查看原始发现，请从Kubernetes 1.24 Security Audit Report的第18页开始。
测试环境
Kubernetes 1.24.3
7条答案
按热度按时间sdnqo3pr1#
请查看 https://kubernetes.io/docs/reference/command-line-tools-reference/kube-apiserver/,kube-apiserver中的标志。
iklwldmw2#
在2024-01-03的签名认证会议中讨论了
如果客户端证书颁发机构(client-ca)和请求头中的客户端证书颁发机构文件(requestheader-client-ca-file)重叠，且没有请求头允许的名称(requestheader-allowed-names),这是一个非常有问题的配置。为了防止这种特定的配置，要求在CA捆绑包重叠时需要–requestheader-allowed-names似乎是合理的。
目前没有人被分配到这个问题，但似乎相对简单地在服务器启动时添加一个验证检查来完成这个任务。
/triage已接受
/priority backlog
vzgqcmou3#
@liggitt 我想为这个问题做出贡献。
hsvhsicv4#
/assign
zaqlnxep5#
/sig security
y1aodyip6#
你好，我正在为我的大学进行Kubernetes加固的研究。偶然间，你找到了设置标志的部分代码吗？我想实现一个代码级别的检查来防止这种漏洞。谢谢
dgiusagp7#