该报告建议已部署Kubernetes的这组织在使用弹性Kubernetes AWS服务(的)时应解决以下问题:
一些的负载平衡器的孤立安全组:充当的入口控制器的负载平衡器被分配了默认安全组.90天后,AWS会自动清除这些权限。
但是,威胁堆栈建议组织在不使用负载平衡器后应主动删除它们。
多租户的网络不匹配:的集群将亚马逊VPC CNI插件用于Kubernetes,从而使其能够代表AWS虚拟私有云(VPC)上的豆荚。
报告发现,这还不足以支持Kubernetes网络策略,除非组织还部署了印花网络虚拟化软件实例。
由于容器网络接口(CNI)插件如何映射到AWS弹性网络接口(ENI),因此公司每个节点只能支持一个安全组。
威胁堆栈警告说,当的在同一节点上调度不相关的吊舱时,这可能会产生问题。
入侵者使用aws-iam-authenticator进行的侦查:可疑用户已将用于通过身份访问管理(IAM)凭据访问的群集的合法aws-iam-authenticator工具下载到的容器中的/tmp目录中。
然后,用户使用AWS CLI访问的信息以进一步探查集群。
威胁堆栈首席安全官山姆Bisbee说,对于Kubernetes而言,大多数云服务提供商采用的网络安全分担责任方法尤其具有挑战性。
大多数这团队假定他们负责保护云应用程序,而云服务提供商则保护基础架构。
但是,当涉及到诸如Kubernetes之类的容器平台时,网络安全责任仍然没有得到精确定义。
结果,这些不确定性可能会拖累Kubernetes集群在生产环境中的部署速度。
这都不意味着Kubernetes不会部署在云中.Kubernetes服务是云计算中增长最快的服务之一。
但是,由于越来越多的生产应用程序开始部署到这些服务上,因此网络安全团队开始对这些服务进行越来越严格的审查。
Bisbee说,挑战当然是容器化应用程序的行为与传统的整体式应用程序非常不同,传统的整体式应用程序需要网络安全团队了解时间。
Bisbee指出,总的来说,采用最佳DevSecOps实践的组织在云中的Kubernetes集群上部署应用程序的趋势通常要比未采用云安全性的组织高。
网络安全专业人员可能完全不熟悉容器化应用程序可能需要一段时间。
从理论上讲,容器化的应用程序更安全,因为替换具有漏洞的容器要比修补整体应用程序容易得多。
当然,问题在于,鉴于容器安全专业知识的复杂性和相对缺乏,存在很多犯错的机会。
