AWS容器服務的安全實踐

AWS是運行容器工作負載的首選平臺。有第三方數(shù)據(jù)顯示，云中80%的容器工作負載，和82%的Kubernetes工作負載構建在AWS云平臺之上。在AWS上運行容器時，我們提供了更多的選擇。首先，您可以選擇編排工具，您可以選擇AWS原生的Amazon ECS或者支持Kubernetes的Amazon EKS。其次，您可以選擇啟動類型，就是您是否要管理服務器。如果您想要進行容器的無服務器計算，您可以選擇AWS Fargate模式，如果您想要控制計算環(huán)境的安裝，配置和管理，您可以選擇Amazon EC2模式。我們提供更多的選擇，也是希望能夠以更靈活的方式幫助您把容器工作負載更快更好更安全的遷移到云端。

安全性和合規(guī)性是AWS和客戶共同的責任，基于此，AWS提出了云安全的責任共擔模式。這種責任區(qū)分為云本身的安全和云內(nèi)部的安全。AWS負責云本身的安全，包括保護所有運行AWS云服務的基礎設施，包括區(qū)域，可用區(qū)，邊緣站點，計算存儲網(wǎng)絡，數(shù)據(jù)庫等等。客戶負責云內(nèi)部的安全。客戶的責任由客戶使用的AWS服務確定，通常來講，客戶會負責操作系統(tǒng)的安全，網(wǎng)絡和防火墻的配置，身份和訪問管理，應用，平臺和客戶數(shù)據(jù)的安全。同時，對于客戶負責的云內(nèi)部安全，AWS提供了大量的工具幫助用戶提升安全性。

我們來看一下把上述安全和合規(guī)的責任共擔模式應用于AWS容器服務Amazon ECS和Amazon EKS的具體實踐。

首先，我們看一下身份和訪問管理。談到身份和訪問管理，我們很容易就會想到AWS IAM服務，它能夠安全的管理對AWS服務和資源的訪問。您可以使用IAM創(chuàng)建和管理AWS用戶和組，并使用各種權限來允許或者拒絕這些用戶和組對AWS資源的訪問。對于ECS來說，由于它是AWS原生的容器解決方案。使用IAM就可以完全管理身份和訪問控制。而對于EKS則需要同時了解和配置IAM和Kubernetes RBAC，就是基于角色的訪問控制。IAM負責將權限分配到AWS服務，而RBAC負責控制資源的權限。

下面我們看一下Kubernetes的管理工具kubectl的執(zhí)行過程是如何在EKS上進行身份認證的。比如說啟動命令kubectl get pods，在這里我們通過kubectl訪問Kubernetes的API，在其中我們會傳遞AWS相關的身份信息，Kubernetes會向IAM驗證身份信息，這里我們會用到IAM認證的一個插件，aws-iam-authenticator，它是AWS官方用于連接驗證身份信息的一個工具，驗證返回之后，Kubernetes API針對RBAC來授權AWS身份的資源訪問權限，最后向kubectl返回執(zhí)行結果是允許還是拒絕。

對于Kubernetes來說，RBAC很重要，在這里我們不詳細展開，大家有需要可以參閱Kubernetes的相關文檔。這里我們只做一些基本介紹。在RBAC中，一個角色，role，它包含一組相關權限的規(guī)則。在RBAC中，權限是純粹累加的，并不存在拒絕某操作的規(guī)則。角色可以用Role定義到某個命名空間上，或者用ClusterRole定義到整個集群。在RBAC中，可以定義描述資源，比如pod和node；允許對資源使用動詞，比如get，update和delete。同時，RBAC上內(nèi)置了一系列默認的ClusterRoles，包括cluster-admin，admin，edit，view，賦予不同的用戶對不同的資源進行不同的操作的權限。

另外，通過 Amazon EKS 集群上服務賬戶 (service account)的 IAM 角色，您可以將 IAM 角色與 Kubernetes 服務賬戶關聯(lián)。然后，此服務賬戶就能夠為使用它的任何一個 Pod 中的容器提供 AWS 權限。您可以將 IAM 權限范圍限定到服務賬戶，并且只有使用該服務賬戶的 Pod 可以訪問這些權限。

其次，我們看一下平臺安全。在這里，我們考慮的是記錄和審核控制平面的安全?？刂破矫娴娜罩居涗?，特別是圍繞API動作的審核記錄，是平臺安全的重要部分。對于ECS來講，由于它是AWS原生的容器服務，所以和其它AWS產(chǎn)品一下，控制平面的日志會進入AWS CloudTrail中，進行云資源調(diào)用的記錄。CloudTrail 是一項支持對AWS 賬戶進行監(jiān)管、合規(guī)性檢查、操作審核和風險審核的服務。借助 CloudTrail，您可以記錄日志、持續(xù)監(jiān)控并保留與整個 AWS 基礎設施中的操作相關的賬戶活動。對于Kubernetes來講，它的控制平面包括審計跟蹤，但這些日志在默認情況下不會公開。EKS有一個功能可以啟用這些日志，我們建議啟用并且將它們發(fā)送到Amazon CloudWatch進行進一步的處理并發(fā)現(xiàn)洞察。

第三，我們看一下網(wǎng)絡和防火墻的配置，這也是容器安全實踐中最重要的部分。對于ECS來講，由于它是AWS的原生服務，您只需要了解和配置Amazon VPC和AWS安全組即可。而對于EKS，除了管理VPC和安全組之外，還需要安裝和配置Kubernetes的網(wǎng)絡插件和網(wǎng)絡策略等。

我們先來看一下ECS的網(wǎng)絡配置。當我們將ECS與VPC結合使用的時候，每個任務都會有自己專用的彈性網(wǎng)絡接口 (ENI)。由于每個任務和每個ENI是一一對應的，而每個ENI和安全組也是一一對應的，因此每個任務進出的任何通信都會通過安全組來進行，從而簡單便捷的實現(xiàn)網(wǎng)絡的安全性。

對于EKS來講，在創(chuàng)建新的Kubernetes集群的時候，EKS會為與集群通信的托管Kubernetes API服務器創(chuàng)建一個終端節(jié)點。默認情況下，這個API終端節(jié)點對于Internet是公有的，對API終端節(jié)點的訪問，我們使用AWS IAM和Kubernetes RBAC的組合加以保護。但是我們建議您啟動Kubernetes API終端節(jié)點的私有訪問，以使得工作節(jié)點和API終端節(jié)點之間的所有通信都在VPC之內(nèi)。您可以限制從Internet訪問API終端節(jié)點的IP地址，或者完全禁用對API終端節(jié)點的Internet訪問。

Amazon VPC CNI目前是Amazon EKS集群默認的網(wǎng)絡插件。在Amazon VPC CNI中，對于每個Kubernetes節(jié)點，我們創(chuàng)建多個ENI并且分配輔助IP地址，對于每個Pod，我們選擇空閑的輔助IP地址進行分配。這樣通過Amazon VPC CNI，可以使得EKS得到原生的Amazon VPC網(wǎng)絡支持，使得Pod和Pod直接互聯(lián)互通，包括單一主機內(nèi)的Pod通信，不同主機內(nèi)的Pod通信，甚至是Pod和其他AWS服務，Pod和On-Premise，Pod和Internet的通信，并提供了更快的網(wǎng)絡延遲。Amazon VPC CNI是一個開源項目，在GitHub上進行維護。

對于Kubernetes來講，網(wǎng)絡策略是一種關于 Pod 間及Pod與其他網(wǎng)絡間所允許的通信規(guī)則的規(guī)范。如果在EKS上進行網(wǎng)絡策略管理，首先需要將網(wǎng)絡策略提供程序添加到EKS中。Calico是EKS官方文檔中介紹的一種主流的方式。

一種既可以分配EC2實例級IAM角色，又可以完全信任基于安全組的方式，是為不同的Pod使用不同的工作節(jié)點集群，甚至是完全獨立的集群。EKS有NodeGroup的概念，它是一個獨立的自動伸縮的工作節(jié)點組，可以對其進行標記，這樣您就可以限制哪些Pod/服務可以在其上運行。

另外，服務網(wǎng)格也是可以對網(wǎng)絡進行配置和管理的一種方法。您可以使用服務網(wǎng)格來對所有服務進行加密和身份驗證，而不是強加AWS安全組或Kubernetes網(wǎng)絡策略之類的網(wǎng)絡級限制，從而在保持安全的同時允許更扁平的底層未分級網(wǎng)絡。服務網(wǎng)格通常是通過一組輕量級的網(wǎng)絡代理，與應用代碼部署在一起來實現(xiàn)的。網(wǎng)絡代理包含在每一個微服務之中，主要處理微服務之間的通信，監(jiān)控，以及一些安全相關的工作。我們可以使用服務網(wǎng)格增強安全性。以傳輸身份認證舉例，傳輸身份驗證可以理解為服務到服務的身份驗證，服務網(wǎng)格提供雙向TLS功能來實現(xiàn)。當開啟了雙向TLS后，服務間的流量為加密流量，并且相互根據(jù)證書以及密鑰進行訪問從而保障服務間的通信安全。

AWS App Mesh是AWS推出服務網(wǎng)格，App Mesh 能夠與 AWS 服務集成以進行監(jiān)控和跟蹤，還可以與很多常用的第三方工具結合使用。App Mesh 可以與在 AWS 上運行的各種容器，包括ECS，EKS，F(xiàn)argate，以及自建Kubernetes集群結合使用。另外，Istio也已經(jīng)支持在EKS上很好的部署。

第四，我們看一下操作系統(tǒng)的安全。在容器的EC2模式中，客戶的安全責任更多一些。比如要選擇的實例類型和數(shù)量，CPU與RAM的比率是多少，擴展能力和可用性是多少；還有選擇哪個操作系統(tǒng)，何時進行操作系統(tǒng)加固，何時給OS，Docker，ECS代理或kubelet打補丁等等，這些都是客戶的責任。在Fargate的模式下，對于安全責任，AWS做得更多，客戶做得更少。AWS負責擴展、修補、保護和管理服務器，為OS，Docker， ECS代理等進行打補丁的操作。Fargate需要運行在VPC網(wǎng)絡中，在Fargate中也沒有容器的特權模式，各個 ECS 任務或 EKS Pod 各自在其自己的專用內(nèi)核運行時環(huán)境中運行，并且不與其他任務和 Pod 共享 CPU、內(nèi)存、存儲或網(wǎng)絡資源。這樣可以確保針對每個任務或 Pod 進行工作負載隔離并提高安全性。

對于EKS來講，Kubernetes的更新也是一個很重要的話題。通常，Kubernetes每個季度都有一個新的主要版本，同時也會定期發(fā)布新的次要版本，有時Kubernetes更新與安全性相關。EKS具有用于觸發(fā)控制平面更新的API，在觸發(fā)之后您需要更新工作節(jié)點，例如，Kubernetes以及Docker和OS。通常工作節(jié)點在一個自動擴展組中，因此我們需要重新構建或者更新AMI。AWS為工作節(jié)點提供定期自動更新的的AMI和手動更新的腳本。

第五，我們看一下容器中客戶數(shù)據(jù)的安全。AWS同時具有Parameter Store和Secrets Manager來存儲您的機密。它們已集成到ECS中，但對于EKS，需要通過CLI或SDK在Kubernetes的Pod中調(diào)用它們。Kubernetes的內(nèi)置Secrets功能將機密存儲在其控制平面中，并通過環(huán)境變量或文件系統(tǒng)中的文件將其放入正在運行的Pod中，但是不能在Kubernetes集群之外使用它們。

我們在最近發(fā)布了一個新的功能。您可以使用 AWS Key Management Service (KMS) 生成的密鑰，對EKS中存儲的 Kubernetes Secrets進行信封加密；或者，您也可以將其他地方生成的密鑰導入KMS，并在EKS集群中使用。實施信封加密被視為存儲敏感數(shù)據(jù)的一種最佳安全實踐。我們使用開源的AWS Encryption Provider在EKS中為您提供KMS機密的信封加密。這個項目得到了Kubernetes社區(qū)和Kubernetes興趣小組的支持。

最后，我們看一下容器鏡像的安全。容器鏡像安全的最佳實踐包括：不在容器鏡像內(nèi)部存儲機密；讓一個容器對應一個服務，在任務/Pod內(nèi)使用Sidecar代理；最小化容器體積，只包括運行時需要的內(nèi)容等等。同時，我們要使用已知且受信任的基本鏡像，包括使用Docker Hub上的官方鏡像，仔細閱讀Dockerfiles，掃描鏡像以獲取CVE。我們需要在Dockerfile中指定USER和最小權限，以及為容器鏡像建立獨特且內(nèi)容豐富的標簽，來快速分辨出容器鏡像的版本。容器鏡像的掃描包括注冊表中的鏡像掃描，構建管道中的鏡像，和運行時的容器鏡像掃描。注冊表中的鏡像掃描由Docker Hub和Amazon ECR提供。另外還有一些第三方的開源或商業(yè)軟件可以對構建管道中的鏡像或者運行時的鏡像進行掃描。還有，我們也要保證運行時的容器安全。我們可以通過規(guī)則引擎限制可以在容器中執(zhí)行的操作，例如，“請勿運行容器中未包含的內(nèi)容”或 “請勿運行不在此白名單中的內(nèi)容”來確保只能在集群中部署/運行受信任的鏡像，我們需要隨時了解整個環(huán)境的運行時行為，一旦遇到CVE公開，立即檢測運行中的易受攻擊的容器