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 這個詞一臉懵逼,建議去看看我的腦殘入門系列:

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的動態。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM