在官方的Kubernetes C#客户端中发现了一个中等严重程度的漏洞，这可能允许攻击者拦截并操纵敏感通信。
这个漏洞在CVSS评分系统中得分为6.8，源于证书验证逻辑不当。
这一漏洞使使用该客户端的应用程序容易遭受中间人（MiTM）攻击</b0，可能导致传输到Kubernetes API服务器的凭据、令牌和其他机密数据被泄露。
证书验证存在缺陷
该漏洞的核心在于Kubernetes C#客户端处理TLS/HTTPS连接的方式，这些连接使用kubeconfig文件中指定的自定义证书颁发机构（CA）。
客户的验证流程能正确检查所提供的证书是否格式正确，但未能针对指定的证书颁发机构（CA）正确验证信任链。
这意味着它将接受由任何有效机构签署的证书，而不是仅信任用户定义的自定义证书颁发机构。
与客户端处于同一网络的攻击者可以通过出示伪造但签名有效的证书来利用这一漏洞。
这使得他们能够伪装成 Kubernetes API服务器，建立中间人位置，从而可以解密、读取和篡改客户端与服务器之间的所有流量。
此漏洞影响Kubernetes C#客户端的所有版本，包括17.0.13及之前的版本。如果环境使用C#客户端通过不受信任的网络连接到Kubernetes API服务器，同时在kubeconfig文件中通过certificate-authority字段指定自定义CA，则这些环境被视为存在漏洞。
最主要且最有效的缓解措施是升级到已修复的版本，即17.0.14或更新版本，该版本能正确执行信任链验证。
该公告称，对于无法立即打补丁的组织，一种解决方法是将自定义CA证书从kubeconfig文件移至系统的主信任存储中。
然而，此操作本身也存在风险，因为它会导致机器上的所有进程开始信任该证书颁发机构签署的证书。
缓解措施
要确定其应用程序是否受到影响，管理员应首先找出其环境中Kubernetes C#客户端的所有实例。
必须对kubeconfig文件进行全面审查，以检查集群配置中是否使用了certificate-authority字段。
系统管理员还应检查客户端应用程序日志，查看是否有任何意外的证书警告或连接错误，这些可能表明存在未遂或成功的漏洞利用。
鉴于存在数据拦截和API命令操纵的可能性，强烈建议安全团队优先部署经过修复的客户端版本。
主动审计和及时修补对于保护Kubernetes环境免受这种 impersonation 威胁至关重要。
1. 本版块文章内容及资料部分来源于网络，不代表本站观点，不对其真实性负责，也不构成任何建议。
2. 部分内容由网友自主投稿、编辑整理上传，本站仅提供交流平台，不为该类内容的版权负责。
3. 本版块提供的信息仅作参考，不保证信息的准确性、有效性、及时性和完整性。
4. 若您发现本版块有侵犯您知识产权的内容，请及时与我们联系，我们会尽快修改或删除。
5. 使用者违规、不可抗力（如黑客攻击）或第三方擅自转载引发的争议，联盟不承担责任。
6. 联盟可修订本声明，官网发布即生效，继续使用视为接受新条款。
