AWS已弃用此EKS认证方法，但81%的集群仍在使用。
内容提要
Kubernetes虽提升敏捷性，但并非自带安全，其动态复杂性常造成安全假象。企业普遍面临访问控制、容器镜像、集群配置、密钥管理及多租户等挑战，尤其在容器和集群层。Nutanix Kubernetes Platform（NKP）通过集中管理、默认安全策略、CIS加固、Gatekeeper准入控制及Istio加密，实现全栈防护，以应对AI时代的安全风险。
延伸解读
弃用方法为何仍被广泛使用
文章指出，尽管AWS已弃用aws-auth ConfigMap，但2025年报告显示81%的EKS集群仍在使用。这反映出企业在安全实践上的滞后，可能源于手动配置的惯性、迁移成本或对风险的认知不足。这种差距导致安全漏洞，并可能拖慢部署速度。
容器与集群层是安全薄弱环节
文章强调，在Kubernetes的“四C”框架中，代码和云层安全实践较成熟，但容器和集群层常被忽视。容器镜像供应链复杂，集群配置灵活易出错，且默认允许Pod间自由通信，缺乏网络策略会扩大攻击面。企业需重点加强这两层的防护。
多租户与密钥管理的常见误区
文章指出，Kubernetes的命名空间隔离并非真正的硬多租户，存在“吵闹邻居”风险。同时，Secret默认仅base64编码，并非加密，长期有效的服务账号令牌也增加风险。企业应使用外部密钥库并定期轮换，或采用专用集群实现硬隔离。
合规与镜像供应链的挑战
文章提到，政府、金融等行业需满足FIPS、CIS等合规要求，手动维护难以规模化。镜像供应链风险突出，Sysdig报告显示镜像膨胀和包维护下滑，部分源于AI工作负载。企业需在构建、部署和运行时全链路扫描验证，并采用准入控制器确保来源可信。
Q&A
为什么说Kubernetes会带来安全假象？
因为Kubernetes的声明式基础设施和动态灵活性让人误以为它自带安全，但实际上它比传统VM环境更复杂，需要额外关注和配置多个安全层面，否则容易产生安全漏洞。
AWS已弃用的EKS认证方法是什么？为什么弃用？
AWS已弃用legacy的aws-auth ConfigMap，因为它需要手动编辑且难以审计，取而代之的是API驱动的替代方案。但根据2025年报告，仍有81%的EKS集群在使用旧方法。
Kubernetes安全框架的“四个C”是什么？
四个C分别是Code（代码）、Container（容器）、Cluster（集群）和Cloud（云）。每个层面都有不同的威胁向量，且相互关联，一个层面的弱点可能影响其他层面。
Kubernetes中容器层和集群层的主要安全挑战是什么？
容器层的主要挑战是镜像供应链的复杂性，需要反复验证和监控镜像的漂移或错误配置。集群层的挑战是配置和生命周期管理，以及东西向流量的安全，默认情况下Pod之间可以自由通信，需要网络策略限制。
为什么Kubernetes Secret并不安全？如何正确管理？
Kubernetes Secret只是base64编码，并未加密，任何有集群访问权限的人都能看到。正确做法是使用外部密钥库（如Vault）并定期轮换令牌，NKP通过External Secrets Operator简化了这一过程。
Kubernetes多租户有哪些限制？如何实现硬多租户？
Kubernetes通过命名空间提供软多租户，但存在信任假设，集群级资源可能跨命名空间可见。要实现硬多租户，需要为每个租户提供专用集群，并通过舰队管理自动化确保一致部署和治理。
NKP如何帮助实现合规要求（如CIS、FIPS）？
NKP在部署集群时自动应用CIS Benchmark加固（OS和Kubernetes层面），并提供FIPS-validated和STIG-compatible的OS镜像。此外，NKP可以按需生成每个集群的CIS基准报告，作为合规证据。
NKP中的Gatekeeper有什么作用？
Gatekeeper是NKP内置的准入控制器，基于Open Policy Agent，在部署时强制执行策略，拒绝违反策略的工作负载（如来自不受信任仓库的镜像或root权限容器），并可配置为警告或阻止模式。
NKP如何增强服务间通信安全？
NKP默认配置Istio，通过mTLS加密Pod间流量并验证通信双方身份，提供应用层安全，而网络策略不提供加密。NKP自动部署Istio升级，减少运维复杂性。
NKP Insights提供哪些安全监控功能？
NKP Insights提供CIS基准扫描、运行时容器镜像扫描、异常检测（如Pod频繁崩溃、资源接近上限、配置漂移），并可作为合规报告工具。
