Kubernetes 最佳安全實踐指南

原文連接：fuckcloudnative.io/posts/secur…

對於大部分 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 文件很是多，眼睛看花了，但願下面的神器能夠助你一臂之力：