建站
咨詢
售后
建站咨詢
新聞中心
Pod安全策略
FEATURE STATE: Kubernetes v1.21 [deprecated]
創(chuàng)新互聯(lián)建站專注于網(wǎng)站建設(shè)、做網(wǎng)站、網(wǎng)頁設(shè)計、網(wǎng)站制作、網(wǎng)站開發(fā)。公司秉持“客戶至上,用心服務(wù)”的宗旨,從客戶的利益和觀點出發(fā),讓客戶在網(wǎng)絡(luò)營銷中找到自己的駐足之地。尊重和關(guān)懷每一位客戶，用嚴(yán)謹(jǐn)?shù)膽B(tài)度對待客戶，用專業(yè)的服務(wù)創(chuàng)造價值，成為客戶值得信賴的朋友，為客戶解除后顧之憂。
Caution: PodSecurityPolicy 自 Kubernetes v1.21 起已棄用，并將在 v1.25 中刪除。 我們建議遷移到 Pod 安全準(zhǔn)入或 3rd 方準(zhǔn)入插件。
Pod 安全策略啟用對 pod 創(chuàng)建和更新的細(xì)粒度授權(quán)。
什么是 Pod 安全策略？
Pod 安全策略是控制 pod 規(guī)范的安全敏感方面的集群級資源。 PodSecurityPolicy 對象定義了一組條件，Pod 必須滿足這些條件才能被系統(tǒng)接受，以及相關(guān)字段的默認(rèn)值。 它們允許管理員控制以下內(nèi)容：
| 控制方面 | 字段名稱 |
|---|---|
| 運行特權(quán)容器 | privileged |
| 主機(jī)命名空間的使用 | hostPID, hostIPC |
| 主機(jī)網(wǎng)絡(luò)和端口的使用 | hostNetwork, hostPorts |
| 卷類型的使用 | volumes |
| 主機(jī)文件系統(tǒng)的使用 | allowedHostPaths |
| 允許特定的 FlexVolume 驅(qū)動程序 | allowedFlexVolumes |
| 分配擁有 pod 卷的 FSGroup | fsGroup |
| 要求使用只讀根文件系統(tǒng) | readOnlyRootFilesystem |
| 容器的用戶和組 ID | runAsUser, runAsGroup, supplementalGroups |
| 限制升級到 root 權(quán)限 | allowPrivilegeEscalation, defaultAllowPrivilegeEscalation |
| Linux 功能 | defaultAddCapabilities, requiredDropCapabilities, allowedCapabilities |
| 容器的 SELinux 上下文 | seLinux |
| 容器的 Allowed Proc Mount 類型 | allowedProcMountTypes |
| 容器使用的 AppArmor 配置文件 | annotations |
| 容器使用的 seccomp 配置文件 | annotations |
| 容器使用的 sysctl 配置文件 | forbiddenSysctls,allowedUnsafeSysctls |
啟用 Pod 安全策略
Pod 安全策略控制被實現(xiàn)為可選的準(zhǔn)入控制器。 PodSecurityPolicies 是通過啟用準(zhǔn)入控制器來實施的，但是在沒有授權(quán)任何策略的情況下這樣做會阻止在集群中創(chuàng)建任何 Pod。
由于 pod 安全策略 API (?policy/v1beta1/podsecuritypolicy?) 獨立于準(zhǔn)入控制器啟用，因此對于現(xiàn)有集群，建議在啟用準(zhǔn)入控制器之前添加和授權(quán)策略。
授權(quán)政策
創(chuàng)建 PodSecurityPolicy 資源時，它什么也不做。 為了使用它，請求用戶或目標(biāo) pod 的服務(wù)帳戶必須被授權(quán)使用該策略，方法是允許策略上的 ?use?verb。
大多數(shù) Kubernetes pod 不是由用戶直接創(chuàng)建的。 相反，它們通常作為 Deployment、ReplicaSet 或其他模板化控制器的一部分通過控制器管理器間接創(chuàng)建。 授予控制器對策略的訪問權(quán)限將授予該控制器創(chuàng)建的所有 Pod 的訪問權(quán)限，因此授權(quán)策略的首選方法是授予對 Pod 的服務(wù)帳戶的訪問權(quán)限
通過 RBAC
RBAC 是一種標(biāo)準(zhǔn)的 Kubernetes 授權(quán)模式，可以很容易地用于授權(quán)策略的使用。
首先，?Role? 或 ?ClusterRole ?需要授予使用所需策略的訪問權(quán)限。 授予訪問權(quán)限的規(guī)則如下所示：
apiVersion: rbac.authorization.K8S.io/v1
kind: ClusterRole
metadata:
name:
rules:
- apiGroups: ['policy']
resources: ['podsecuritypolicies']
verbs: ['use']
resourceNames:
-
然后 ?(Cluster)Role? 綁定到授權(quán)用戶：
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name:
roleRef:
kind: ClusterRole
name:
apiGroup: rbac.authorization.k8s.io
subjects:
# Authorize all service accounts in a namespace (recommended):
- kind: Group
apiGroup: rbac.authorization.k8s.io
name: system:serviceaccounts:
# Authorize specific service accounts (not recommended):
- kind: ServiceAccount
name:
namespace:
# Authorize specific users (not recommended):
- kind: User
apiGroup: rbac.authorization.k8s.io
name: 如果使用 ?RoleBinding?（不是 ?ClusterRoleBinding?），它只會授予與綁定在同一命名空間中運行的 Pod 的使用權(quán)。 這可以與系統(tǒng)組配對以授予對命名空間中運行的所有 pod 的訪問權(quán)限：
# Authorize all service accounts in a namespace:
- kind: Group
apiGroup: rbac.authorization.k8s.io
name: system:serviceaccounts
# Or equivalently, all authenticated users in a namespace:
- kind: Group
apiGroup: rbac.authorization.k8s.io
name: system:authenticated推薦做法
PodSecurityPolicy 正在被一個新的、簡化的 ?PodSecurity ?準(zhǔn)入控制器所取代。請遵循以下指南來簡化從 PodSecurityPolicy 到新準(zhǔn)入控制器的遷移：
- 將您的 PodSecurityPolicies 限制為 Pod 安全標(biāo)準(zhǔn)定義的策略：
- Privileged
- Baseline
- Restricted
- 僅使用 ?
system:serviceaccounts:? 組（其中 ?
apiVersion: rbac.authorization.k8s.io/v1
# This cluster role binding allows all pods in the "development" namespace to use the baseline PSP.
kind: ClusterRoleBinding
metadata:
name: psp-baseline-namespaces
roleRef:
kind: ClusterRole
name: psp-baseline
apiGroup: rbac.authorization.k8s.io
subjects:
- kind: Group
name: system:serviceaccounts:development
apiGroup: rbac.authorization.k8s.io
- kind: Group
name: system:serviceaccounts:canary
apiGroup: rbac.authorization.k8s.io故障排除
控制器管理器必須針對安全的 API 端口運行，并且不得具有超級用戶權(quán)限。
如果控制器管理器通過受信任的 API 端口（也稱為 ?localhost ?偵聽器）連接，請求將繞過身份驗證和授權(quán)模塊； 所有 PodSecurityPolicy 對象都將被允許，并且用戶將能夠創(chuàng)建授予自己創(chuàng)建特權(quán)容器的能力。
Policy Order
除了限制 pod 創(chuàng)建和更新之外，pod 安全策略還可用于為其控制的許多字段提供默認(rèn)值。 當(dāng)有多個策略可用時，Pod 安全策略控制器根據(jù)以下標(biāo)準(zhǔn)選擇策略：
- PodSecurityPolicies 允許 pod 保持原樣，而不更改默認(rèn)值或改變 pod，是首選。 這些非變異 PodSecurityPolicies 的順序無關(guān)緊要。
- 如果 pod 必須是默認(rèn)的或變異的，則選擇第一個允許該 pod 的 PodSecurityPolicy（按名稱排序）。
Note: 在更新操作期間（在此期間不允許對 pod 規(guī)范進(jìn)行更改），僅使用非變異 PodSecurityPolicies 來驗證 pod。
例子
此示例假設(shè)您有一個正在運行的集群并啟用了 PodSecurityPolicy 準(zhǔn)入控制器，并且您擁有集群管理員權(quán)限。
設(shè)置
設(shè)置命名空間和服務(wù)帳戶以作為本示例的行為。 我們將使用此服務(wù)帳戶來模擬非管理員用戶。
kubectl create namespace psp-example
kubectl create serviceaccount -n psp-example fake-user
kubectl create rolebinding -n psp-example fake-editor --clusterrole=edit --serviceaccount=psp-example:fake-user為了明確我們所扮演的用戶并保存一些輸入，創(chuàng)建 2 個別名：
alias kubectl-admin='kubectl -n psp-example'
alias kubectl-user='kubectl --as=system:serviceaccount:psp-example:fake-user -n psp-example'創(chuàng)建策略和 pod
在文件中定義示例 PodSecurityPolicy 對象。 這是一項阻止創(chuàng)建特權(quán) pod 的策略。 PodSecurityPolicy 對象的名稱必須是有效的 DNS 子域名。
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: example
spec:
privileged: false # Don't allow privileged pods!
# The rest fills in some required fields.
seLinux:
rule: RunAsAny
supplementalGroups:
rule: RunAsAny
runAsUser:
rule: RunAsAny
fsGroup:
rule: RunAsAny
volumes:
- '*'
并使用 kubectl 創(chuàng)建它：
kubectl-admin create -f example-psp.yaml
現(xiàn)在，作為非特權(quán)用戶，嘗試創(chuàng)建一個簡單的 pod：
kubectl-user create -f- <輸出類似于：
Error from server (Forbidden): error when creating "STDIN": pods "pause" is forbidden: unable to validate against any pod security policy: []
盡管創(chuàng)建了 PodSecurityPolicy，但 pod 的服務(wù)帳戶和 ?fake-user? 都無權(quán)使用新策略：
kubectl-user auth can-i use podsecuritypolicy/example
no創(chuàng)建角色綁定以授予 ?fake-user? 示例策略上的 ?use?verb：
Note: 這不是推薦的方式！
kubectl-admin create role psp:unprivileged \
--verb=use \
--resource=podsecuritypolicy \
--resource-name=example
role "psp:unprivileged" created
kubectl-admin create rolebinding fake-user:psp:unprivileged \
--role=psp:unprivileged \
--serviceaccount=psp-example:fake-user
rolebinding "fake-user:psp:unprivileged" created
kubectl-user auth can-i use podsecuritypolicy/example
yes現(xiàn)在重試創(chuàng)建 pod：
kubectl-user create -f- <輸出類似于此
pod "pause" created
它按預(yù)期工作！ 但仍應(yīng)拒絕任何創(chuàng)建特權(quán) pod 的嘗試：
kubectl-user create -f- <輸出類似于：
Error from server (Forbidden): error when creating "STDIN": pods "privileged" is forbidden: unable to validate against any pod security policy: [spec.containers[0].securityContext.privileged: Invalid value: true: Privileged containers are not allowed]
在繼續(xù)之前刪除 pod：
kubectl-user delete pod pause
運行另一個 pod
讓我們再試一次，稍有不同：
kubectl-user create deployment pause --image=k8s.gcr.io/pause
deployment "pause" created
kubectl-user get pods
No resources found.
kubectl-user get events | head -n 2
LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE
1m 2m 15 pause-7774d79b5 ReplicaSet Warning FailedCreate replicaset-controller Error creating: pods "pause-7774d79b5-" is forbidden: no providers available to validate pod request我們已經(jīng)為我們的 ?fake-user? 綁定了 ?psp:unprivileged ?角色，為什么我們會收到錯誤 ?Error created: pods "pause-7774d79b5-" is disabled: no providers available to validate pod request?？ 答案在于源——?replicaset-controller?。 Fake-user 成功創(chuàng)建了部署（成功創(chuàng)建了一個副本集），但是當(dāng)副本集去創(chuàng)建 pod 時，它沒有被授權(quán)使用示例 podsecuritypolicy。
為了解決這個問題，請將 ?psp:unprivileged? 角色綁定到 pod 的服務(wù)帳戶。 在這種情況下（因為我們沒有指定它）服務(wù)帳戶是默認(rèn)的：
kubectl-admin create rolebinding default:psp:unprivileged \
--role=psp:unprivileged \
--serviceaccount=psp-example:defaultrolebinding "default:psp:unprivileged" created
現(xiàn)在，如果你給它一分鐘重試，replicas-controller 最終應(yīng)該會成功創(chuàng)建 pod：
kubectl-user get pods --watch
NAME READY STATUS RESTARTS AGE
pause-7774d79b5-qrgcb 0/1 Pending 0 1s
pause-7774d79b5-qrgcb 0/1 Pending 0 1s
pause-7774d79b5-qrgcb 0/1 ContainerCreating 0 1s
pause-7774d79b5-qrgcb 1/1 Running 0 2s清理
刪除命名空間以清理大部分示例資源：
kubectl-admin delete ns psp-example
namespace "psp-example" deleted
請注意，?PodSecurityPolicy ?資源沒有命名空間，必須單獨清理：
kubectl-admin delete psp example
podsecuritypolicy "example" deleted
示例策略
這是您可以創(chuàng)建的限制最少的策略，相當(dāng)于不使用 pod 安全策略準(zhǔn)入控制器：
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: privileged
annotations:
seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
spec:
privileged: true
allowPrivilegeEscalation: true
allowedCapabilities:
- '*'
volumes:
- '*'
hostNetwork: true
hostPorts:
- min: 0
max: 65535
hostIPC: true
hostPID: true
runAsUser:
rule: 'RunAsAny'
seLinux:
rule: 'RunAsAny'
supplementalGroups:
rule: 'RunAsAny'
fsGroup:
rule: 'RunAsAny'
這是一個限制性策略的示例，它要求用戶以非特權(quán)用戶身份運行，阻止可能升級到 root，并需要使用多種安全機(jī)制。
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: restricted
annotations:
# docker/default identifies a profile for seccomp, but it is not particularly tied to the Docker runtime
seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default,runtime/default'
apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default'
apparmor.security.beta.kubernetes.io/defaultProfileName: 'runtime/default'
spec:
privileged: false
# Required to prevent escalations to root.
allowPrivilegeEscalation: false
requiredDropCapabilities:
- ALL
# Allow core volume types.
volumes:
- 'configMap'
- 'emptyDir'
- 'projected'
- 'secret'
- 'downwardAPI'
# Assume that ephemeral CSI drivers & persistentVolumes set up by the cluster admin are safe to use.
- 'csi'
- 'persistentVolumeClaim'
- 'ephemeral'
hostNetwork: false
hostIPC: false
hostPID: false
runAsUser:
# Require the container to run without root privileges.
rule: 'MustRunAsNonRoot'
seLinux:
# This policy assumes the nodes are using AppArmor rather than SELinux.
rule: 'RunAsAny'
supplementalGroups:
rule: 'MustRunAs'
ranges:
# Forbid adding the root group.
- min: 1
max: 65535
fsGroup:
rule: 'MustRunAs'
ranges:
# Forbid adding the root group.
- min: 1
max: 65535
readOnlyRootFilesystem: false
策略參考
特權(quán)
Privileged - 確定 pod 中的任何容器是否可以啟用特權(quán)模式。 默認(rèn)情況下，不允許容器訪問主機(jī)上的任何設(shè)備，但“特權(quán)”容器可以訪問主機(jī)上的所有設(shè)備。 這允許容器幾乎與主機(jī)上運行的進(jìn)程具有相同的訪問權(quán)限。 這對于想要使用 linux 功能（例如操作網(wǎng)絡(luò)堆棧和訪問設(shè)備）的容器很有用。
主機(jī)命名空間
- ?
HostPID? - 控制 pod 容器是否可以共享主機(jī)進(jìn)程 ID 命名空間。 請注意，當(dāng)與 ptrace 配對時，這可用于提升容器外部的權(quán)限（默認(rèn)情況下禁止使用 ptrace）。 - ?
HostIPC?- 控制 pod 容器是否可以共享主機(jī) IPC 命名空間。 - ?
HostNetwork?- 控制 pod 是否可以使用節(jié)點網(wǎng)絡(luò)命名空間。 這樣做可以讓 pod 訪問環(huán)回設(shè)備、偵聽 localhost 的服務(wù)，并可用于窺探同一節(jié)點上其他 pod 的網(wǎng)絡(luò)活動。 - ?
HostPorts?- 提供主機(jī)網(wǎng)絡(luò)命名空間中允許的端口范圍列表。 定義為 ?HostPortRange?的列表，具有 ?min?(inclusive) 和 ?max?(inclusive)。 默認(rèn)為不允許的主機(jī)端口。
卷和文件系統(tǒng)
卷 - 提供允許的卷類型列表。 允許的值對應(yīng)于創(chuàng)建卷時定義的卷源。 此外，?*? 可用于允許所有卷類型。
新 PSPs 的建議最小允許卷集是：
- ?
configMap? - ?
downwardAPI? - ?
emptyDir? - ?
persistentVolumeClaim? - ?
secret? - ?
projected?
Warning: PodSecurityPolicy 不限制 ?
PersistentVolumeClaim?可以引用的 ?PersistentVolume?對象的類型，hostPath 類型的 ?PersistentVolume?不支持只讀訪問模式。 只有受信任的用戶才應(yīng)被授予創(chuàng)建 ?PersistentVolume?對象的權(quán)限。
FSGroup - 控制應(yīng)用于某些卷的補(bǔ)充組。
- ?
MustRunAs?- 至少需要指定一個范圍。 使用第一個范圍的最小值作為默認(rèn)值。 針對所有范圍進(jìn)行驗證。 - ?
MayRunAs?- 至少需要指定一個范圍。 允許不設(shè)置 ?FSGroups?而不提供默認(rèn)值。 如果設(shè)置了 ?FSGroups?，則針對所有范圍進(jìn)行驗證。 - ?
RunAsAny?- 未提供默認(rèn)值。 允許指定任何 ?fsGroup?ID。
AllowedHostPaths - 這指定允許由 hostPath 卷使用的主機(jī)路徑列表。 空列表意味著對使用的主機(jī)路徑?jīng)]有限制。 這被定義為具有單個 ?pathPrefix ?字段的對象列表，它允許 hostPath 卷安裝以允許的前綴開頭的路徑，并且 ?readOnly ?字段指示它必須以只讀方式安裝。 例如：
allowedHostPaths:
# This allows "/foo", "/foo/", "/foo/bar" etc., but
# disallows "/fool", "/etc/foo" etc.
# "/foo/../" is never valid.
- pathPrefix: "/foo"
readOnly: true # only allow read-only mountsWarning:
對主機(jī)文件系統(tǒng)具有無限制訪問權(quán)限的容器可以通過多種方式提升權(quán)限，包括從其他容器讀取數(shù)據(jù)，以及濫用系統(tǒng)服務(wù)（如 Kubelet）的憑據(jù)。
可寫的 hostPath 目錄卷允許容器以允許它們在 ?
pathPrefix?之外遍歷主機(jī)文件系統(tǒng)的方式寫入文件系統(tǒng)。 ?
readOnly: true?，在 Kubernetes 1.11+ 中可用，必須在所有 ?
allowedHostPaths?上使用，以有效限制對指定 ?
pathPrefix?的訪問。
ReadOnlyRootFilesystem - 要求容器必須使用只讀根文件系統(tǒng)（即無可寫層）運行。
彈性卷驅(qū)動程序
這指定了允許 flexvolume 使用的 FlexVolume 驅(qū)動程序列表。 空列表或 nil 表示對驅(qū)動程序沒有限制。 請確保 ?volumes ?字段包含 ?flexVolume ?卷類型； 否則不允許使用任何 FlexVolume 驅(qū)動程序。
例如：
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: allow-flex-volumes
spec:
# ... other spec fields
volumes:
- flexVolume
allowedFlexVolumes:
- driver: example/lvm
- driver: example/cifs用戶和組
RunAsUser - 控制容器運行時使用的用戶 ID。
- ?
MustRunAs?- 至少需要指定一個范圍。 使用第一個范圍的最小值作為默認(rèn)值。 針對所有范圍進(jìn)行驗證。 - ?
MustRunAsNonRoot?- 要求使用非零 ?runAsUser?提交 pod 或在映像中定義 USER 指令（使用數(shù)字 UID）。 既沒有指定 ?runAsNonRoot?也沒有指定 ?runAsUser?設(shè)置的 Pod 將被更改為設(shè)置 ?runAsNonRoot=true?，因此需要在容器中定義一個非零數(shù)字 USER 指令。 沒有提供默認(rèn)值。 強(qiáng)烈建議使用此策略設(shè)置 ?allowPrivilegeEscalation=false?。 - ?
RunAsAny?- 未提供默認(rèn)值。 允許指定任何 ?runAsUser?。
RunAsGroup - 控制容器運行的主要組 ID。
- ?
MustRunAs?- 至少需要指定一個范圍。 使用第一個范圍的最小值作為默認(rèn)值。 針對所有范圍進(jìn)行驗證。 - ?
MayRunAs?- 不需要指定 RunAsGroup。 但是，當(dāng)指定 RunAsGroup 時，它們必須落在定義的范圍內(nèi)。 - ?
RunAsAny?- 未提供默認(rèn)值。 允許指定任何 ?runAsGroup?
SupplementalGroups - 控制容器添加的組 ID。
- ?
MustRunAs?- 至少需要指定一個范圍。 使用第一個范圍的最小值作為默認(rèn)值。 針對所有范圍進(jìn)行驗證。 - ?
MayRunAs?- 至少需要指定一個范圍。 允許在不提供默認(rèn)值的情況下不設(shè)置?supplementalGroups?。 如果設(shè)置了補(bǔ)充組，則驗證所有范圍。 - ?
RunAsAny?- 未提供默認(rèn)值。 允許指定任何補(bǔ)充組。
權(quán)限提升
這些選項控制 ?allowPrivilegeEscalation ?容器選項。 此布爾值直接控制是否在容器進(jìn)程上設(shè)置 ?no_new_privs ?標(biāo)志。 此標(biāo)志將阻止 ?setuid ?二進(jìn)制文件更改有效用戶 ID，并阻止文件啟用額外功能（例如，它將阻止使用 ?ping ?工具）。 此行為是有效實施 ?MustRunAsNonRoot ?所必需的。
AllowPrivilegeEscalation - 決定是否允許用戶將容器的安全上下文設(shè)置為 ?allowPrivilegeEscalation=true?。 這默認(rèn)為允許，以免破壞 setuid 二進(jìn)制文件。 將其設(shè)置為 ?false ?可確保容器的任何子進(jìn)程都無法獲得比其父進(jìn)程更多的權(quán)限。
DefaultAllowPrivilegeEscalation - 設(shè)置 ?allowPrivilegeEscalation ?選項的默認(rèn)值。 沒有這個的默認(rèn)行為是允許權(quán)限升級，以免破壞 setuid 二進(jìn)制文件。 如果不需要該行為，則可以使用此字段默認(rèn)為禁止，同時仍允許 pod 顯式請求 ?allowPrivilegeEscalation?。
能力
Linux 功能提供了對傳統(tǒng)上與超級用戶相關(guān)的權(quán)限的更細(xì)粒度的細(xì)分。 其中一些功能可用于提升權(quán)限或用于容器突破，并且可能受 PodSecurityPolicy 限制。
以下字段采用功能列表，指定為 ALL_CAPS 中不帶 ?CAP_ ?前綴的功能名稱。
- ?
AllowedCapabilities?- 提供允許添加到容器的功能列表。 默認(rèn)功能集是隱式允許的。 空集意味著除了默認(rèn)集之外不能添加其他功能。 ?*? 可用于允許所有功能。 - ?
RequiredDropCapabilities?- 必須從容器中刪除的功能。 這些功能已從默認(rèn)設(shè)置中刪除，不得添加。 ?RequiredDropCapabilities?中列出的功能不得包含在 ?AllowedCapabilities?或 ?DefaultAddCapabilities?中。 - ?
DefaultAddCapabilities?- 除了運行時默認(rèn)值之外，默認(rèn)情況下添加到容器的功能。
SELinux
- ?
MustRunAs?- 需要配置 ?seLinuxOptions?。 使用 ?seLinuxOptions?作為默認(rèn)值。 針對 ?seLinuxOptions?進(jìn)行驗證。 - ?
RunAsAny?- 未提供默認(rèn)值。 允許指定任何 ?seLinuxOptions?。
AllowedProcMountTypes
?allowedProcMountTypes ?是允許的 ProcMountTypes 的列表。 Empty 或 nil 表示只能使用 ?DefaultProcMountType?。
?DefaultProcMount ?對 /proc 的只讀路徑和掩碼路徑使用容器運行時默認(rèn)值。 大多數(shù)容器運行時會屏蔽 /proc 中的某些路徑，以避免特殊設(shè)備或信息的意外安全暴露。 這表示為字符串 ?Default?。
唯一的其他 ProcMountType 是 ?UnmaskedProcMount?，它繞過了容器運行時的默認(rèn)屏蔽行為，并確保新創(chuàng)建的 /proc 容器保持不變而無需修改。 這表示為字符串 ?Unmasked?。
AppArmor
通過 PodSecurityPolicy 上的注釋進(jìn)行控制。
Seccomp
從 Kubernetes v1.19 開始，您可以使用 Pod 或容器的 ?securityContext ?中的 ?seccompProfile ?字段來控制 seccomp 配置文件的使用。 在之前的版本中，seccomp 是通過向 Pod 添加注釋來控制的。 相同的 PodSecurityPolicies 可以與任一版本一起使用，以強(qiáng)制應(yīng)用這些字段或注釋。
seccomp.security.alpha.kubernetes.io/defaultProfileName - 指定要應(yīng)用于容器的默認(rèn) seccomp 配置文件的注釋。 可能的值為：
- ?
unconfined?- 如果沒有提供替代方案，則不將 Seccomp 應(yīng)用于容器進(jìn)程（這是 Kubernetes 中的默認(rèn)設(shè)置）。 - ?
runtime/default? - 使用默認(rèn)容器運行時配置文件。 - ?
docker/default? - 使用 Docker 默認(rèn)的 seccomp 配置文件。 自 Kubernetes 1.11 起已棄用。 請改用runtime/default。 - ?
localhost/? - 將配置文件指定為位于 ?/ --seccomp-profile-root? 標(biāo)志定義的。 如果未定義 ?--seccomp-profile-root? 標(biāo)志，將使用默認(rèn)路徑，即 ?/seccomp --root-dir? 標(biāo)志指定。
Note: ?
--seccomp-profile-root? 標(biāo)志自 Kubernetes v1.19 起已棄用。 鼓勵用戶使用默認(rèn)路徑。
?seccomp.security.alpha.kubernetes.io/allowedProfileNames? - 指定 pod seccomp 注釋允許哪些值的注釋。 指定為允許值的逗號分隔列表。 可能的值是上面列出的值，加上 ?*? 以允許所有配置文件。 缺少此注釋意味著無法更改默認(rèn)值。
Sysctl
默認(rèn)情況下，允許所有安全的 sysctl。
- ?
forbiddenSysctls?- 不包括特定的 sysctl。 您可以在列表中禁止安全和不安全 sysctl 的組合。 要禁止設(shè)置任何 sysctls，請單獨使用 ?*?。 - ?
allowedUnsafeSysctls?- 允許被默認(rèn)列表禁止的特定 sysctl，只要這些未在?forbiddenSysctls?中列出。
本文標(biāo)題：創(chuàng)新互聯(lián)kubernetes教程：Kubernetes Pod安全策略
URL分享：http://m.fisionsoft.com.cn/article/dphhsdo.html
