如何簡(jiǎn)化生產(chǎn)中的Pod安全策略

如何簡(jiǎn)化生產(chǎn)中的Pod安全策略，針對(duì)這個(gè)問(wèn)題，這篇文章詳細(xì)介紹了相對(duì)應(yīng)的分析和解答，希望可以幫助更多想解決這個(gè)問(wèn)題的小伙伴找到更簡(jiǎn)單易行的方法。

涇源網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)！從網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開(kāi)發(fā)、APP開(kāi)發(fā)、自適應(yīng)網(wǎng)站建設(shè)等網(wǎng)站項(xiàng)目制作，到程序開(kāi)發(fā)，運(yùn)營(yíng)維護(hù)。創(chuàng)新互聯(lián)2013年至今到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來(lái)保證我們的工作的順利進(jìn)行。專(zhuān)注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)。

Pod安全策略對(duì)于強(qiáng)化K8S集群安全至關(guān)重要。本文將延續(xù)之前的文章繼續(xù)深入介紹Pod安全策略。

首先，簡(jiǎn)單介紹了如何將Pod與Pod安全策略相關(guān)聯(lián)，并使用RBAC來(lái)展示具體步驟。然后介紹如何在Rancher中啟用默認(rèn)的PSP和創(chuàng)建自定義PSP。最后將使用一種工具來(lái)簡(jiǎn)化生產(chǎn)中Pod安全策略的使用，極大提升生產(chǎn)力，趕緊戳文咯~

我們有意省略了有關(guān)基于角色的訪問(wèn)控制（RBAC）以及如何將Pod與特定PSP連接的具體細(xì)節(jié)。那下面讓我們繼續(xù)深入研究PSP。

將Pod與Pod 安全策略匹配

你可能已經(jīng)注意到，PSP模式?jīng)]有與任何Kubernetes命名空間、Service Account或Pod相關(guān)聯(lián)。實(shí)際上，PSP是集群范圍的資源。那么，我們?nèi)绾沃付男㏄od應(yīng)該由哪些PSP來(lái)管理呢？下圖顯示了所有參與組件、資源以及準(zhǔn)入流程的工作方式。

也許一開(kāi)始聽(tīng)起來(lái)很復(fù)雜?，F(xiàn)在，我們來(lái)詳細(xì)介紹一下。

部署Pod時(shí)，準(zhǔn)入控制將根據(jù)請(qǐng)求deployment的對(duì)象來(lái)應(yīng)用策略。

Pod本身沒(méi)有任何關(guān)聯(lián)的策略——執(zhí)行該Deployment的是service account。在上圖中，Jorge使用webapp-sa service account部署了pod。

RoleBinding將service account與Roles（或ClusterRoles）相關(guān)聯(lián)，Role是指定可以使用PSP的資源。在該圖中，webapp-sa與webapp-role關(guān)聯(lián)，后者為特定的PSP資源提供使用許可。部署Pod時(shí)，將根據(jù)webapp-sa PSP對(duì)Pod進(jìn)行檢查。實(shí)際上，一個(gè)service account可以使用多個(gè)PSP，并且其中一個(gè)可以驗(yàn)證Pod就足夠了。你可以在官方文檔中查看詳細(xì)信息：

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

然后，準(zhǔn)入控制將決定Pod是否符合其中任何一個(gè)PSP。如果Pod符合要求，準(zhǔn)入控制將調(diào)度Pod；如果Pod不符合規(guī)定，則會(huì)阻止部署。

以上內(nèi)容可以總結(jié)為以下幾點(diǎn)：

• Pod身份由其service account確定

• 如果規(guī)范中未聲明任何service account，則將使用默認(rèn)賬戶(hù)

• 你需要允許使用聲明Role或ClusterRole

最后，需要有一個(gè)RoleBinding，它將Role（從而允許訪問(wèn)使用PSP）與Pod規(guī)范中聲明的Servcie Account相關(guān)聯(lián)。

讓我們用一些例子來(lái)說(shuō)明。

RBAC的真實(shí)示例

假設(shè)你已經(jīng)有一個(gè)啟用了PSP的集群，這是采用PSP創(chuàng)建限制性PSP的常用方法，該P(yáng)SP可以被任意Pod使用。然后你將添加更為特定的PSP，該P(yáng)SP有綁定到特定service account的其他特權(quán)。擁有默認(rèn)、安全且嚴(yán)格的策略有助于集群的管理，因?yàn)榇蠖鄶?shù)Pod不需要特殊的特權(quán)或功能，并且在默認(rèn)情況下即可運(yùn)行。然后，如果你的某些工作負(fù)載需要其他特權(quán)，我們可以創(chuàng)建一個(gè)自定義PSP并將該工作負(fù)載的特定service account綁定到限制較少的PSP。

但是，如何將Pod綁定到特定的PSP而不是默認(rèn)的受限PSP？以及如何使用不自動(dòng)添加RoleBindings的普通Kubernetes集群來(lái)做到這一點(diǎn)？

讓我們看一個(gè)完整的示例，在該示例中，我們定義一些安全的默認(rèn)值（集群中任何service account都可以使用的受限PSP），然后為需要該服務(wù)的特定deployment向單個(gè)service account提供其他特權(quán)。

首先，我們手動(dòng)創(chuàng)建一個(gè)新的命名空間。它不會(huì)由Rancher管理，所以不會(huì)自動(dòng)創(chuàng)建RoleBindings。然后我們?cè)谠撁臻g中嘗試部署一個(gè)受限的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中沒(méi)有RoleBinding，且該命名空間綁定到允許使用任何PSP的角色，因此無(wú)法創(chuàng)建pod。我們將通過(guò)創(chuàng)建集群范圍的ClusterRole和ClusterRoleBinding來(lái)解決此問(wèn)題，以允許任何Service Account默認(rèn)使用受限的PSP。之前的文章中啟用PSP時(shí)，Rancher創(chuàng)建了受限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

我們應(yīng)用這些更改之后，非特權(quán)deployment應(yīng)正常工作。

但是，如果我們需要部署特權(quán)Pod，則不會(huì)被現(xiàn)有策略允許：

$ 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]

在這種情況下，由于我們創(chuàng)建了ClusterRoleBinding，所以Pod可以使用PSP，但是restricted-psp不會(huì)驗(yàn)證Pod，因?yàn)樗枰猵rivileged 、hostNetwork等參數(shù)。

我們已經(jīng)在前文中看到了restricted-psp策略。讓我們檢查一下default-psp的細(xì)節(jié)，這是由Rancher在啟用PSP允許這些特權(quán)時(shí)創(chuàng)建的：

$ 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:
  - '*'

你可以看到這是一個(gè)非常寬松的策略，特別是我們?cè)试Sprivileged、hostNetwork、hostPID、hostIPC、hostPorts以及以root身份運(yùn)行以及其他功能。

我們只需要明確允許該P(yáng)od使用PSP。我們通過(guò)創(chuàng)建類(lèi)似于現(xiàn)有restricted-clusterrole的ClusterRole，但允許使用default-psp資源，然后為我們的psp-test 命名空間創(chuàng)建RoleBinding來(lái)將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

一會(huì)兒之后，特權(quán)Pod將會(huì)被創(chuàng)建。然后你會(huì)注意到restricted-psp和default-psp現(xiàn)在已經(jīng)可以直接使用。接下來(lái)，我們來(lái)詳細(xì)介紹一下它們。

在Rancher上默認(rèn)的PSP

在Rancher中通過(guò)編輯集群設(shè)置來(lái)啟用PSP準(zhǔn)入控制，并選擇其中一個(gè)已經(jīng)定義好的PSP作為默認(rèn)選項(xiàng)：

Rancher將在集群中創(chuàng)建一對(duì)PSP資源：

• restricted-psp：如果你選擇“受限（restricted）”作為默認(rèn)的PSP

• default-psp：默認(rèn)的PSP，允許創(chuàng)建特權(quán)Pod。

除了restricted-psp和default-psp，Rancher還會(huì)創(chuàng)建名為 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在何處才可以允許授權(quán)使用pod ServiceAccount 呢？

對(duì)于屬于Rancher中項(xiàng)目的命名空間，它還在其中為你設(shè)置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

資源名稱(chēng)（default-default-default-restricted-clusterrole-binding）可能會(huì)令人感到困惑，實(shí)際上它的構(gòu)成為：

default-serviceaccountname-namespace-restricted-clusterrole-binding

并且如果你創(chuàng)建一個(gè)類(lèi)似myserviceaccount的新的service account，那么將會(huì)自動(dòng)創(chuàng)建一個(gè)新的角色綁定：

$ 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

借助這種神奇的功能，你無(wú)需為不需要任何提升特權(quán)的安全pod配置RBAC。

在Rancher中創(chuàng)建你的PSP

PSP是一個(gè)標(biāo)準(zhǔn)的Kubernetes資源，全程是Pod安全策略，所以你可以通過(guò)Kubernetes API或kubectl CLI來(lái)使用它。

你可以通過(guò)在YAML文件中定義它們來(lái)創(chuàng)建你的自定義PSP，然后使用kubectl在集群中創(chuàng)建資源。查看官方文檔即可了解所有可用控件（https://kubernetes.io/docs/concepts/policy/pod-security-policy/ ）。在YAML中定義了控件集之后，你可以運(yùn)行：

$ kubectl create psp my-custom-psp

以創(chuàng)建PSP資源。

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

PSP十分強(qiáng)大，但也十分復(fù)雜

配置Pod安全策略是一個(gè)十分乏味的過(guò)程。你在Kubernetes集群中啟用PSP之后，你想要部署的任意Pod都必須經(jīng)由其中一個(gè)PSP允許。實(shí)施強(qiáng)大的安全策略可能十分耗時(shí)，而且為每個(gè)應(yīng)用程序的每個(gè)deployment生成一個(gè)策略也是一種負(fù)擔(dān)。如果你的策略十分寬松，那么不強(qiáng)制執(zhí)行最小特權(quán)訪問(wèn)方法；然而，如果它存在很多限制，你可能會(huì)破壞你的應(yīng)用程序，因?yàn)镻od無(wú)法在Kubernetes中成功運(yùn)行。

能夠以最少的訪問(wèn)要求集自動(dòng)生成Pod安全策略，將幫助你更輕松地安裝PSP。并且你不能只在生產(chǎn)環(huán)境中部署它們，而不驗(yàn)證你的應(yīng)用程序是否可以正常工作，而且進(jìn)行手動(dòng)測(cè)試既繁瑣又效率低下。如果你可以針對(duì)Kubernetes工作負(fù)載的運(yùn)行時(shí)行為驗(yàn)證PSP呢？

如何簡(jiǎn)化生產(chǎn)環(huán)境中PSP的使用？

Kubernetes Pod安全策略 Advisor（又名kube-psp-advisor）是一個(gè)Sysdig的開(kāi)源工具。kube-psp-advisor會(huì)從Kubernetes資源（如deployment、daemonset、replicaset等）中掃描現(xiàn)有的安全上下文，將其作為我們想要執(zhí)行的reference模型，然后在整個(gè)集群中為所有資源自動(dòng)生成Pod安全策略。kube-psp-advisor通過(guò)查看不同的屬性以創(chuàng)建推薦的Pod安全策略：

• allowPrivilegeEscalation

• allowedCapabilities

• allowedHostPaths

• hostIPC

• hostNetwork

• hostPID

• Privileged

• readOnlyRootFilesystem

• runAsUser

• Volume

查看kube-psp-advisor教程，以獲取有關(guān)其工作原理的更多詳細(xì)信息：

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

使用Sysdig Secure自動(dòng)生成PSP

Sysdig Secure Kubernetes Policy Advisor可以幫助用戶(hù)創(chuàng)建和驗(yàn)證Pod安全策略。

第一步是設(shè)置新的PSP模擬環(huán)境。你可以針對(duì)不同范圍內(nèi)的不同策略（例如Kubernetes命名空間）進(jìn)行多種模擬。

Sysdig在你的Deployment定義中分析Pod規(guī)范的要求，并為你的應(yīng)用程序創(chuàng)建權(quán)限最小的PSP。這可以控制是否允許特權(quán)Pod，用戶(hù)將其作為容器、volume等運(yùn)行。Ni 可以微調(diào)PSP并針對(duì)你將要運(yùn)行的模擬環(huán)境定義命名空間：

左側(cè)的策略會(huì)破壞應(yīng)用程序，因?yàn)閚ginx Deployment是特權(quán)Pod，并且具有主機(jī)網(wǎng)絡(luò)訪問(wèn)權(quán)限。你必須決定是擴(kuò)大PSP以允許這種行為，還是選擇減少Deployment的特權(quán)以適應(yīng)該策略。無(wú)論如何，你在應(yīng)用PSP之前都會(huì)檢測(cè)到此情況，這會(huì)阻止Pod運(yùn)行并在應(yīng)用程序部署上造成破壞。通過(guò)授予或拒絕對(duì)特定資源的訪問(wèn)，PSP使你可以對(duì)在Kubernetes中運(yùn)行的Pod和容器進(jìn)行精細(xì)控制。這些策略相對(duì)來(lái)說(shuō)容易創(chuàng)建和部署，并且應(yīng)該是任何Kubernetes安全策略的有用組件。

關(guān)于如何簡(jiǎn)化生產(chǎn)中的Pod安全策略問(wèn)題的解答就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，如果你還有很多疑惑沒(méi)有解開(kāi)，可以關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道了解更多相關(guān)知識(shí)。

網(wǎng)站欄目：如何簡(jiǎn)化生產(chǎn)中的Pod安全策略
文章鏈接：http://www.muchs.cn/article36/jdospg.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)頁(yè)設(shè)計(jì)公司、ChatGPT、、商城網(wǎng)站、外貿(mào)網(wǎng)站建設(shè)、靜態(tài)網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶(hù)投稿、用戶(hù)轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話(huà)：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)