這些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集群上部署應用程序的趨勢通常要比未采用云安全性的組織高。

網絡安全專業人員可能完全不熟悉容器化應用程序可能需要一段時間。

從理論上講，容器化的應用程序更安全，因為替換具有漏洞的容器要比修補整體應用程序容易得多。

當然，問題在于，鑒于容器安全專業知識的復雜性和相對缺乏，存在很多犯錯的機會。