【Kubernetes安全系列第二篇】kubernetes基礎設施的安全
【Kubernetes安全系列第二篇】kubernetes基礎設施的安全
在我們開始保護kubernetes平臺安全的任務之前，《Securing Kubernetes for Cloud Native Applications》系列的第一篇文章中，討論了為什麼很難保護Kubernetes，以及需要我們注意的各個層的概述。
堆疊中的第一層是基礎架構層。 我們可以通過許多不同的方式對此進行定義，但出於討論的目的，它是基於Kubernetes部署的基礎架構元件的總和。 它是用於計算，儲存和網路目的的物理或抽象硬體層，以及這些資源所處的環境。 它還包括作業系統（很可能是Linux）和容器執行時環境（如Docker）。
我們將要討論的大部分內容同樣適用於支援Kubernetes以外的系統的基礎設施元件，但我們將特別關注那些可以增強Kubernetes安全性的因素。
機器，資料中心和公共雲
採用雲平臺作為工作負載部署的工具，無論是公共，私有還是混合組合，都在繼續快速發展。 雖然對專業裸機伺服器配置的需求尚未完全消失，但支撐當今大部分計算資源的基礎設施是虛擬機器。 但是，如果我們部署的機器是虛擬的（基於雲的或其他）或物理的，實體將駐留在由我們自己的組織或選定的第三方託管的資料中心，例如公共雲提供商，這並不重要。
資料中心很複雜，在考慮安全性方面需要考慮很多。 它是託管整個組織的資料處理要求的一般資源，甚至是來自不同行業和地區的眾多獨立組織的共同租用工作負載。 出於這個原因，在這個級別上對基礎設施的許多不同方面應用安全性，往往是一個成熟的公司或供應商的責任。 它將根據諸如國家或國際法規（HIPAA，GDPR），行業合規要求（PCI DSS）等因素進行管理，並且通常會獲得認證標準認證（ISO 27001，FIPS）。
在公共雲環境的情況下，供應商可以並且將在基礎設施層提供必要的遵守法規和合規標準，但在某些時候，它會下沉到服務消費者（您和我），以進一步構建這個安全的基礎。 這是一項共同的責任。 這引出了一個問題，作為一個公共雲服務消費者，“我應該保護什麼，我該怎麼做呢？”有很多人對這個話題有很多不同的看法，但是真正可靠的實體是網際網路安全（CIS），一個致力於保護公共和私人實體免受惡意網路活動威脅的非營利組織。
CIS基準測試
CIS提供了一系列工具，技術和資訊，用於對抗我們所依賴的系統和資料的潛在威脅。 例如，CIS基準是安全專業人員和主題專家共同編制的針對每個平臺安全的最佳實踐配置指南。 為了鼓勵越來越多的組織開始實施轉型計劃，其中包括遷移到公共和/或混合雲基礎架構，CIS開展了對應的業務，為主要的公共雲提供商提供基準。 CIS Amazon Web Services Foundations Benchmark就是一個例子，其他主要公共雲提供商也有類似的基準。
這些基準測試提供基礎安全配置建議，包括身份和訪問管理（IAM），入口和出口，以及日誌和監視最佳實踐等。 實施這些基準建議是一個很好的開始，但它不應該是旅程的終點。 每個公共雲提供商都有自己的一套詳細的推薦最佳實踐[^1] [^2] [^3]，並且可以從相關領域中的其他專家聲音中獲得很多好處，例如雲安全聯盟。
讓我們花一點時間來看一下典型的基於雲的場景，需要從安全形度進行一些仔細的規劃。
雲場景：專用網 vs 公有網
我們如何通過限制訪問來平衡保持Kubernetes叢集安全的需求，同時通過Internet以及我們自己的組織內部外部客戶端實現所需的訪問？
service.beta.kubernetes.io/aws-load-balancer-internal：0.0.0.0/0
此方案表明需要仔細考慮如何保證基礎架構配置的安全，同時提供向其目標受眾提供服務所需的功能。 這不是一個特殊的場景，還有其他情況需要類似的處理。
鎖定目標：作業系統和容器執行時
假設我們已經調查並應用了必要的安全配置以使機器級基礎架構及其環境安全，那麼下一個任務是鎖定每臺機器的主機作業系統（OS），以及負責管理容器生命週期的容器執行時。
Linux OS
雖然可以將Microsoft Windows Server作為Kubernetes工作節點的作業系統執行，但控制平面和工作節點通常會執行Linux作業系統的變體。 可能有許多因素決定使用Linux發行版（商業，內部技能，作業系統成熟度），但如果可能的話，請使用專為執行容器而設計的最小發行版。 比如CoreOS Container Linux，Ubuntu Core和Atomic Host變體。 這些作業系統已經被剝離到最低限度以便於大規模地執行容器，因此具有顯著減小的攻擊面。
同樣，CIS為不同風格的Linux提供了許多不同的基準，為保護作業系統提供了最佳實踐建議。 這些基準涵蓋了可能被認為是Linux的主流發行版，例如RHEL，Ubuntu，SLES，Oracle Linux和Debian。 如果未涵蓋您的首選發行版，則存在獨立發行版的CIS基準測試，並且通常存在特定發行版的準則，例如CoreOS容器Linux強化指南。
Docker Engine
基礎結構中的最後一個元件是容器執行時。 在Kubernetes的早期，沒有選擇; 容器執行時必然是Docker引擎。 然而，隨著Kubernetes容器執行時介面的出現，可以刪除Docker引擎依賴性，轉而使用CRI-O，containerd或Frakti等執行時。事實上，從Kubernetes 1.12開始，這是一個alpha功能（執行時），允許在叢集中並行執行多個容器執行時。 無論部署哪個容器執行時，它們都需要被保護。
儘管選擇多種多樣，但Docker引擎仍然是Kubernetes的預設容器執行時（儘管在不久的將來可能會改變為containerd^4），我們將在此考慮其安全性含義。 它是使用大量可配置的安全設定構建的，其中一些預設情況下是開啟的，但可以在每個容器的基礎上繞過它們。 其中一個例子是在建立時應用於每個容器的Linux核心功能的白名單，這有助於減少正在執行的容器內的可用許可權。
CIS再一次為Docker平臺CIS Docker Benchmark保留了基準。 它提供了有關配置Docker守護程式以獲得最佳安全性的最佳實踐建議。 甚至還有一個方便的開源工具（指令碼），名為Docker Bench for Security，可以針對Docker引擎執行，該引擎評估系統是否符合CIS Docker Benchmark。 可以定期執行該工具以暴露所需配置的任何漂移。
Docker被用作Kubernetes的容器執行時，在考慮和測量Docker引擎的安全配置時，需要注意一些事項。 Kubernetes忽略了Docker守護程式的許多可用功能，而是更喜歡自己的安全控制元件。 例如，Docker守護程式配置為使用seccomp配置檔案將可用Linux核心系統呼叫的預設白名單應用於每個建立的容器。 除非另有說明，否則Kubernetes將指示Docker從seccomp角度建立pod容器“unconfined”，使容器可以訪問每個可用的系統呼叫。 換句話說，可以在較低的“Docker層”配置的內容可能會在平臺堆疊中的更高級別被撤消。 我們將在以後的文章中介紹如何通過安全上下文緩解這些差異。
總結
將所有注意力集中在平臺的Kubernetes元件的安全配置上可能很誘人。 但正如我們在本文中看到的那樣，較低層的基礎架構元件同樣重要，並且非常危險的是它們往往被被忽略。 實際上，提供安全的基礎架構層甚至可以緩解我們可能在叢集層本身中引入的問題。 例如，保持我們的節點私密性將防止不充分安全的kubelet被用於惡意目的。 基礎設施元件應該與Kubernetes元件本身一樣受到關注。
在下一篇文章中，我們將繼續討論安全堆疊中下一層的含義，即Kubernetes叢集元件。
[^1]:AWS Security Best Practices
[^2]:Azure security best practices and patterns
[^3]:Best practices for enterprise organizations | Google Cloud