Kubernetes 最佳安全實踐指南-有解無憂

原文鏈接：https://fuckcloudnative.io/posts/security-best-practices-for-kubernetes-pods/

對于大部分 Kubernetes 用戶來說，安全是無關緊要的，或者說沒那么緊要，就算考慮到了，也只是敷衍一下，草草了事，實際上 Kubernetes 提供了非常多的選項可以大大提高應用的安全性，只要用好了這些選項，就可以將絕大部分的攻擊抵擋在門外，為了更容易上手，我將它們總結成了幾個最佳實踐配置，大家看完了就可以開干了，當然，本文所述的最佳安全實踐僅限于 Pod 層面，也就是容器層面，于容器的生命周期相關，至于容器之外的安全配置（比如作業系統啦、k8s 組件啦），以后有機會再嘮，

1. 為容器配置 Security Context

大部分情況下容器不需要太多的權限，我們可以通過 Security Context 限定容器的權限和訪問控制，只需加上 SecurityContext 欄位：

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
? -?name: <container name>
  image: <image>
+   securityContext:

2. 禁用 allowPrivilegeEscalation

allowPrivilegeEscalation=true 表示容器的任何子行程都可以獲得比父行程更多的權限，最好將其設定為 false，以確保 RunAsUser 命令不能繞過其現有的權限集，

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
? -?name: <container name>
  image: <image>
    securityContext:
  +   allowPrivilegeEscalation: false

3. 不要使用 root 用戶

為了防止來自容器內的提權攻擊，最好不要使用 root 用戶運行容器內的應用，UID 設定大一點，盡量大于 3000，

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
  securityContext:
+   runAsUser: <UID higher than 1000>
+   runAsGroup: <UID higher than 3000>

4. 限制 CPU 和記憶體資源

這個就不用多說了吧，requests 和 limits 都加上，

5. 不必掛載 Service Account Token

ServiceAccount 為 Pod 中運行的行程提供身份標識，怎么標識呢？當然是通過 Token 啦，有了 Token，就防止假冒偽劣行程，如果你的應用不需要這個身份標識，可以不必掛載：

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
+ automountServiceAccountToken: false

6. 確保 seccomp 設定正確

對于 Linux 來說，用戶層一切資源相關操作都需要通過系統呼叫來完成，那么只要對系統呼叫進行某種操作，用戶層的程式就翻不起什么風浪，即使是惡意程式也就只能在自己行程記憶體空間那一分田地晃悠，行程一終止它也如風消散了，seccomp（secure computing mode）就是一種限制系統呼叫的安全機制，可以可以指定允許那些系統呼叫，

對于 Kubernetes 來說，大多數容器運行時都提供一組允許或不允許的默認系統呼叫，通過使用 runtime/default 注釋或將 Pod 或容器的安全背景關系中的 seccomp 型別設定為 RuntimeDefault，可以輕松地在 Kubernetes 中應用默認值，

apiVersion: v1
kind: Pod
metadata:
  name: <name>
  annotations:
  + seccomp.security.alpha.kubernetes.io/pod: "runtime/default"

默認的 seccomp 組態檔應該為大多數作業負載提供足夠的權限，如果你有更多的需求，可以自定義組態檔，

7. 限制容器的 capabilities

容器依賴于傳統的Unix安全模型，通過控制資源所屬用戶和組的權限，來達到對資源的權限控制，以 root 身份運行的容器擁有的權限遠遠超過其作業負載的要求，一旦發生泄露，攻擊者可以利用這些權限進一步對網路進行攻擊，

默認情況下，使用 Docker 作為容器運行時，會啟用 NET_RAW capability，這可能會被惡意攻擊者進行濫用，因此，建議至少定義一個PodSecurityPolicy(PSP)，以防止具有 NET_RAW 功能的容器啟動，

通過限制容器的 capabilities，可以確保受攻擊的容器無法為攻擊者提供橫向攻擊的有效路徑，從而縮小攻擊范圍，

apiVersion: v1
kind: Pod
metadata:
  name: <name>
spec:
  securityContext:
  + runAsNonRoot: true
  + runAsUser: <specific user>
  capabilities:
  drop:
  + -NET_RAW
  + -ALL

如果你對 Linux capabilities 這個詞一臉懵逼，建議去看看我的腦殘入門系列：

Linux Capabilities 入門教程：概念篇
Linux Capabilities 入門教程：基礎實戰篇
Linux Capabilities 入門教程：進階實戰篇

8. 只讀

如果容器不需要對根檔案系統進行寫入操作，最好以只讀方式加載容器的根檔案系統，可以進一步限制攻擊者的手腳，

apiVersion: v1
kind: Pod
metadata:
  name: <Pod name>
spec:
  containers:
? -?name: <container name>
  image: <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://www.uj5u.com/qita/235331.html

標籤：其他

上一篇：表示數值的字串

下一篇：容器網路（八）如何使用 flannel host-gw【57】