實操教程丨使用Pod安全策略強化K8S安全

本文來自Rancher Labs

什麼是Pod安全策略？

Kubernetes Pod安全策略（PSP）是Kubernetes安全版塊中極爲重要的組件。Pod安全策略是集羣級別的資源，用於控制Pod安全相關選項，而且仍是一種強化Kubernetes工做負載安全性的機制。Kubernetes平臺團隊或集羣運維人員能夠利用它來控制pod的建立以及限制特定的用戶、組或應用程序可使用的功能。

舉個簡單的例子，使用PSP你能夠：

• 防止特權Pod啓動並控制特權升級。

• 限制Pod能夠訪問的主機命名空間、網絡和文件系統

• 限制能夠運行pod的用戶/組。

• 限制Pod能夠訪問的Volume

• 限制其餘參數，如運行時配置文件或只讀根文件系統

在本文中，咱們將向你展現在Rancher中如何經過啓用一個簡單的Pod安全策略來強化你的Kubernetes安全。

Pod安全策略真的能夠加強K8S的安全性嗎？

是的，Pod安全策略確實能夠加強Kubernetes的安全性。它提供了Kubernetes原生控制機制，能夠防止威脅而不影響性能，這與agent必須攔截主機上的每一個動做有所區別。

若是你還沒有在集羣中啓用PSP（或執行訪問控制之類的等效方法），則Kubernetes用戶可能會生成特權集羣。這將會被惡意利用，例如提高特權進而突破容器隔離並訪問其餘Pod/服務。

若是沒有限制Pod spec特權的機制，攻擊者能夠經過docker命令執行任何操做，例如，運行特權容器、使用節點資源等。

想要快速驗證以上說法，你能夠執行如下腳本（千萬不要在生產集羣上操做）：

❯ ./kubectl-root-in-host.sh
bash-4.4# whoami
root
bash-4.4# hostname
sudo--alvaro-rancher-rancheragent-0-all

你能夠得到對Kubernetes節點的即時root訪問權限。是否是有點後怕呢？

經過遵循最小特權的概念，你能夠安全地在集羣中實現PSP，並確保在Kubernetes Pod或工做負載中沒有不須要的權限。除了Kubernetes安全的核心理念外，最小特權原則也是一種通用的安全最佳實踐，同時仍是諸如PCI、SOC2或HIPAA等合規性標準的核心要求。

總結一下：

• PSP將爲Pod授予的安全功能提供默認安全約束，該pod能夠是集羣上任何用戶建立的

• PSP還能經過知足特定合規性基準的要求幫助你驗證合規性

最小特權是一個概念，也是一個實踐，能夠將用戶、帳號和計算過程的訪問權限限制爲僅執行平常合法活動所須要的資源。

在你的集羣中啓用Pod安全策略

在Kubernetes中Pod安全策略能夠實現爲Admission Controller。要在你的集羣中啓用PSP，確保PodSecurityPolicy在enable-admission-plugins列表內，做爲參數傳遞給你的Kubernetes API配置的參數：

--enable-admission-plugins=...,PodSecurityPolicy

提供託管Kubernetes集羣（你沒法直接訪問API配置）的雲提供商一般會提供高級設置，用戶能夠在整個集羣範圍內啓用PSP。在其餘狀況下，你可能須要編輯/etc/kubernetes/manifests/kube-apiserver.yaml文件，並將其添加到相應的命令參數中。

在Rancher中，你能夠在UI上編輯集羣來輕鬆啓用PSP：

你能夠選擇默認應用哪一個Pod安全策略。在本例中，咱們選擇了restricted（受限）。

使用一個Admission controller來啓用PSP的好處在於它提供了一個即時預防機制，甚至能夠在調度以前中止部署過分特權的Pod。缺點就是你啓用一個PSP以後，每一個pod都須要通過PSP的批准，使其部署和過渡更加困難。

Rancher中啓用基本Pod安全策略demo

在這一部分中，咱們將逐步演示如何經過Rancher dashboard在集羣中啓用Pod安全策略，並在默認狀況下使用受限策略，並瞭解如何防止建立特權Pod。

PSP對象自己是將要應用於pod specs的要求和約束的列表。PSP YAML以下所示：

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: example
spec:
  allowedCapabilities:
    - NET_ADMIN
    - IPC_LOCK
  allowedHostPaths:
    - pathPrefix: /dev
    - pathPrefix: /run
    - pathPrefix: /
  fsGroup:
    rule: RunAsAny
  hostNetwork: true
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  privileged: true
  runAsUser:
    rule: RunAsAny
  volumes:
    - hostPath
    - secret

以上PSP有不少容許權限，例如：

• 它容許pod能夠與其餘Linux功能（如NET_ADMIN和IPC_LOCK）一塊兒運行

• 它容許從主機安裝敏感路徑

• Pod能夠做爲特權運行

瀏覽Kubernetes官方文檔能夠獲取可用的PSP控件及其默認值的完整列表：

https://kubernetes.io/docs/concepts/policy/pod-security-policy/

讓咱們來看一個示例，說明如何防止特權Pod在集羣中運行。

在集羣中啓用PSP以後，請嘗試部署相似的pod：

deploy-not-privileged.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: not-privileged-deploy
  name: not-privileged-deploy
spec:
  replicas: 1
  selector:
    matchLabels:
      app: not-privileged-deploy
  template:
    metadata:
      labels:
        app: not-privileged-deploy
    spec:
      containers:
        - image: alpine
          name: alpine
          stdin: true
          tty: true
          securityContext:
            runAsUser: 1000
            runAsGroup: 1000

它能夠當即使用，由於咱們告訴Rancher啓用具備受限安全策略的PSP，該策略容許沒有特權的pod正常運行，像上面那樣。

檢查默認PSP中的內容，以下所示：

$ kubectl get psp restricted-psp -o yaml

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  annotations:
    serviceaccount.cluster.cattle.io/pod-security: restricted
    serviceaccount.cluster.cattle.io/pod-security-version: "1960"
  creationTimestamp: "2020-03-04T19:56:10Z"
  labels:
    cattle.io/creator: norman
  name: restricted-psp
  resourceVersion: "2686"
  selfLink: /apis/policy/v1beta1/podsecuritypolicies/restricted-psp
  uid: 40957380-1d44-4e43-9333-91610e3fc079
spec:
  allowPrivilegeEscalation: false
  fsGroup:
    ranges:
      - max: 65535
        min: 1
    rule: MustRunAs
  requiredDropCapabilities:
    - ALL
  runAsUser:
    rule: RunAsAny
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    ranges:
      - max: 65535
        min: 1
    rule: MustRunAs
  volumes:
    - configMap
    - emptyDir
    - projected
    - secret
    - downwardAPI
    - persistentVolumeClaim

或者在Rancher的全局視角檢查。選擇【安全>Pod安全策略】並點擊受限的選項。

該PSP應該容許任何pod，只要它以標準用戶（不是root）身份運行，而且不須要任何特權和特殊功能。

有關PSP和RBAC的其餘內容，咱們將在之後進行探討。爲了簡單起見，加上Rancher已經爲你設置了必需的綁定，所以咱們如今略過這一部分。讓咱們嘗試部署一個特權pod，例如來自kubectl-root-in-host.sh腳本的那個pod：

deploy-privileged.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: privileged-deploy
  name: privileged-deploy
spec:
  replicas: 1
  selector:
    matchLabels:
      app: privileged-deploy
  template:
    metadata:
      labels:
        app: privileged-deploy
    spec:
      containers:
        - image: alpine
          name: alpine
          stdin: true
          tty: true
          securityContext:
            privileged: true
      hostPID: true
      hostNetwork: true

該pod將不會進入集羣

Warning  FailedCreate  2s (x12 over 13s)  replicaset-controller  Error creating: pods "privileged-deploy-7569b9969d-" is forbidden: unable to validate against any pod security policy: [spec.securityContext.hostNetwork: Invalid value: true: Host network is not allowed to be used spec.securityContext.hostPID: Invalid value: true: Host PID is not allowed to be used spec.containers[0].securityContext.privileged: Invalid value: true: Privileged containers are not allowed]

PodSecurityPolicy admission controller將不容許建立這個pod，由於現有的PSP不容許使用「hostPID」、「hostNetwork」 或 「privileged」。

總結

在本文中咱們經過在Rancher環境中啓用一個簡單的Pod安全策略來加強你的Kubernetes安全。經過使用默認的受限PSP，咱們確保pod只能在不須要擴展安全權限的狀況下運行。最後，咱們嘗試部署一個擁有衆多權限的pod，而且失敗了，由於現有的PSP阻止了它被調度到集羣上。

Rancher Kubernetes平臺擁有着超過一億次下載量，咱們深知安全問題對於用戶而言的重要性。後期咱們也將會推出更多與安全相關的內容，幫助Rancher用戶安全、穩妥地落地Kubernetes。