原文作者：Leonid Sandler
原文譯自：CNCF（云原生基金會）
對于在共享基礎(chǔ)架構(gòu)上運(yùn)行的容器化應(yīng)用程序，安全性至關(guān)重要。隨著越來越多的組織將其容器工作負(fù)載轉(zhuǎn)移到 Kubernetes，K8s 已成為容器編排的首選平臺。隨著這一趨勢的出現(xiàn)，越來越多的威脅和新的攻擊方式需要加強(qiáng)所有安全層。
在 Kubernetes 中，安全性有兩個方面：集群安全性和應(yīng)用程序安全性。這篇文章，我們主要將探討如何保護(hù) ?Kubernetes 部署和應(yīng)用程序的安全。
復(fù)習(xí)基礎(chǔ)知識
在這里快速回顧一下基礎(chǔ)知識：Pod 是在集群中運(yùn)行一個或多個容器的邏輯原子單元；它由其他資源包裝，例如 ReplicaSet、Deployment、StatefulSets 等。有多種方法可以改善在 Kubernetes 中運(yùn)行的應(yīng)用程序的安全狀況。
在 Kubernetes 部署中， 模板部分包含 pod 規(guī)范，這些規(guī)范定義了此部署必須運(yùn)行的工作負(fù)載。在下面的模板中，幾個與安全相關(guān)的部分以粗體突出顯示：
現(xiàn)在，讓我們仔細(xì)看看pod 規(guī)范中的這些內(nèi)容。
服務(wù)帳號
當(dāng)容器內(nèi)的進(jìn)程與 API 服務(wù)器通信時，您應(yīng)該使用服務(wù)帳戶進(jìn)行身份驗證。如果您沒有為 pod 定義服務(wù)帳戶，則將使用默認(rèn)帳戶。建議使用執(zhí)行該功能所需的最低權(quán)限創(chuàng)建一個特定于應(yīng)用程序的服務(wù)帳戶。如果您選擇將角色授予默認(rèn)服務(wù)帳戶，則這些權(quán)限將可用于未在規(guī)范中定義服務(wù)帳戶的每個 pod。這可能會無意中允許對其他應(yīng)用程序的過度許可，因此不建議這樣做。在 Kubernetes 1.6 及更高版本中，您可以通過設(shè)置來選擇不為容器中的服務(wù)帳戶自動掛載 API 令牌。
虛擬防火墻
虛擬防火墻定義 pod 和容器中的權(quán)限和訪問控制設(shè)置。以下是一些重要的列表：
-
· seLinuxOptions (Security-Enhanced Linux)： 應(yīng)用提供更精細(xì)訪問和控制策略的機(jī)制
-
· runAsUser和runAsGroup： 特定的UserID或GroupID（UID和GID）運(yùn)行容器進(jìn)程的入口點(diǎn)；如果未指定，則默認(rèn)為用戶在圖像元數(shù)據(jù)中指定的（在 Windows 容器中均無效）。
-
· privileged：以特權(quán)模式運(yùn)行容器，默認(rèn)為 false；與主機(jī)上的 root（具有所有功能）相同
-
· runAsNonRoot： 容器必須以非 root 用戶身份運(yùn)行（如果 Kubelet 在運(yùn)行時驗證時 UID 為 0，則容器將無法啟動）。
-
· 能力： 在運(yùn)行容器時添加或刪除能力；容器運(yùn)行時授予功能，這是默認(rèn)設(shè)置。
-
· procMount：指定容器的 proc 掛載類型，默認(rèn)為 DefaultProcMount；這將容器運(yùn)行時默認(rèn)值用于只讀和掩碼路徑。
-
· AppArmor： 與 SELinux 類似，可以通過配置文件限制單個程序的功能。
-
· seccompProfile： 容器使用的 secomp 選項；過濾進(jìn)程的系統(tǒng)調(diào)用
-
· readOnlyRootFilesystem： 將容器中的根文件系統(tǒng)掛載為只讀；默認(rèn)為假
-
· AllowPrivilegeEscalation： 決定一個進(jìn)程是否可以獲得比其父進(jìn)程更多的權(quán)限；如果容器以 Privileged 或具有 CAP_SYS_ADMIN 功能運(yùn)行，則始終為 true。該字段必須顯式設(shè)置為 false，因為它的默認(rèn)行為可能會在 PSP 中更改。
Images
源Images通常取自各種公共存儲庫；開發(fā)人員將他們的應(yīng)用程序代碼放在這些基礎(chǔ)鏡像之上。您還可以直接從流行的公共注冊中心部署 OOTB 應(yīng)用程序。
關(guān)于Images，需要牢記三件事，下面我們一起討論一下。
Image來源
確保是從受信任的注冊表中獲取Image。攻擊者可以將惡意Image放置在公共注冊表中，這反過來又會導(dǎo)致數(shù)據(jù)泄露或攻擊者獲得對集群的訪問權(quán)等問題。許多公共Image也被發(fā)現(xiàn)被加密礦工感染。
作為一個組織，您可以創(chuàng)建基本映像的 golden images 并與開發(fā)人員共享它們，然后開發(fā)人員可以從他們的內(nèi)部存儲庫中安全地使用它們。
Distroless 和容器優(yōu)化鏡像
這些Images安全且經(jīng)過優(yōu)化，可在容器中運(yùn)行，從而減少了潛在攻擊的表面積。它們僅包含應(yīng)用程序和依賴庫，而 Linux 操作系統(tǒng)上通?？捎玫陌芾砥?、shell 和程序已被刪除。
持續(xù)漏洞掃描
強(qiáng)烈建議實(shí)施持續(xù)的映像掃描，以檢測容器映像中的漏洞、惡意軟件和其他安全威脅（例如，未經(jīng)授權(quán)連接到不受信任的網(wǎng)絡(luò)）。有許多可用的安全解決方案，包括 Kubescape。
Pod安全許可
你可能聽說過 Pod Security Policies，但是它現(xiàn)在已被棄用，將在 Kubernetes 1.25 中刪除。 PodS 安全準(zhǔn)入 (PSA) 將取代它來處理安全和其他與安全相關(guān)的要求。它為 pod 定義了不同的隔離級別，例如 privileged、baseline和 restricted。截至 Kubernetes 1.23，PSA 目前處于測試階段。
這些級別在 Kubernetes 的 Pod 安全標(biāo)準(zhǔn)中有詳細(xì)描述，但下面是 Kubernetes 自己的文檔的摘要：
Pod Security 準(zhǔn)入與內(nèi)置的 Pod Security 準(zhǔn)入控制器配合使用；您需要在集群中使用 –feature-gates=”...,PodSecurity=true” 或使用 pod admission webhook啟用此功能。它應(yīng)用于 命名空間級別，帶有以下標(biāo)簽：
在命名空間中，使用以下注解啟用 Pod 安全準(zhǔn)入：
使用秘密
如果在應(yīng)用程序中有可用的敏感信息（如憑證、令牌、加密密鑰和證書），請使用 Kubernetes Secrets。可以使用文字值或文件創(chuàng)建 Secret，然后將它們掛載到 pod 中。不要將此類信息存儲在容器映像和 Git 存儲庫中。
使用 Secrets 時，最好不要使用環(huán)境變量將憑據(jù)投影到容器中，而是使用文件。
請記住，Secrets 是 base64 編碼的值。它們未加密，因此必須限制對安全對象的訪問，并且應(yīng)該在 API 服務(wù)器的寫入時啟用加密。
結(jié)論
Kubernetes 提供了多種方法來改善集群的安全狀況。開發(fā)人員需要考慮如何利用這些結(jié)構(gòu)來使應(yīng)用程序更安全。
回顧一下：
-
1. 每個應(yīng)用程序使用服務(wù)帳戶，并將服務(wù)帳戶與最低角色和權(quán)限要求綁定，以實(shí)現(xiàn)目標(biāo)。
-
2. 如果應(yīng)用程序不需要服務(wù)帳戶令牌，請不要自動掛載它。
-
3. 使用虛擬防火墻來實(shí)現(xiàn)各種技術(shù)，例如防止容器在特權(quán)模式下以 root 用戶身份運(yùn)行，使用 SELinux 或 AppArmor 配置文件等等。
-
4. 確保容器鏡像的來源是可信的，如果可以的話，將它們存儲在私有注冊表中。
-
5. 嘗試使用容器優(yōu)化的圖像來減少表面積以最大程度地減少威脅。
-
6. 部署持續(xù)的漏洞掃描解決方案，不僅在 CI/CD 中，而且在集群中，可以實(shí)時監(jiān)控和采取行動。
-
7. 使用 Pod 安全準(zhǔn)入配置文件和模型為工作負(fù)載提供不同的隔離級別。
-
8. 使用 Secrets 存儲敏感信息，并應(yīng)用最低權(quán)限 RBAC 來限制用戶/SA 秘密訪問。
希望本文對您有所幫助……
讓企業(yè)都能高效創(chuàng)新
企業(yè)云原生數(shù)字化創(chuàng)新平臺CloudOS?
可插拔云原生工具集Cloud Native Toolkit
開發(fā)者專屬一站式在線服務(wù)Methodot
