建站
咨詢
售后
建站咨詢
新聞中心
Pod 安全性準(zhǔn)入
FEATURE STATE: Kubernetes v1.23 [beta]
Kubernetes Pod 安全性標(biāo)準(zhǔn)（Security Standards） 為 Pod 定義不同的隔離級別。這些標(biāo)準(zhǔn)能夠讓你以一種清晰、一致的方式定義如何限制 Pod 行為。
作為一項 Beta 功能特性，Kubernetes 提供一種內(nèi)置的 Pod 安全性 準(zhǔn)入控制器， 作為 PodSecurityPolicies 特性的后繼演化版本。Pod 安全性限制是在 Pod 被創(chuàng)建時在 名字空間層面實施的。
Note:
PodSecurityPolicy API 已經(jīng)被廢棄，會在 Kubernetes v1.25 發(fā)行版中 移除。
啟用 PodSecurity 準(zhǔn)入插件
在 v1.23 中，?PodSecurity ?特性門控 是一項 Beta 功能特性，默認(rèn)被啟用。
在 v1.22 中，?PodSecurity ?特性門控 是一項 Alpha 功能特性，必須在 ?kube-apiserver? 上啟用才能使用內(nèi)置的準(zhǔn)入插件。
--feature-gates="...,PodSecurity=true"
替代方案：安裝 PodSecurity 準(zhǔn)入 Webhook
對于無法應(yīng)用內(nèi)置 ?PodSecurity ?準(zhǔn)入插件的環(huán)境，無論是因為集群版本低于 v1.22， 或者 ?PodSecurity ?特性無法被啟用，都可以使用 Beta 版本的 驗證性準(zhǔn)入 Webhook。 來使用 ?PodSecurity ?準(zhǔn)入邏輯。
在 https://git.K8S.io/pod-security-admission/webhook 上可以找到一個預(yù)先構(gòu)建的容器鏡像、證書生成腳本以及一些示例性質(zhì)的清單。
git clone git@github.com:kubernetes/pod-security-admission.git
cd pod-security-admission/webhook
make certs
kubectl apply -k .Note:
所生成的證書合法期限為 2 年。在證書過期之前， 需要重新生成證書或者去掉 Webhook 以使用內(nèi)置的準(zhǔn)入查件。
Pod 安全性級別
Pod 安全性準(zhǔn)入插件對 Pod 的安全性上下文 有一定的要求，并且依據(jù) Pod 安全性標(biāo)準(zhǔn) 所定義的三個級別（?privileged?、?baseline ?和 ?restricted?）對其他字段也有要求。
為名字空間設(shè)置 Pod 安全性準(zhǔn)入控制標(biāo)簽
一旦特性被啟用或者安裝了 Webhook，你可以配置名字空間以定義每個名字空間中 Pod 安全性準(zhǔn)入控制模式。 Kubernetes 定義了一組標(biāo)簽， 你可以設(shè)置這些標(biāo)簽來定義某個名字空間上要使用的預(yù)定義的 Pod 安全性標(biāo)準(zhǔn)級別。 你所選擇的標(biāo)簽定義了檢測到潛在違例時，控制面 要采取什么樣的動作。
| 模式 | 描述 |
|---|---|
| enforce | 策略違例會導(dǎo)致 Pod 被拒絕 |
| audit | 策略違例會觸發(fā)審計日志中記錄新事件時添加審計注解；但是 Pod 仍是被接受的。 |
| warn | 策略違例會觸發(fā)用戶可見的警告信息，但是 Pod 仍是被接受的。 |
名字空間可以配置任何一種或者所有模式，或者甚至為不同的模式設(shè)置不同的級別。
對于每種模式，決定所使用策略的標(biāo)簽有兩個：
# 針對模式的級別標(biāo)簽用來標(biāo)示針對該模式所應(yīng)用的策略級別
#
# MODE 必須是 `enforce`、`audit` 或 `warn` 之一
# LEVEL 必須是 `privileged`、baseline` 或 `restricted` 之一
pod-security.kubernetes.io/:
# 可選：針對每個模式版本的版本標(biāo)簽可以將策略鎖定到
# 給定 Kubernetes 小版本號所附帶的版本（例如 v1.24）
#
# MODE 必須是 `enforce`、`audit` 或 `warn` 之一
# VERSION 必須是一個合法的 Kubernetes 小版本號或者 `latest`
pod-security.kubernetes.io/-version: 負(fù)載資源和 Pod 模板
Pod 通常是通過創(chuàng)建 Deployment 或 Job 這類工作負(fù)載對象 來間接創(chuàng)建的。工作負(fù)載對象為工作負(fù)載資源定義一個 Pod 模板 和一個對應(yīng)的 負(fù)責(zé)基于該模板來創(chuàng)建 Pod 的控制器。 為了盡早地捕獲違例狀況，?audit ?和 ?warn ?模式都應(yīng)用到負(fù)載資源。 不過，?enforce ?模式并 不 應(yīng)用到工作負(fù)載資源，僅應(yīng)用到所生成的 Pod 對象上。
豁免
你可以為 Pod 安全性的實施設(shè)置 豁免（Exemptions） 規(guī)則， 從而允許創(chuàng)建一些本來會被與給定名字空間相關(guān)的策略所禁止的 Pod。 豁免規(guī)則可以在準(zhǔn)入控制器配置 中靜態(tài)配置。
豁免規(guī)則可以顯式枚舉。滿足豁免標(biāo)準(zhǔn)的請求會被準(zhǔn)入控制器 忽略 （所有 ?enforce?、?audit ?和 ?warn ?行為都會被略過）。 豁免的維度包括：
- ?
Username?： 來自用戶名已被豁免的、已認(rèn)證的（或偽裝的）的用戶的請求會被忽略。 - ?
RuntimeClassName?： 指定了已豁免的運行時類名稱的 Pod 和負(fù)載資源會被忽略。 - ?
Namespace?： 位于被豁免的名字空間中的 Pod 和負(fù)載資源 會被忽略。
Caution:
大多數(shù) Pod 是作為對工作負(fù)載資源的響應(yīng)， 由控制器所創(chuàng)建的，這意味著為某最終用戶提供豁免時，只會當(dāng)該用戶直接創(chuàng)建 Pod 時對其實施安全策略的豁免。用戶創(chuàng)建工作負(fù)載資源時不會被豁免。 控制器服務(wù)賬號（例如：?
system:serviceaccount:kube-system:replicaset-controller?） 通常不應(yīng)該被豁免，因為豁免這類服務(wù)賬號隱含著對所有能夠創(chuàng)建對應(yīng)工作負(fù)載資源的用戶豁免。
策略檢查時會對以下 Pod 字段的更新操作予以豁免，這意味著如果 Pod 更新請求僅改變這些字段時，即使 Pod 違反了當(dāng)前的策略級別，請求也不會被拒絕。
- 除了對 seccomp 或 AppArmor 注解之外的所有 meatadata 更新操作：
- ?
seccomp.security.alpha.kubernetes.io/pod? （已棄用） - ?
container.seccomp.security.alpha.kubernetes.io/*?（已棄用） - ?
container.apparmor.security.beta.kubernetes.io/*? - 對 ?
.spec.activeDeadlineSeconds? 的合法更新 - 對 ?
.spec.tolerations? 的合法更新
文章題目：創(chuàng)新互聯(lián)kubernetes教程：KubernetesPod安全性準(zhǔn)入
本文網(wǎng)址：http://www.5511xx.com/article/dpigecj.html
