最近阿里雲容器團隊與Palo Alto Networks的安全團隊發現，目前用戶自己部署的Kubernetes集群中有約2752個可能存在安全隱患，比如用戶把Kubernetes的API向所有互聯網IP地址開放了。其中有超過120個Kubernetes集群甚至沒有啟用API認證，這導致了所有人都可以對這些不安全Kubernetes集群進行訪問，讀取信息，甚至遠程部署惡意容器。這將給用戶帶來極大的安全風險。
同時，Palo Alto Networks的Unit42的資深研究員Jay Chan發現目前全球有超過1400個不安全的Docker主機，8673個不安全運行的容器，17927個有漏洞的鏡像和15229個不安全的目錄掛載。更需要大家引起重視的是，其中47.7%在中國。可查看原文鏈接。
首先，介紹一下什麼是Kubernetes的API server。
顧名思義，Kubernetes的API server的主要功能就是提供REST API，來訪問和控制Kubernetes集群的。它的功能非常強大，一旦你擁有了這個API的所有權限，也就類似你有了對整個集群的root權限了。
對於沒有對Kubernetes的API進行安全防護的情況，黑客可以通過以下三種方式對用戶環境產生極大影響：
- 1 部署帶有惡意軟件的容器
首先上傳惡意鏡像去公共的鏡像倉庫。然後自動的下載並部署到不安全的Kubernetes集群中去。 - 2 先部署合法的容器，然後容器運行時下載惡意代碼，並執行
首先先部署合法的容器在Kubernetes集群中，逃避一些容器鏡像檢查的策略。然後通過運行的容器去下載並執行惡意代碼。 - 3 直接在主機上部署並運行惡意代碼
通過部署一些特權容器，或者mount主機的根目錄進入容器，來獲得提權，直接在主機上下載惡意代碼，並且執行。
這些將給用戶帶來極大的安全隱患，我們需要對整個容器平臺進行安全的防護。
首先，我們怎麼知道我們的Kubernetes集群的API server有沒有啟用不安全的端口呢？
Kubernetes的API server默認監聽8080端口，也就是不安全的端口，所有的訪問都會接受，並且不需要通過任何的認證和授權。也就是剛才所提到的，如果你使用了這個默認配置，整個K8s集群等於是向所有人都開放了，這是個非常嚴重的問題。
你可以通過以下命令來檢查：
如果返回了類似如下的信息：
則說明你的K8s集群使用的默認設定，也就是說你的API端口不需要任何驗證就可以直接操作你的集群，需要馬上進行修復。
修改API server的配置中--insecure-port項參數為0，並且沒有配置--insecure-bind-address。
同時啟用安全的訪問端口：
o 啟用TLS加密。通過--tls-cert-file，--tls-private-key-file 這兩項來設置證書及密鑰。
o 默認端口為6443, 可以通過--secure-port來修改。
o 通過 --bind-address 來修改綁定地址。
詳細請參見Kubernetes官網。
整個Kubernetes的部署會比較複雜，同時對安全的配置也相當的麻煩。一些早期的Kubernetes版本中往往有很多安全漏洞存在。所以用戶可以直接使用阿里雲的ACK容器服務，通過很方便的導航式部署模式免去很多客戶的麻煩。阿里雲的ACK集群默認啟用安全的API訪問端口，系統組件的參數配置和鏡像均經過安全合規加固；同時通過授權管理，加密通信，證書管理，默認啟用RBAC等手段來加固整個客戶Kubernetes集群的平臺安全，徹底杜絕上述自建集群由於配置失誤縮帶來的重大安全隱患。
在授權管理方面，ACK採用阿里雲RAM和Kubernetes RBAC結合的機制，為用戶提供了對API server以及Kubernetes集群其他資源的訪問控制機制。用戶可以使用主賬號和具有管理員權限的子賬號角色扮演用戶進行授權管理，根據工作需要對管理的子賬號賦予細粒度的集群內資源訪問權限，例如某個集群的一個命名空間的只讀權限。
同時ACK還面向不同身份的使用者提供了相應的缺省RBAC角色模板，方便用戶使用：
| 角色 | 說明 |
|---|---|
| 管理員 | 對所有命名空間下所有資源的讀寫權限 |
| 運維人員 | 對所有命名空間下控制檯可見資源的讀寫權限，對集群節點，存儲卷，命名空間，配額的只讀權限 |
| 開發人員 | 對所有命名空間或所選命名空間下控制檯可見資源的讀寫權限 |
| 受限用戶 | 對所有命名空間或所選命名空間下控制檯可見資源的只讀權限 |
| 自定義 | 權限由您所選擇的 Cluster Role 決定，請在確定所選 Cluster Role 對各類資源的操作權限後再進行授權，以免子賬號獲得不符合預期的權限 |
使用ACK集群的用戶可以方便的通過控制檯或OpenAPI的方式獲取集群訪問kubeconfig憑證，如果因為人員離職等原因發生憑證的洩漏，可以立即吊銷，從而確保賬戶安全。更多內容請參考阿里雲容器服務官方文檔
Docker的進程隔離機制有可能導致的安全漏洞，對於安全要求高的客戶來講無法接受。例如客戶希望能夠有一個高隔離能力的多租平臺。這類用戶可以嘗試阿里雲新推出的安全沙箱容器的技術。不同於傳統Docker應用進程隔離，共享宿主機操作系統內核的設計特點，安全沙箱容器採用虛擬化技術隔離容器應用，每個容器都獨享操作系統內核。這樣的優勢在於隔離性大大提升，可以防止很多進程隔離帶來的安全隱患。並且安全沙箱容器的性能非常好，實測可以達到原生Docker性能的90%以上，而且運行效率還在持續提升。
除了架構方面的加固，用戶也需要對容器的東西，或者南北向的流量進行防護，對鏡像倉庫的鏡像進行漏洞掃描，對容器的進程，文件系統，系統調用等方面進行管理和保護。用戶也迫切希望看到對容器安全的管理和企業的開發運維流程結合起來，從而把DevOps演進為DevSecOps。這需要在容器鏡像的棲身之地鏡像倉庫入手。阿里雲的鏡像倉庫服務，可以支持 Linux、Windows、ARM 等多架構容器鏡像的託管。安全方面鏡像服務提供了基於RAM的認證授權機制容器鏡像掃描, 簽名等能力，並可以與第三方安全產品進行集成，例如Palo Alto Networks的Prisma Cloud。同時阿里雲還推出了鏡像服務企業版，提供了網絡和權限的訪問控制，並支持更為安全的雲原生交付鏈管理。
基於容器的開發，集成，部署，運行環境變得越來越複雜，如何全面保護這個快速變化的環境遠遠比單單保護Kubernetes集群複雜的多。Gartner在2019年十月發佈的一份雲安全研究報告中提到，那些在雲環境中最成功的網絡攻擊，都是由於用戶的設置缺失，人為錯誤或者管理失敗造成的，而不是公有云廠商安全防護職責的失誤。
早在2017年，Twistlock的聯合創始人John Merrolo就受邀為美國國家標準技術研究所 (NIST) 編寫了SP800-190應用容器安全指南。美國國家標準技術研究所 (NIST) 的職責之一是發佈計算機網絡安全標準和指南。 美國聯邦政府部門需要在NIST安全指南發佈一年之內遵照執行。Twistlock在2019年五月成為Palo Alto Networks雲安全平臺Prisma的一員，同時John Merrolo先生成為Prisma的全球副總裁，繼續引領公司成為主流的容器安全平臺。
在過去的五年中，Prisma為超過90%的美國聯邦政府機構，超過40%的財富100強企業服務，為他們的容器環境通過全面的保護。在此主要列舉客戶在容器安全領域面對的十大挑戰：
- 1 對容器環境提供實時全面直觀的可視性，我們保護不了我們看不見的環境。
- 2 控制鏡像的來源，讓應用的開發，集成，部署，運行的生命週期中只使用可靠的鏡像來源。
- 3 在應用的生命週期中持續的進行鏡像漏洞掃描。漏洞發現不斷更新，昨天安全的鏡像可能今天就會因為新發現的漏洞而成為駭客的攻擊目標。實時監控鏡像存在已知漏洞及其嚴重性以制定修復優先次序。
- 4 監控和管理生產環境，包括對容器漏洞持續監控，修復存在漏洞的容器。
- 5 實時監控特權容器的使用，以防止駭客通過容器攻擊主機。
- 6 實時監控應用服務暴露在集群之外的容器。這些容器最容易受到攻擊。
- 7 實時監控運行時中所有容器的異常行為，對於異常行為報警或阻斷。
- 8 甄別和阻斷惡意容器攻擊。
- 9 對容器應用服務進行合規性的檢查和持續監控，能夠檢查CIS, PCI-DSS, HIPAA, GDPR, NIST SP 800-190, 以及FISMA等常見的國際標準。
- 10 建立和監控針對容器環境和雲原生應用程序的訪問控制措施，並與企業和雲廠商的訪問控制系統集成。
面對這些挑戰，我們需要一直努力完善對容器環境的保護。我們不但要有效保護在共有云和專有云中部署的Kubernetes集群，還需要為整個軟件生命週期，提供跨主機、容器和無服務器部署的整體保護。Prisma Cloud計算版本身是雲原生的，並且支持 API，與阿里雲的ACK，ASK容器平臺無縫集成。同時，Palo Alto Networks的容器安全解決方案也將很快上架阿里雲的容器鏡像市場，方便大家快速部署並集成到大家的容器平臺之中。
阿里雲大學提供的免費雲原生技術公開課，詳細講解了Kubernetes 以及它的安全訪問控制。阿里雲大學還提供了免費的容器安全與Palo Alto Networks解決方案課程， 對於如何利用Prisma Cloud 計算版全面保護你的容器環境和應用的生命週期進行了詳細的講解和演示，為了方便大家討論Kubernetes的防護以及容器安全解決方案，Palo Alto Networks與阿里雲容器團隊建立了容器安全討論釘釘群。歡迎大家掃碼加入釘釘群和我們進一步討論容器安全的話題。