默認情況下，Kubernetes 允許創建一個有特權容器的 Pod，這些容器很可能會危機系統安全，而 Pod 安全策略pod security policy（PSP）則通過確保請求者有權限按配置來創建 Pod，從而來保護集群免受特權 Pod 的影響。
Admission Controller
Admission Controller（准入控制器）攔截對 kube-apiserver 的請求，攔截發生在請求的對象被持久化之前，但是在請求被驗證和授權之后。這樣我們就可以查看請求對象的來源，並驗證需要的內容是否正確。通過將它們添加到 kube-apiserver 的--enable-admission-plugins參數中來啟用准入控制器。在1.10版本之前，使用現在已經棄用的--admision-control參數，另外需要注意准入控制器的順序很重要。
將PodSecurityPolicy添加到 kube-apiserver 上的--enabled-admission-plugins參數中，然后重啟 kube-apiserver：
--enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,DefaultStorageClass,DefaultTolerationSeconds,MutatingAdmissionWebhook,ValidatingAdmissionWebhook,ResourceQuota,PodSecurityPolicy
其他插件來自 Kubernetes 文檔中推薦的一些插件列表。
PodSecurityPolicy 已經添加到上面的列表中了，現在 PSP 的控制器已經啟用了，但是我們集群中現在缺少一些安全策略，那么新的 Pod 創建就會失敗。
比如現在我們創建一個 Nginx 的 Deployment，YAML 文件內容如下所示：（nginx.yaml）
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deploy
namespace: default
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.15.4
然后直接創建上面的 Deployment：
$ kubectl apply -f nginx.yaml
deployment.apps/nginx-deploy created
我們可以看到 Deployment 已經創建成功了，現在檢查下 default 命名空間下面的 pod、replicaset、deployment：
$ kubectl get po,rs,deploy -l app=nginx
NAME READY STATUS RESTARTS AGE
NAME DESIRED CURRENT READY AGE
replicaset.extensions/nginx-deploy-77f7d4c6b4 1 0 0 40s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.extensions/nginx-deploy 0/1 0 0 40s
可以看到 replicaset 和 deployment 都創建成功了，但是 replicaset 控制器卻並沒有創建 Pod，這個時候就需要使用 ServiceAccount 了。
ServiceAccount Controller Manager
一般來說用戶很少會直接創建 Pod，通常是通過 Deployment、StatefulSet、Job 或者 DasemonSet 這些控制器來創建 Pod 的，我們這里需要配置 kube-controller-manager 來為其包含的每個控制器使用單獨的 ServiceAccount，我們可以通過在其命令啟動參數中添加如下標志來實現：
--use-service-account-credentials=true
一般情況下上面這個標志在大多數安裝工具（如 kubeadm）中都是默認開啟的，所以不需要單獨配置了。
當 kube-controller-manager 開啟上面的標志后，它將使用由 Kubernetes 自動生成的以下 ServiceAccount:
$ kubectl get serviceaccount -n kube-system | egrep -o '[A-Za-z0-9-]+-controller'
attachdetach-controller
calico-kube-controller
certificate-controller
clusterrole-aggregation-controller
cronjob-controller
daemon-set-controller
deployment-controller
disruption-controller
endpoint-controller
expand-controller
job-controller
namespace-controller
node-controller
pv-protection-controller
pvc-protection-controller
replicaset-controller
replication-controller
resourcequota-controller
service-account-controller
service-controller
statefulset-controller
ttl-controller
這些 ServiceAccount 指定了哪個控制器可以解析哪些策略的配置。
策略
PodSecurityPolicy 對象提供了一種聲明式的方式，用於表達我們運行用戶和 ServiceAccount 在我們的集群中創建的內容。我們可以查看策略文檔來了解如何設置。在我們當前示例中，我們將創建2個策略，第一個是提供限制訪問的“默認”策略，保證使用特權設置（例如使用 hostNetwork）無法創建 Pod。第二種是一個“提升”的許可策略，允許將特權設置用於某些 Pod，例如在 kube-system 命名空間下面創建的 Pod 有權限。
首先，創建一個限制性策略，作為默認策略：(psp-restrictive.yaml)
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: restrictive
spec:
privileged: false
hostNetwork: false
allowPrivilegeEscalation: false
defaultAllowPrivilegeEscalation: false
hostPID: false
hostIPC: false
runAsUser:
rule: RunAsAny
fsGroup:
rule: RunAsAny
seLinux:
rule: RunAsAny
supplementalGroups:
rule: RunAsAny
volumes:
- 'configMap'
- 'downwardAPI'
- 'emptyDir'
- 'persistentVolumeClaim'
- 'secret'
- 'projected'
allowedCapabilities:
- '*'
直接創建上面的 psp 對象：
$ kubectl apply -f psp-restrictive.yaml
podsecuritypolicy.policy/restrictive configured
雖然限制性的訪問對於大多數 Pod 創建是足夠的了，但是對於需要提升訪問權限的 Pod 來說，就需要一些允許策略了，例如，kube-proxy 就需要啟用 hostNetwork:
$ kubectl get pods -n kube-system -l k8s-app=kube-proxy
NAME READY STATUS RESTARTS AGE
kube-proxy-4z4vf 1/1 Running 0 18d
$ kubectl get pods -n kube-system kube-proxy-4z4vf -o yaml |grep hostNetwork
hostNetwork: true
這就需要創建一個用於提升創建權限的許可策略了：(psp-permissive.yaml)
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: permissive
spec:
privileged: true
hostNetwork: true
hostIPC: true
hostPID: true
seLinux:
rule: RunAsAny
supplementalGroups:
rule: RunAsAny
runAsUser:
rule: RunAsAny
fsGroup:
rule: RunAsAny
hostPorts:
- min: 0
max: 65535
volumes:
- '*'
同樣直接創建上面的 psp 對象：
$ kubectl apply -f psp-permissive.yaml
podsecuritypolicy.policy/permissive configured
$ kubectl get psp
NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP READONLYROOTFS VOLUMES
permissive true RunAsAny RunAsAny RunAsAny RunAsAny false *
restrictive false * RunAsAny RunAsAny RunAsAny RunAsAny false configMap,downwardAPI,emptyDir,persistentVolumeClaim,secret,projected
現在配置都已經就緒了，但是我們需要引入到 Kubernetes 授權，這樣才可以確定請求 Pod 創建的用戶或者 ServiceAccount 是否解決了限制性或許可性策略，這就需要用到 RBAC 了。
RBAC
在我們啟用 Pod 安全策略的時候，可能會對 RBAC 引起混淆。它確定了一個賬戶可以使用的策略，使用集群范圍的 ClusterRoleBinding 可以為 ServiceAccount（例如 replicaset-controller）提供對限制性策略的訪問權限。使用命名空間范圍的 RoleBinding，可以啟用對許可策略的訪問，這樣可以在特定的命名空間（如 kube-system）中進行操作。
首先創建允許使用restrictive策略的 ClusterRole。然后創建一個 ClusterRoleBinding，將restrictive策略和系統中所有的控制器 ServiceAccount 進行綁定:(psp-restrictive-rbac.yaml)
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: psp-restrictive
rules:
- apiGroups:
- extensions
resources:
- podsecuritypolicies
resourceNames:
- restrictive
verbs:
- use
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: psp-default
subjects:
- kind: Group
name: system:serviceaccounts
namespace: kube-system
roleRef:
kind: ClusterRole
name: psp-restrictive
apiGroup: rbac.authorization.k8s.io
直接創建上面的 RBAC 相關的資源對象：
$ kubectl apply -f psp-restrictive-rbac.yaml
clusterrole.rbac.authorization.k8s.io/psp-restrictive created
clusterrolebinding.rbac.authorization.k8s.io/psp-default created
然后現在我們再重新創建上面我們的定義的 Deployment：
$ kubectl delete -f nginx.yaml
deployment.apps "nginx-deploy" deleted
$ kubectl apply -f nginx.yaml
deployment.apps/nginx-deploy created
創建完成后同樣查看下 default 命名空間下面我們創建的一些資源對象：
$ kubectl get po,rs,deploy -l app=nginx
NAME READY STATUS RESTARTS AGE
pod/nginx-deploy-77f7d4c6b4-njfdl 1/1 Running 0 13s
NAME DESIRED CURRENT READY AGE
replicaset.extensions/nginx-deploy-77f7d4c6b4 1 1 1 13s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.extensions/nginx-deploy 1/1 1 1 13s
我們可以看到 Pods 被成功創建了，但是，如果我們嘗試做一些策略不允許的事情，正常來說就應該被拒絕了。首先刪除上面的這個 Deployment：
$ kubectl delete -f nginx.yaml
deployment.apps "nginx-deploy" deleted
現在我們在 nginx-deploy 基礎上添加hostNetwork: true來使用 hostNetwork 這個特權：（nginx-hostnetwork.yaml）
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-hostnetwork-deploy
namespace: default
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.15.4
hostNetwork: true # 注意添加hostNetwork
然后直接創建上面的 Deployment 這個資源對象：
$ kubectl apply -f nginx-hostnetwork.yaml
deployment.apps/nginx-hostnetwork-deploy created
創建完成后同樣查看 default 這個命名空間下面的一些資源對象：
$ kubectl get po,rs,deploy -l app=nginx
NAME READY STATUS RESTARTS AGE
NAME DESIRED CURRENT READY AGE
replicaset.extensions/nginx-hostnetwork-deploy-74c8fbd687 1 0 0 44s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.extensions/nginx-hostnetwork-deploy 0/1 0 0 44s
現在我們發現 ReplicaSet 又沒有創建 Pod 了，可以使用kubectl describe命令去查看這里我們創建的 ReplicaSet 資源對象來了解更多的信息：
$ kubectl describe rs nginx-hostnetwork-deploy-74c8fbd687
Name: nginx-hostnetwork-deploy-74c8fbd687
......
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedCreate 80s (x15 over 2m42s) replicaset-controller Error creating: pods "nginx-hostnetwork-deploy-74c8fbd687-" is forbidden: unable to validate against any pod security policy: [spec.securityContext.hostNetwork: Invalid value: true: Host network is not allowed to be used]
我們可以看到很明顯 Hostnetwork 不被允許使用，但是在某些情況下，我們的確有在某個命名空間（比如 kube-system）下面創建使用 hostNetwork 的 Pod，這里就需要我們創建一個允許執行的 ClusterRole，然后為特定的命名空間創建一個 RoleBinding，將這里的 ClusterRole 和相關的控制器 ServiceAccount 進行綁定:(psp-permissive-rbac.yaml)
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: psp-permissive
rules:
- apiGroups:
- extensions
resources:
- podsecuritypolicies
resourceNames:
- permissive
verbs:
- use
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
name: psp-permissive
namespace: kube-system
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: psp-permissive
subjects:
- kind: ServiceAccount
name: daemon-set-controller
namespace: kube-system
- kind: ServiceAccount
name: replicaset-controller
namespace: kube-system
- kind: ServiceAccount
name: job-controller
namespace: kube-system
然后直接創建上面的 RBAC 相關的資源對象：
$ kubectl apply -f psp-permissive-rbac.yaml
clusterrole.rbac.authorization.k8s.io/psp-permissive created
rolebinding.rbac.authorization.k8s.io/psp-permissive created
現在，我們就可以在 kube-system 這個命名空間下面使用 hostNetwork 來創建 Pod 了，將上面的 nginx 資源清單更改成 kube-system 命名空間下面：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-hostnetwork-deploy
namespace: kube-system
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.15.4
hostNetwork: true
重新創建這個 Deployment：
$ kubectl apply -f nginx-hostnetwork.yaml
deployment.apps/nginx-hostnetwork-deploy created
創建完成后同樣查看下對應的資源對象創建情況：
$ kubectl get po,rs,deploy -n kube-system -l app=nginx
NAME READY STATUS RESTARTS AGE
pod/nginx-hostnetwork-deploy-74c8fbd687-7x8px 1/1 Running 0 2m1s
NAME DESIRED CURRENT READY AGE
replicaset.extensions/nginx-hostnetwork-deploy-74c8fbd687 1 1 1 2m1s
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.extensions/nginx-hostnetwork-deploy 1/1 1 1 2m1s
現在我們可以看到 Pod 在 kube-system 這個命名空間下面創建成功了。
特定應用的 ServiceAccount
如果我們現在有這樣的一個需求，在某個命名空間下面要強制執行我們創建的 restrictive（限制性）策略，但是這個命名空間下面的某個應用需要使用 permissive（許可）策略，那么應該怎么辦呢？在當前模型中，我們只有集群級別和命名空間級別的解析。為了給某個應用提供單獨的許可策略，我們可以為應用的 ServiceAccount 提供使用 permissive 這個 ClusterRole 的能力。
比如，還是在默認的命名空間下面創建一個名為 specialsa 的 ServiceAccount:
$ kubectl create serviceaccount specialsa
serviceaccount/specialsa created
然后創建一個 RoleBinding 將 specialsa 綁定到上面的 psp-permissive 這個 CluterRole 上:(specialsa-psp.yaml)
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
name: specialsa-psp-permissive
namespace: default
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: psp-permissive
subjects:
- kind: ServiceAccount
name: specialsa
namespace: default
創建上面的 RoleBinding 對象：
$ kubectl apply -f specialsa-psp.yaml
rolebinding.rbac.authorization.k8s.io/specialsa-psp-permissive created
然后為我們上面的 Deployment 添加上 serviceAccount 屬性:(nginx-hostnetwork-sa.yaml)
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-hostnetwork-deploy
namespace: default
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.15.4
hostNetwork: true
serviceAccount: specialsa # 注意這里使用的sa的權限綁定
然后直接創建即可:
$ kubectl apply -f nginx-hostnetwork-sa.yaml
deployment.apps/nginx-hostnetwork-deploy configured
這個時候我們查看 default 這個命名空間下面帶有 hostNetwork 的 Pod 也創建成功了:
$ kubectl get po,rs,deploy -l app=nginx
NAME READY STATUS RESTARTS AGE
pod/nginx-hostnetwork-deploy-6c85dfbf95-hqt8j 1/1 Running 0 65s
NAME DESIRED CURRENT READY AGE
replicaset.extensions/nginx-hostnetwork-deploy-6c85dfbf95 1 1 1 65s
replicaset.extensions/nginx-hostnetwork-deploy-74c8fbd687 0 0 0 31m
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.extensions/nginx-hostnetwork-deploy 1/1 1 1 31m
上面我們描述了 Pod 安全策略是一種通過使用 PSP 授權策略來保護 k8s 集群中的 Pod 的創建過程的方法。
總結
使用PSP安全策略
psp策略定義好之后還需要再創建role，把psp策略綁定到role上，再將role綁定到serviceaccount，再在Pod中使用serviceaccount。
還有幾個必要條件：
1、在apiserver啟動參數 --enable-admission-plugins 中要加上 PodSecurityPolicy 選項，默認是沒有啟用的。
2、在 controller-manager 的啟動參數中開啟 --use-service-account-credentials=true 選項