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

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

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

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