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安全策略的有用組件，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/27818.html
標籤：其他