> 原文連結：[https://fuckcloudnative.io/posts/security-best-practices-for-kubernetes-pods/](https://fuckcloudnative.io/posts/security-best-practices-for-kubernetes-pods/) 對於大部分 Kubernetes 使用者來說，安全是無關緊要的，或者說沒那麼緊要，就算考慮到了，也只是敷衍一下，草草了事。實際上 Kubernetes 提供了非常多的選項可以大大提高應用的安全性，只要用好了這些選項，就可以將絕大部分的攻擊抵擋在門外。為了更容易上手，我將它們總結成了幾個最佳實踐配置，大家看完了就可以開幹了。當然，本文所述的最佳安全實踐僅限於 Pod 層面，也就是容器層面，於容器的生命週期相關，至於容器之外的安全配置（比如作業系統啦、k8s 元件啦），以後有機會再嘮。 ## 1. 為容器配置 Security Context 大部分情況下容器不需要太多的許可權，我們可以通過 `Security Context` 限定容器的許可權和訪問控制，只需加上 SecurityContext 欄位： ```yaml apiVersion: v1 kind: Pod metadata: name: spec: containers:   - name: image: + securityContext: ``` ## 2. 禁用 allowPrivilegeEscalation `allowPrivilegeEscalation=true` 表示容器的任何子程序都可以獲得比父程序更多的許可權。最好將其設定為 false，以確保 `RunAsUser` 命令不能繞過其現有的許可權集。 ```yaml apiVersion: v1 kind: Pod metadata: name: spec: containers:   - name: image: securityContext: + allowPrivilegeEscalation: false ``` ## 3. 不要使用 root 使用者 為了防止來自容器內的提權攻擊，最好不要使用 root 使用者執行容器內的應用。UID 設定大一點，儘量大於 `3000`。 ```yaml apiVersion: v1 kind: Pod metadata: name: spec: securityContext: + runAsUser: + runAsGroup: ``` ## 4. 限制 CPU 和記憶體資源 這個就不用多說了吧，requests 和 limits 都加上。 ## 5. 不必掛載 Service Account Token ServiceAccount 為 Pod 中執行的程序提供身份標識，怎麼標識呢？當然是通過 Token 啦，有了 Token，就防止假冒偽劣程序。如果你的應用不需要這個身份標識，可以不必掛載： ```yaml apiVersion: v1 kind: Pod metadata: name: spec: + automountServiceAccountToken: false ``` ## 6. 確保 seccomp 設定正確 對於 Linux 來說，使用者層一切資源相關操作都需要通過系統呼叫來完成，那麼只要對系統呼叫進行某種操作，使用者層的程式就翻不起什麼風浪，即使是惡意程式也就只能在自己程序記憶體空間那一分田地晃悠，程序一終止它也如風消散了。seccomp（secure computing mode）就是一種限制系統呼叫的安全機制，可以可以指定允許那些系統呼叫。 對於 Kubernetes 來說，大多數容器執行時都提供一組允許或不允許的預設系統呼叫。通過使用 `runtime/default` 註釋或將 Pod 或容器的安全上下文中的 seccomp 型別設定為 `RuntimeDefault`，可以輕鬆地在 Kubernetes 中應用預設值。 ```yaml apiVersion: v1 kind: Pod metadata: name: annotations: + seccomp.security.alpha.kubernetes.io/pod: "runtime/default" ``` 預設的 seccomp 配置檔案應該為大多數工作負載提供足夠的許可權。如果你有更多的需求，可以自定義配置檔案。 ## 7. 限制容器的 capabilities 容器依賴於傳統的Unix安全模型，通過控制資源所屬使用者和組的許可權，來達到對資源的許可權控制。以 root 身份執行的容器擁有的許可權遠遠超過其工作負載的要求，一旦發生洩露，攻擊者可以利用這些許可權進一步對網路進行攻擊。 預設情況下，使用 Docker 作為容器執行時，會啟用 `NET_RAW` capability，這可能會被惡意攻擊者進行濫用。因此，建議至少定義一個`PodSecurityPolicy`(PSP)，以防止具有 NET_RAW 功能的容器啟動。 通過限制容器的 capabilities，可以確保受攻擊的容器無法為攻擊者提供橫向攻擊的有效路徑，從而縮小攻擊範圍。 ```yaml apiVersion: v1 kind: Pod metadata: name: spec: securityContext: + runAsNonRoot: true + runAsUser: capabilities: drop: + -NET_RAW + -ALL ``` 如果你對 Linux capabilities 這個詞一臉懵逼，建議去看看我的腦殘入門系列： + [Linux Capabilities 入門教程：概念篇](https://fuckcloudnative.io/posts/linux-capabilities-why-they-exist-and-how-they-work/) + [Linux Capabilities 入門教程：基礎實戰篇](https://fuckcloudnative.io/posts/linux-capabilities-in-practice-1/) + [Linux Capabilities 入門教程：進階實戰篇](https://fuckcloudnative.io/posts/linux-capabilities-in-practice-2/) ## 8. 只讀 如果容器不需要對根檔案系統進行寫入操作，最好以只讀方式載入容器的根檔案系統，可以進一步限制攻擊者的手腳。 ```yaml apiVersion: v1 kind: Pod metadata: name: spec: containers:   - name: image: securityContext: + readOnlyRootFilesystem: true ``` ## 9 總結 總之，Kubernetes 提供了非常多的選項來增強叢集的安全性，沒有一個放之四海而皆準的解決方案，所以需要對這些選項非常熟悉，以及瞭解它們是如何增強應用程式的安全性，才能使叢集更加穩定安全。 最後，請記住：你需要萬分小心你的 YAML 檔案內容縮排，如果你的 YAML 檔案非常多，眼睛看花了，希望下面的神器可以助你一臂之力：  ---- Kubernetes 1.18.2 1.17.5 1.16.9 1.15.12離線安裝包釋出地址http://store.lameleg.com ，歡迎體驗。 使用了最新的sealos v3.3.6版本。 作了主機名解析配置優化，lvscare 掛載/lib/module解決開機啟動ipvs載入問題， 修復lvscare社群netlink與3.10核心不相容問題,sealos生成百年證書等特性。更多特性 https://github.com/fanux/sealos 。歡迎掃描下方的二維碼加入釘釘群 ，釘釘群已經整合sealos的機器人實時可以看到sealos的動態。 ![](https://img2020.cnblogs.com/other/1737323/202012/1737323-20201215142808284-272881