这些Kubernetes常见安全问题，你遇到过几个？

该报告建议已部署Kubernetes的IT组织在使用AWS Elastic Kubernetes Service（EKS）时应解决以下问题：

一些EKS负载平衡器的孤立安全组：充当EKS入口控制器的负载平衡器被分配了默认安全组。90天后，AWS会自动清除这些权限。

但是，Threat Stack建议组织在不使用负载平衡器后应主动删除它们。

多租户EKS网络不匹配：EKS集群将Amazon VPC CNI插件用于Kubernetes，从而使其能够代表AWS虚拟私有云（VPC）上的Pod。

报告发现，这还不足以支持Kubernetes网络策略，除非组织还部署了Calico网络虚拟化软件实例。

由于容器网络接口（CNI）插件如何映射到AWS弹性网络接口（ENI），因此CNI每个节点只能支持一个安全组。

威胁堆栈警告说，当EKS在同一节点上调度不相关的吊舱时，这可能会产生问题。

入侵者使用aws-iam-authenticator进行EKS侦查：可疑用户已将用于通过身份访问管理（IAM）凭据访问EKS群集的合法aws-iam-authenticator工具下载到EKS容器中的/ tmp目录中。

然后，用户使用AWS CLI访问EKS信息以进一步探查集群。

Threat Stack首席安全官Sam Bisbee说，对于Kubernetes而言，大多数云服务提供商采用的网络安全分担责任方法尤其具有挑战性。

大多数IT团队假定他们负责保护云应用程序，而云服务提供商则保护基础架构。

但是，当涉及到诸如Kubernetes之类的容器平台时，网络安全责任仍然没有得到精确定义。

结果，这些不确定性可能会拖累Kubernetes集群在生产环境中的部署速度。

这都不意味着Kubernetes不会部署在云中。Kubernetes服务是云计算中增长最快的服务之一。

但是，由于越来越多的生产应用程序开始部署到这些服务上，因此网络安全团队开始对这些服务进行越来越严格的审查。

Bisbee说，挑战当然是容器化应用程序的行为与传统的整体式应用程序非常不同，传统的整体式应用程序需要网络安全团队了解时间。

Bisbee指出，总的来说，采用最佳DevSecOps实践的组织在云中的Kubernetes集群上部署应用程序的趋势通常要比未采用云安全性的组织高。

网络安全专业人员可能完全不熟悉容器化应用程序可能需要一段时间。

从理论上讲，容器化的应用程序更安全，因为替换具有漏洞的容器要比修补整体应用程序容易得多。

当然，问题在于，鉴于容器安全专业知识的复杂性和相对缺乏，存在很多犯错的机会。