日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

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)容：

啟用 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)入控制器的遷移：

1. 將您的 PodSecurityPolicies 限制為 Pod 安全標(biāo)準(zhǔn)定義的策略：
• Privileged
• Baseline
• Restricted
2. 僅使用 ?system:serviceaccounts:? 組（其中 ?? 是目標(biāo)命名空間）將 PSP 綁定到整個命名空間。 例如：

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)選擇策略：

1. PodSecurityPolicies 允許 pod 保持原樣，而不更改默認(rèn)值或改變 pod，是首選。 這些非變異 PodSecurityPolicies 的順序無關(guān)緊要。
2. 如果 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:default

rolebinding "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 mounts

Warning:

對主機(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/? - 將配置文件指定為位于 ?/? 的節(jié)點上的文件，其中 ?? 是通過 Kubelet 上的 ?--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?中列出。