實例演示：如何簡化生產中的Pod安全策略？

Pod安全策略對於強化K8S集羣安全相當重要。本文將延續以前的文章繼續深刻介紹Pod安全策略。

首先，簡單介紹瞭如何將Pod與Pod安全策略相關聯，並使用RBAC來展現具體步驟。而後介紹如何在Rancher中啓用默認的PSP和建立自定義PSP。最後將使用一種工具來簡化生產中Pod安全策略的使用，極大提高生產力，趕忙戳文咯~

---

本文來自RancherLabs

在以前的文章中，咱們演示瞭如何使用受限的PSP策略做爲默認值在Rancher中啓用PSP。咱們還展現瞭如何防止特權Pod被接納到集羣中。

咱們有意省略了有關基於角色的訪問控制（RBAC）以及如何將Pod與特定PSP鏈接的具體細節。那麼，這篇文章讓咱們繼續深刻研究PSP。

將Pod與Pod 安全策略匹配

你可能已經注意到，PSP模式沒有與任何Kubernetes命名空間、Service Account或Pod相關聯。實際上，PSP是集羣範圍的資源。那麼，咱們如何指定哪些Pod應該由哪些PSP來管理呢？下圖顯示了全部參與組件、資源以及准入流程的工做方式。

也許一開始聽起來很複雜。如今，咱們來詳細介紹一下。

部署Pod時，准入控制將根據請求deployment的對象來應用策略。

Pod自己沒有任何關聯的策略——執行該Deployment的是service account。在上圖中，Jorge使用webapp-sa service account部署了pod。

RoleBinding將service account與Roles（或ClusterRoles）相關聯，Role是指定可使用PSP的資源。在該圖中，webapp-sa與webapp-role關聯，後者爲特定的PSP資源提供使用許可。部署Pod時，將根據webapp-sa PSP對Pod進行檢查。實際上，一個service account可使用多個PSP，而且其中一個能夠驗證Pod就足夠了。你能夠在官方文檔中查看詳細信息：

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

而後，准入控制將決定Pod是否符合其中任何一個PSP。若是Pod符合要求，准入控制將調度Pod；若是Pod不符合規定，則會阻止部署。

以上內容能夠總結爲如下幾點：

• Pod身份由其service account肯定

• 若是規範中未聲明任何service account，則將使用默認帳戶

• 你須要容許使用聲明Role或ClusterRole

最後，須要有一個RoleBinding，它將Role（從而容許訪問使用PSP）與Pod規範中聲明的Servcie Account相關聯。

讓咱們用一些例子來講明。

RBAC的真實示例

假設你已經有一個啓用了PSP的集羣，這是採用PSP建立限制性PSP的經常使用方法，該PSP能夠被任意Pod使用。而後你將添加更爲特定的PSP，該PSP有綁定到特定service account的其餘特權。擁有默認、安全且嚴格的策略有助於集羣的管理，由於大多數Pod不須要特殊的特權或功能，而且在默認狀況下便可運行。而後，若是你的某些工做負載須要其餘特權，咱們能夠建立一個自定義PSP並將該工做負載的特定service account綁定到限制較少的PSP。

可是，如何將Pod綁定到特定的PSP而不是默認的受限PSP？以及如何使用不自動添加RoleBindings的普通Kubernetes集羣來作到這一點？

讓咱們看一個完整的示例，在該示例中，咱們定義一些安全的默認值（集羣中任何service account均可以使用的受限PSP），而後爲須要該服務的特定deployment向單個service account提供其餘特權。

首先，咱們手動建立一個新的命名空間。它不會由Rancher管理，因此不會自動建立RoleBindings。而後咱們在該命名空間中嘗試部署一個受限的Pod：

$ kubectl create ns psp-test
$ cat 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
$ kubectl -n psp-test apply -f deploy-not-privileged.yaml
$ kubectl -n psp-test describe rs
...
  Warning  FailedCreate  4s (x12 over 15s)  replicaset-controller  Error creating: pods "not-privileged-deploy-684696d5b5-" is forbidden: unable to validate against any pod security policy: []

因爲命名空間psp-test中沒有RoleBinding，且該命名空間綁定到容許使用任何PSP的角色，所以沒法建立pod。咱們將經過建立集羣範圍的ClusterRole和ClusterRoleBinding來解決此問題，以容許任何Service Account默認使用受限的PSP。以前的文章中啓用PSP時，Rancher建立了受限PSP。

resourceNames:
  - restricted-psp
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: restricted-role-bind
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: use-restricted-psp
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:serviceaccounts
$ kubectl apply -f clusterrole-use-restricted.yaml

咱們應用這些更改以後，非特權deployment應正常工做。

可是，若是咱們須要部署特權Pod，則不會被現有策略容許：

$ cat deploy-privileged.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: privileged-sa
  namespace: psp-test
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: privileged-deploy
  name: privileged-deploy
  namespace: psp-test
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
      serviceAccountName: privileged-sa

$ kubectl -n psp-test apply -f deploy-privileged.yaml
$ kubectl -n psp-test describe rs privileged-deploy-7569b9969d
Name:           privileged-deploy-7569b9969d
Namespace:      default
Selector:       app=privileged-deploy,pod-template-hash=7569b9969d
Labels:         app=privileged-deploy
...
Events:
  Type     Reason        Age                From                   Message
  ----     ------        ----               ----                   -------
  Warning  FailedCreate  4s (x14 over 45s)  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]

在這種狀況下，因爲咱們建立了ClusterRoleBinding，因此Pod可使用PSP，可是restricted-psp不會驗證Pod，由於它須要privileged 、hostNetwork等參數。

咱們已經在前文中看到了restricted-psp策略。讓咱們檢查一下default-psp的細節，這是由Rancher在啓用PSP容許這些特權時建立的：

$ kubectl get psp default-psp -o yaml

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  annotations:
    seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
  creationTimestamp: "2020-03-10T08:45:08Z"
  name: default-psp
  resourceVersion: "144774"
  selfLink: /apis/policy/v1beta1/podsecuritypolicies/default-psp
  uid: 1f83b803-bbee-483c-8f66-bfa65feaef56
spec:
  allowPrivilegeEscalation: true
  allowedCapabilities:
  - '*'
  fsGroup:
    rule: RunAsAny
  hostIPC: true
  hostNetwork: true
  hostPID: true
  hostPorts:
  - max: 65535
    min: 0
  privileged: true
  runAsUser:
    rule: RunAsAny
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  volumes:
  - '*'

你能夠看到這是一個很是寬鬆的策略，特別是咱們容許privileged、hostNetwork、hostPID、hostIPC、hostPorts以及以root身份運行以及其餘功能。

咱們只須要明確容許該Pod使用PSP。咱們經過建立相似於現有restricted-clusterrole的ClusterRole，但容許使用default-psp資源，而後爲咱們的psp-test 命名空間建立RoleBinding來將privileged-sa ServiceAccount綁定到該ClusterRole：

$ cat clusterrole-use-privileged.yaml
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: use-privileged-psp
rules:
- apiGroups: ['policy']
  resources: ['podsecuritypolicies']
  verbs:     ['use']
  resourceNames:
  - default-psp
---
  apiVersion: rbac.authorization.k8s.io/v1
  kind: RoleBinding
  metadata:
    name: privileged-role-bind
    namespace: psp-test
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: use-privileged-psp
  subjects:
  - kind: ServiceAccount
    name: privileged-sa
$ kubectl -n psp-test apply -f clusterrole-use-privileged.yaml

一下子以後，特權Pod將會被建立。而後你會注意到restricted-psp和default-psp如今已經能夠直接使用。接下來，咱們來詳細介紹一下它們。

在Rancher上默認的PSP

在Rancher中經過編輯集羣設置來啓用PSP准入控制，並選擇其中一個已經定義好的PSP做爲默認選項：

Rancher將在集羣中建立一對PSP資源：

• restricted-psp：若是你選擇「受限（restricted）」做爲默認的PSP

• default-psp：默認的PSP，容許建立特權Pod。

除了restricted-psp和default-psp，Rancher還會建立名爲 restricted-clusterrole的ClusterRole：

annotations:
    serviceaccount.cluster.cattle.io/pod-security: restricted
  creationTimestamp: "2020-03-10T08:44:39Z"
  labels:
    cattle.io/creator: norman
  name: restricted-clusterrole
rules:
- apiGroups:
  - extensions
  resourceNames:
  - restricted-psp
  resources:
  - podsecuritypolicies
  verbs:
  - use

此ClusterRole容許使用restricted-psp策略。那麼Binding在何處才能夠容許受權使用pod ServiceAccount 呢？

對於屬於Rancher中項目的命名空間，它還在其中爲你設置RoleBinding配置：

$ kubectl -n default get rolebinding default-default-default-restricted-clusterrole-binding -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  annotations:
    podsecuritypolicy.rbac.user.cattle.io/psptpb-role-binding: "true"
    serviceaccount.cluster.cattle.io/pod-security: restricted
  labels:
    cattle.io/creator: norman
  name: default-default-default-restricted-clusterrole-binding
  namespace: default
...
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: restricted-clusterrole
subjects:
- kind: ServiceAccount
  name: default
  namespace: default

資源名稱（default-default-default-restricted-clusterrole-binding）可能會使人感到困惑，實際上它的構成爲：

default-serviceaccountname-namespace-restricted-clusterrole-binding

而且若是你建立一個相似myserviceaccount的新的service account，那麼將會自動建立一個新的角色綁定：

$ kubectl create sa myserviceaccount
serviceaccount/myserviceaccount created
$ kubectl get rolebinding
NAME                                                              AGE
---
default-default-default-restricted-clusterrole-binding            13m
default-myserviceaccount-default-restricted-clusterrole-binding   4s

藉助這種神奇的功能，你無需爲不須要任何提高特權的安全pod配置RBAC。

在Rancher中建立你的PSP

PSP是一個標準的Kubernetes資源，全程是Pod安全策略，因此你能夠經過Kubernetes API或kubectl CLI來使用它。

你能夠經過在YAML文件中定義它們來建立你的自定義PSP，而後使用kubectl在集羣中建立資源。查看官方文檔便可瞭解全部可用控件（https://kubernetes.io/docs/concepts/policy/pod-security-policy/ ）。在YAML中定義了控件集以後，你能夠運行：

$ kubectl create psp my-custom-psp

以建立PSP資源。

使用Rancher，你能夠從UI中直接查看或添加新的策略：

PSP十分強大，但也十分複雜

配置Pod安全策略是一個十分乏味的過程。你在Kubernetes集羣中啓用PSP以後，你想要部署的任意Pod都必須經由其中一個PSP容許。實施強大的安全策略可能十分耗時，並且爲每一個應用程序的每一個deployment生成一個策略也是一種負擔。若是你的策略十分寬鬆，那麼不強制執行最小特權訪問方法；然而，若是它存在不少限制，你可能會破壞你的應用程序，由於Pod沒法在Kubernetes中成功運行。

可以以最少的訪問要求集自動生成Pod安全策略，將幫助你更輕鬆地安裝PSP。而且你不能只在生產環境中部署它們，而不驗證你的應用程序是否能夠正常工做，並且進行手動測試既繁瑣又效率低下。若是你能夠針對Kubernetes工做負載的運行時行爲驗證PSP呢？

如何簡化生產環境中PSP的使用？

Kubernetes Pod安全策略 Advisor（又名kube-psp-advisor）是一個Sysdig的開源工具。kube-psp-advisor會從Kubernetes資源（如deployment、daemonset、replicaset等）中掃描現有的安全上下文，將其做爲咱們想要執行的reference模型，而後在整個集羣中爲全部資源自動生成Pod安全策略。kube-psp-advisor經過查看不一樣的屬性以建立推薦的Pod安全策略：

• allowPrivilegeEscalation

• allowedCapabilities

• allowedHostPaths

• hostIPC

• hostNetwork

• hostPID

• Privileged

• readOnlyRootFilesystem

• runAsUser

• Volume

查看kube-psp-advisor教程，以獲取有關其工做原理的更多詳細信息：

https://sysdig.com/blog/enable-kubernetes-pod-security-policy/

使用Sysdig Secure自動生成PSP

Sysdig Secure Kubernetes Policy Advisor能夠幫助用戶建立和驗證Pod安全策略。

第一步是設置新的PSP模擬環境。你能夠針對不一樣範圍內的不一樣策略（例如Kubernetes命名空間）進行多種模擬。

Sysdig在你的Deployment定義中分析Pod規範的要求，併爲你的應用程序建立權限最小的PSP。這能夠控制是否容許特權Pod，用戶將其做爲容器、volume等運行。Ni 能夠微調PSP並針對你將要運行的模擬環境定義命名空間：

左側的策略會破壞應用程序，由於nginx Deployment是特權Pod，而且具備主機網絡訪問權限。你必須決定是擴大PSP以容許這種行爲，仍是選擇減小Deployment的特權以適應該策略。不管如何，你在應用PSP以前都會檢測到此狀況，這會阻止Pod運行並在應用程序部署上形成破壞。

結 論

如這些示例所示，經過授予或拒絕對特定資源的訪問，PSP使你能夠對在Kubernetes中運行的Pod和容器進行精細控制。這些策略相對來講容易建立和部署，而且應該是任何Kubernetes安全策略的有用組件。