限制pod使用安全相關的特性
已經介紹了如何在部署 pod時在任一宿主節點上做任何想做 的事。 比如， 部署一個特權模式的 pod 。 很明顯， 需要有一種機制阻止使用者使用其中的部分功能。 叢集管理入員可以通過建立 PodSecurityPolicy資源來限制對以上提到的安全相關的特性的使用。
PodSecurityPolicy資源介紹
PodSecurityPolicy 是一種叢集級别（無命名空間）的資源， 它定義了使用者能否在 pod 中使用各種安全相關的特性。 維護 PodSecurityPolicy 資源中配置政策的工作由內建在 API 伺服器中的 PodSecurityPolicy 準入控制插件完成
當有人向
API
伺服器發送
pod
資源時，
PodSecurityPolicy 準入控制插件會将這個 pod 與已經配置的 PodSecurityPolicy 進行校驗。 如果這個 pod 符合叢集中已有安全政策， 它會被接收并存入 etcd; 否則它會立即被拒絕。 這個插件也會根據安全政策中配置的預設值對 pod 進行修改。
了解 PodSecurityPolicy 可以做的事
一個 PodSecurityPolicy 資源可以定義以下事項：
• 是否允許 pod
使用宿主節點的
PID
、
IPC
、 網絡命名空間
•
pod
允許綁定的宿主節點端口
• 容器運作時允許使用的使用者 ID
• 是否允許擁有特權模式容器的 pod
• 允許添加哪些核心功能， 預設添加哪些核心功能， 總是禁用哪些核心功能
• 允許容器使用哪些 SELinux
選項
• 容器是否允許使用可寫的根檔案系統
• 允許容器在哪些檔案系統組下運作
• 允許 pod
使用哪些類型的存儲卷
檢視一個 PodSecurityPolicy 樣例
以下代碼清單展示了一個 PodSecurityPolicy 的樣例。 它阻止了 pod 使用宿主節點的 PID、 IPC、 網絡命名空間， 運作特權模式的容器， 以及綁定大多數宿主節點的端口（除11 000-11 000和13 000-14 000範圍内的端口）。 它沒有限制容器運作時使用的使用者、使用者組和SELinux 選項。
以上樣例的大部分選項是不言自明的，特别是當你已經閱讀了本章前幾節的内容時。這個PodSecurityPolicy在叢集中建立成功之後，API伺服器将不再允許之前
樣例中的特權pod。例如
$ kubectl create -f pod-privileged.yaml
Error from server (Forbidden): error when crea七ing "pod-privileged.yaml"
pods "pod-privileged" is forbidden: unable to validate agains七 any pod
security policy: [spec.containers[OJ .securityContex七.privileged: 工nvalic
value: true: Privileged containers are not allowed] 類似地，叢集中不能再部署使用宿主節點的PID、IPC、網絡命名空間的pod了。
因為以上政策中的readOnlyRootFilesystem選項己設定為true, 容器的根檔案系統将變為隻讀（容器隻能寫入挂載的存儲卷）。
了解 runAsUser、 fsGroup 和 supplementalGroup 政策
前面的例子中的政策
沒有對容器運作時可以使用的使用者和使用者組施加任何限制
，因為它們在runAsUser、fsGroup、supplementalGroups等字段中使用
了runA
sAny規則。
如果需要限制容器可以使用的使用者和使用者組ID,
可以将規則改為MustRunAs
, 并指定允許使用的ID範圍。
使用MustRunAs規則
來看以下的例子。為了隻允許容器以使用者ID 2的身份運作并限制預設的檔案系統組和增補組ID在2-10或20-30的範圍（包含臨界值）内，需要在PodSecurityPolicy資源中加入如以下代碼清單所示片段。
如果pod spec試圖将其中的任一字段設定為該範圍之外的值，這個pod将不會被API服務
器接收。可以通過删除之前的PodSecurityContextPolicy, 并通過psp-must-run-as.yam!
檔案建立一個新的來實踐這一點。
注意 修改政策對已經存在的pod無效，因為PodSecurityPolicy資原僅在建立和更新po d
時起作用
。
部署runAsUser在指定範圍之外的pod
如果嘗試使用之前的pod-as-user-guest.yaml 檔案部署一 個pod, 其中指定了容器運作的使用者ID為405, API伺服器會拒絕這個pod:
$ kubectl create -f pod -as - user-guest. yaml
Error from server (Forbidden): error when creating "pod-as-user-guest . yaml"
pods pod-as user-guest" is forb dden: able to validate against pod
secur ty poli cy : [securityContext runAsUser: Inval value 405 UID on
cont 工口er main does ot match required ra ge Found 405, allowed : [(2 2)] J 好，這個是顯然的。但是如果部署 pod
時沒
有指定 ruAs
User
屬性，但使用者
ID
被注入到鏡像的情況下（在
Docke
le
中使用
USER
指令），會發生什麼？
部署鏡像中使用者 ID 在指定範圍之外的 pod
筆者建立了 個不同版本的
Node.js
鏡像，在
全書
的例子中使用
。這
個鏡像被
配置為使用使用者
ID為5的使用者運作。該鏡像使用的 Dockerfi
le
以下代碼清單所示。
筆者将這個鏡像命名為 uk sa/kubia-
run-
as-
user ，
上傳到
Docker
Hub 。如果使用這個鏡像建立 pod, API 伺服器不
會拒絕
$ kubectl run run-as-5 --image luksa/kubia-run-as-user-5 --restart Never
pod ” r un as-5 ’I created 與之前不同， API
伺服器
接收了這
pod,
kubelet
也運作了這個容器。接下來檢視這 容器使用的使用者
ID 和使用者組 ID:
$ kubectl exec run-as-5 -- id
uid=2(bin) gid=2(bin） groups=2(bin) 可以 看到，這個容器運作時使用的使用者
ID 為2，就是在 Po
dSecurit
yP
olicy
中指定的
ID PodSecurityPolicy
可以
将寫死覆寫到鏡像中的使用者
ID。