本文发布已超过一年。较旧的文章可能包含过时的内容。请检查页面中的信息自发布以来是否已变得不正确。

Kubernetes 1.23：Pod 安全升级为 Beta

作者：Jim Angel (Google), Lachlan Evenson (Microsoft) |

随着 Kubernetes v1.23 的发布，Pod 安全准入现在已进入 beta 阶段。Pod 安全是一个内置准入控制器，它根据预定义的Pod 安全标准评估 Pod 规范，并确定是否允许或拒绝 Pod 运行。

Pod 安全是 PodSecurityPolicy 的后继者，后者在 v1.21 版本中已被弃用，并将在 Kubernetes v1.25 中被移除。在本文中，我们将介绍 Pod 安全的关键概念以及如何使用它。我们希望集群管理员和开发人员都将使用这种新机制来为其工作负载强制执行安全默认设置。

为什么要使用 Pod 安全

Pod 安全的总体目标是让您隔离工作负载。您可以运行一个运行不同工作负载的集群，并且无需添加额外的第三方工具，即可实施控制，要求工作负载的 Pod 将其自身的权限限制在定义的边界集内。

Pod 安全克服了 Kubernetes 现有但已弃用的 PodSecurityPolicy (PSP) 机制的关键缺陷

  • 策略授权模型 — 难以与控制器一起部署。
  • 切换的风险 — 缺乏 dry-run/审计功能使得启用 PodSecurityPolicy 变得困难。
  • 不一致且无界的 API — 大量的配置表面和不断变化的约束导致了复杂且令人困惑的 API。

PSP 的缺陷使其难以使用，这导致社区重新评估是否可以使用更好的实现来达到相同的目标。其中一个目标是提供一个开箱即用的解决方案来应用安全最佳实践。Pod 安全附带预定义的 Pod 安全级别，集群管理员可以配置这些级别以满足所需的安全态势。

请务必注意，Pod 安全与已弃用的 PodSecurityPolicy 不具有完整的功能对等性。具体来说，它不具备变更或更改 Kubernetes 资源以代表用户自动修复策略违规的能力。此外，它不提供对 Pod 规范或您可能希望评估的任何其他 Kubernetes 资源中每个允许的字段和值的细粒度控制。如果您需要更细粒度的策略控制，请查看这些其他支持此类用例的项目。

Pod 安全还遵循 Kubernetes 声明式对象管理的最佳实践，通过拒绝违反策略的资源来实现。这要求在部署到 Kubernetes 之前更新源存储库中的资源并更新工具。

Pod 安全如何工作？

Pod 安全是 Kubernetes v1.22 开始的内置准入控制器，但也可以作为独立的webhook 运行。准入控制器通过在持久化到存储之前拦截 Kubernetes API 服务器中的请求来发挥作用。它们可以允许或拒绝请求。对于 Pod 安全，将根据以 Pod 安全标准形式配置的策略评估 Pod 规范。这意味着 Pod 规范中对安全敏感的字段将仅允许具有特定值。

配置 Pod 安全

Pod 安全标准

为了使用 Pod 安全，我们首先需要了解Pod 安全标准。这些标准定义了三种不同的策略级别，从允许到限制不等。这些级别如下

  • privileged — 开放且不受限制
  • baseline — 涵盖已知的权限提升，同时最大限度地减少限制
  • restricted — 高度受限，可防止已知和未知的权限提升。可能会导致兼容性问题

这些策略级别中的每一个都定义了 Pod 规范中限制的字段以及允许的值。这些策略限制的一些字段包括

  • spec.securityContext.sysctls
  • spec.hostNetwork
  • spec.volumes[*].hostPath
  • spec.containers[*].securityContext.privileged

策略级别通过命名空间资源上的标签应用，这允许每个命名空间的粒度策略选择。还可以配置 API 服务器中的 AdmissionConfiguration 以设置集群范围的默认级别和豁免。

策略模式

策略以特定模式应用。可以在同一命名空间上设置多个模式（具有不同的策略级别）。以下是模式列表

  • enforce — 任何违反策略的 Pod 都将被拒绝
  • audit — 违规行为将作为审计日志中的注释记录，但不影响是否允许 Pod。
  • warn — 违规行为将向用户发送警告消息，但不影响是否允许 Pod。

除了模式之外，您还可以将策略固定到特定版本（例如 v1.22）。固定到特定版本允许在策略定义在未来的 Kubernetes 版本中发生更改时保持行为一致。

实践演示

先决条件

部署 kind 集群

kind create cluster --image kindest/node:v1.23.0

启动可能需要一段时间，并且一旦启动，节点可能需要一分钟左右才能准备就绪。

kubectl cluster-info --context kind-kind

等待节点 STATUS 变为 ready。

kubectl get nodes

输出类似于此

NAME                 STATUS   ROLES                  AGE   VERSION
kind-control-plane   Ready    control-plane,master   54m   v1.23.0

确认启用 Pod 安全

确认 API 默认启用的插件的最佳方法是检查 Kubernetes API 容器的帮助参数。

kubectl -n kube-system exec kube-apiserver-kind-control-plane -it -- kube-apiserver -h | grep "default enabled ones"

输出类似于此

...
      --enable-admission-plugins strings
admission plugins that should be enabled in addition
to default enabled ones (NamespaceLifecycle, LimitRanger,
ServiceAccount, TaintNodesByCondition, PodSecurity, Priority,
DefaultTolerationSeconds, DefaultStorageClass,
StorageObjectInUseProtection, PersistentVolumeClaimResize,
RuntimeClass, CertificateApproval, CertificateSigning,
CertificateSubjectRestriction, DefaultIngressClass,
MutatingAdmissionWebhook, ValidatingAdmissionWebhook,
ResourceQuota).
...

PodSecurity 列在默认启用的准入插件组中。

如果使用云提供商，或者您无权访问 API 服务器，则最佳的检查方法是运行快速端到端测试

kubectl create namespace verify-pod-security
kubectl label namespace verify-pod-security pod-security.kubernetes.io/enforce=restricted
# The following command does NOT create a workload (--dry-run=server)
kubectl -n verify-pod-security run test --dry-run=server --image=busybox --privileged
kubectl delete namespace verify-pod-security

输出类似于此

Error from server (Forbidden): pods "test" is forbidden: violates PodSecurity "restricted:latest": privileged (container "test" must not set securityContext.privileged=true), allowPrivilegeEscalation != false (container "test" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "test" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "test" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "test" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

配置 Pod 安全

策略通过标签应用于命名空间。这些标签如下

  • pod-security.kubernetes.io/<MODE>: <LEVEL>（启用 Pod 安全所必需）
  • pod-security.kubernetes.io/<MODE>-version: <VERSION> (可选，默认为最新版本)

可以为每种强制模式提供特定版本。该版本将策略固定到作为 Kubernetes 版本一部分发布的版本。固定到特定的 Kubernetes 版本允许确定性的策略行为，同时为将来对 Pod 安全标准的更新提供灵活性。可能的 <MODE(S)> 是 enforce、audit 和 warn。

何时使用 warn？

warn 的典型用法是为将来您想要强制执行不同策略的更改做好准备。最常见的两种情况是

  • warn 处于相同的级别但不同的版本（例如，将 enforce 固定为 restricted+v1.23，将 warn 固定为 restricted+latest）
  • warn 处于更严格的级别（例如，enforce baseline，warn restricted）

不建议对与 enforce 策略完全相同的级别+版本使用 warn。在准入序列中，如果 enforce 失败，则整个序列会在评估 warn 之前失败。

首先，如果之前没有创建，请创建一个名为 verify-pod-security 的命名空间。对于演示，在标记时使用 --overwrite 以允许将单个命名空间重新用于多个示例。

kubectl create namespace verify-pod-security

部署演示工作负载

每个工作负载代表更高的安全级别，该级别不会通过其后的配置文件。

对于以下示例，使用 busybox 容器运行 100 万秒（≅11 天）的 sleep 命令或直到删除。Pod 安全不关心您选择哪个容器镜像，而是关心 Pod 级别的设置及其对安全性的影响。

特权级别和工作负载

对于特权 Pod，请使用 特权策略。这允许容器内的进程获取新进程（也称为“权限提升”），如果不受信任，可能会很危险。

首先，让我们应用一个受限制的 Pod 安全级别进行测试。

# enforces a "restricted" security policy and audits on restricted
kubectl label --overwrite ns verify-pod-security \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/audit=restricted

接下来，尝试在命名空间中部署特权工作负载。

cat <<EOF | kubectl -n verify-pod-security apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-privileged
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
    securityContext:
      allowPrivilegeEscalation: true
EOF

输出类似于此

Error from server (Forbidden): error when creating "STDIN": pods "busybox-privileged" is forbidden: violates PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "busybox" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "busybox" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "busybox" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "busybox" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

现在让我们应用特权的 Pod 安全级别并重试。

# enforces a "privileged" security policy and warns / audits on baseline
kubectl label --overwrite ns verify-pod-security \
  pod-security.kubernetes.io/enforce=privileged \
  pod-security.kubernetes.io/warn=baseline \
  pod-security.kubernetes.io/audit=baseline

cat <<EOF | kubectl -n verify-pod-security apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-privileged
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
    securityContext:
      allowPrivilegeEscalation: true
EOF

输出类似于此

pod/busybox-privileged created

我们可以运行 kubectl -n verify-pod-security get pods 来验证它是否正在运行。使用以下命令清理

kubectl -n verify-pod-security delete pod busybox-privileged

基线级别和工作负载

基线策略演示了明智的默认值，同时防止常见的容器漏洞。

让我们恢复到受限制的 Pod 安全级别以进行快速测试。

# enforces a "restricted" security policy and audits on restricted
kubectl label --overwrite ns verify-pod-security \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/audit=restricted

应用工作负载。

cat <<EOF | kubectl -n verify-pod-security apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-baseline
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        add:
          - NET_BIND_SERVICE
          - CHOWN
EOF

输出类似于此

Error from server (Forbidden): error when creating "STDIN": pods "busybox-baseline" is forbidden: violates PodSecurity "restricted:latest": unrestricted capabilities (container "busybox" must set securityContext.capabilities.drop=["ALL"]; container "busybox" must not include "CHOWN" in securityContext.capabilities.add), runAsNonRoot != true (pod or container "busybox" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "busybox" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

让我们应用基线的 Pod 安全级别并重试。

# enforces a "baseline" security policy and warns / audits on restricted
kubectl label --overwrite ns verify-pod-security \
  pod-security.kubernetes.io/enforce=baseline \
  pod-security.kubernetes.io/warn=restricted \
  pod-security.kubernetes.io/audit=restricted

cat <<EOF | kubectl -n verify-pod-security apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-baseline
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        add:
          - NET_BIND_SERVICE
          - CHOWN
EOF

输出类似于以下内容。请注意，警告与上面测试中的错误消息匹配，但仍然成功创建了 Pod。

Warning: would violate PodSecurity "restricted:latest": unrestricted capabilities (container "busybox" must set securityContext.capabilities.drop=["ALL"]; container "busybox" must not include "CHOWN" in securityContext.capabilities.add), runAsNonRoot != true (pod or container "busybox" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "busybox" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
pod/busybox-baseline created

请记住，我们根据受限配置文件将 verify-pod-security 命名空间设置为 warn。我们可以运行 kubectl -n verify-pod-security get pods 来验证它是否正在运行。使用以下命令清理

kubectl -n verify-pod-security delete pod busybox-baseline

受限级别和工作负载

受限策略要求拒绝所有特权参数。它是最安全的，但需要权衡复杂性。受限策略仅允许容器添加 NET_BIND_SERVICE 功能。

虽然我们已经测试了受限作为阻止功能，但让我们尝试运行一些符合所有标准的东西。

首先，我们需要最后一次重新应用受限配置文件。

# enforces a "restricted" security policy and audits on restricted
kubectl label --overwrite ns verify-pod-security \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/audit=restricted

cat <<EOF | kubectl -n verify-pod-security apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-restricted
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        add:
          - NET_BIND_SERVICE
EOF

输出类似于此

Error from server (Forbidden): error when creating "STDIN": pods "busybox-restricted" is forbidden: violates PodSecurity "restricted:latest": unrestricted capabilities (container "busybox" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "busybox" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "busybox" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")

这是因为受限配置文件明确要求将某些值设置为最安全的参数。

通过要求显式值，清单变得更具声明性，并且您的整个安全模型可以左移。通过 restricted 级别的强制执行，公司可以根据允许的清单审核其集群的合规性。

让我们修复每个警告，最终得到以下文件

cat <<EOF | kubectl -n verify-pod-security apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-restricted
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
    securityContext:
      seccompProfile:
        type: RuntimeDefault
      runAsNonRoot: true
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL
        add:
          - NET_BIND_SERVICE
EOF

输出类似于此

pod/busybox-restricted created

运行 kubectl -n verify-pod-security get pods 来验证它是否正在运行。输出类似于这样：

NAME               READY   STATUS                       RESTARTS   AGE
busybox-restricted   0/1     CreateContainerConfigError   0          2m26s

让我们使用 kubectl -n verify-pod-security describe pod busybox-restricted 来找出容器没有启动的原因。输出类似于这样：

Events:
  Type     Reason     Age                    From               Message
  ----     ------     ----                   ----               -------
  Warning  Failed     2m29s (x8 over 3m55s)  kubelet            Error: container has runAsNonRoot and image will run as root (pod: "busybox-restricted_verify-pod-security(a4c6a62d-2166-41a9-b288-20df17cf5c90)", container: busybox)

要解决这个问题，请将有效 UID (runAsUser) 设置为非零（root）值，或者使用 nobody UID (65534)。

# delete the original pod
kubectl -n verify-pod-security delete pod busybox-restricted

# create the pod again with new runAsUser
cat <<EOF | kubectl -n verify-pod-security apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-restricted
spec:
  securityContext:
    runAsUser: 65534
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
    securityContext:
      seccompProfile:
        type: RuntimeDefault
      runAsNonRoot: true
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL
        add:
          - NET_BIND_SERVICE
EOF

运行 kubectl -n verify-pod-security get pods 来验证它是否正在运行。输出类似于这样：

NAME                 READY   STATUS    RESTARTS   AGE
busybox-restricted   1/1     Running   0          25s

使用以下命令清理演示（受限 Pod 和命名空间）：

kubectl delete namespace verify-pod-security

此时，如果你想深入了解 Linux 权限或特定容器允许的内容，可以进入控制平面，使用 containerd 和 crictl inspect 进行操作。

# if using docker, shell into the control plane
docker exec -it kind-control-plane bash

# list running containers
crictl ps

# inspect each one by container ID
crictl inspect <CONTAINER ID>

应用集群范围策略

除了向命名空间应用标签来配置策略外，你还可以使用 AdmissionConfiguration 资源配置集群范围的策略和豁免。

使用此资源，默认情况下策略定义在集群范围内应用，任何通过命名空间标签应用的策略都将优先。

AdmissionConfiguration 配置文件没有运行时可配置的 API，因此集群管理员需要通过 API 服务器上的 --admission-control-config-file 标志指定文件的路径。

在以下资源中，我们正在强制执行基线策略，并警告和审计基线策略。我们还将 kube-system 命名空间排除在此策略之外。

不建议在安装后更改控制平面/集群，因此让我们构建一个新集群，在所有命名空间上都使用默认策略。

首先，删除当前集群。

kind delete cluster

创建一个 Pod 安全配置，该配置 enforce 和 audit 基线策略，同时使用受限配置文件来 warn 最终用户。

cat <<EOF > pod-security.yaml
apiVersion: apiserver.config.k8s.io/v1
kind: AdmissionConfiguration
plugins:
- name: PodSecurity
  configuration:
    apiVersion: pod-security.admission.config.k8s.io/v1beta1
    kind: PodSecurityConfiguration
    defaults:
      enforce: "baseline"
      enforce-version: "latest"
      audit: "baseline"
      audit-version: "latest"
      warn: "restricted"
      warn-version: "latest"
    exemptions:
      # Array of authenticated usernames to exempt.
      usernames: []
      # Array of runtime class names to exempt.
      runtimeClasses: []
      # Array of namespaces to exempt.
      namespaces: [kube-system]
EOF

有关其他选项，请查看官方标准准入控制器文档。

我们现在有了一个默认的基线策略。接下来将其传递给 kind 配置，以启用 --admission-control-config-file API 服务器参数并传递策略文件。要将文件传递到 kind 集群，请使用配置文件传递其他设置指令。Kind 使用 kubeadm 来配置集群，并且配置文件能够传递 kubeadmConfigPatches 以进行进一步的自定义。在我们的例子中，本地文件被挂载到控制平面节点作为 /etc/kubernetes/policies/pod-security.yaml，然后挂载到 apiServer 容器中。我们还传递指向策略位置的 --admission-control-config-file 参数。

cat <<EOF > kind-config.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
  kubeadmConfigPatches:
  - |
    kind: ClusterConfiguration
    apiServer:
        # enable admission-control-config flag on the API server
        extraArgs:
          admission-control-config-file: /etc/kubernetes/policies/pod-security.yaml
        # mount new file / directories on the control plane
        extraVolumes:
          - name: policies
            hostPath: /etc/kubernetes/policies
            mountPath: /etc/kubernetes/policies
            readOnly: true
            pathType: "DirectoryOrCreate"
  # mount the local file on the control plane
  extraMounts:
  - hostPath: ./pod-security.yaml
    containerPath: /etc/kubernetes/policies/pod-security.yaml
    readOnly: true
EOF

使用上面定义的 kind 配置文件创建一个新集群。

kind create cluster --image kindest/node:v1.23.0 --config kind-config.yaml

让我们看看默认命名空间。

kubectl describe namespace default

输出类似于此

Name:         default
Labels:       kubernetes.io/metadata.name=default
Annotations:  <none>
Status:       Active

No resource quota.

No LimitRange resource.

让我们创建一个新的命名空间，看看标签是否也应用于那里。

kubectl create namespace test-defaults
kubectl describe namespace test-defaults

相同。

Name:         test-defaults
Labels:       kubernetes.io/metadata.name=test-defaults
Annotations:  <none>
Status:       Active

No resource quota.

No LimitRange resource.

是否可以部署特权工作负载？

cat <<EOF | kubectl -n test-defaults apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-privileged
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
    securityContext:
      allowPrivilegeEscalation: true
EOF

嗯... 是的。至少默认的 warn 级别正在工作。

Warning: would violate PodSecurity "restricted:latest": allowPrivilegeEscalation != false (container "busybox" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container "busybox" must set securityContext.capabilities.drop=["ALL"]), runAsNonRoot != true (pod or container "busybox" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container "busybox" must set securityContext.seccompProfile.type to "RuntimeDefault" or "Localhost")
pod/busybox-privileged created

让我们使用 kubectl -n test-defaults delete pod/busybox-privileged 删除 Pod。

我的配置甚至在工作吗？

# if using docker, shell into the control plane
docker exec -it kind-control-plane bash

# cat out the file we mounted
cat /etc/kubernetes/policies/pod-security.yaml

# check the api server logs
cat /var/log/containers/kube-apiserver*.log 

# check the api server config
cat /etc/kubernetes/manifests/kube-apiserver.yaml

更新： 基线策略允许 allowPrivilegeEscalation。虽然我看不到 Pod 安全的默认强制级别，但它们确实存在。让我们尝试提供一个通过请求 hostNetwork 访问来违反基线的清单。

# delete the original pod
kubectl -n test-defaults delete pod busybox-privileged

cat <<EOF | kubectl -n test-defaults apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-privileged
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - sleep
    - "1000000"
  hostNetwork: true
EOF

输出类似于此

Error from server (Forbidden): error when creating "STDIN": pods "busybox-privileged" is forbidden: violates PodSecurity "baseline:latest": host namespaces (hostNetwork=true)

是的！它起作用了！🎉🎉🎉

我后来发现，另一种检查是否按预期运行的方法是检查原始 API 服务器指标端点。

运行以下命令

kubectl get --raw /metrics | grep pod_security_evaluations_total

输出类似于此

# HELP pod_security_evaluations_total [ALPHA] Number of policy evaluations that occurred, not counting ignored or exempt requests.
# TYPE pod_security_evaluations_total counter
pod_security_evaluations_total{decision="allow",mode="enforce",policy_level="baseline",policy_version="latest",request_operation="create",resource="pod",subresource=""} 2
pod_security_evaluations_total{decision="allow",mode="enforce",policy_level="privileged",policy_version="latest",request_operation="create",resource="pod",subresource=""} 0
pod_security_evaluations_total{decision="allow",mode="enforce",policy_level="privileged",policy_version="latest",request_operation="update",resource="pod",subresource=""} 0
pod_security_evaluations_total{decision="deny",mode="audit",policy_level="baseline",policy_version="latest",request_operation="create",resource="pod",subresource=""} 1
pod_security_evaluations_total{decision="deny",mode="enforce",policy_level="baseline",policy_version="latest",request_operation="create",resource="pod",subresource=""} 1
pod_security_evaluations_total{decision="deny",mode="warn",policy_level="restricted",policy_version="latest",request_operation="create",resource="controller",subresource=""} 2
pod_security_evaluations_total{decision="deny",mode="warn",policy_level="restricted",policy_version="latest",request_operation="create",resource="pod",subresource=""} 2

监控工具也可以摄取这些指标，用于报告、评估或衡量趋势。

清理

完成后，删除 kind 集群。

kind delete cluster

审计

审计是另一种跟踪集群中正在强制执行的策略的方式。要使用 kind 设置审计，请查看官方文档以了解启用审计。截至版本 1.11，Kubernetes 审计日志包含两个注释，指示请求是否被授权（authorization.k8s.io/decision）以及决策的原因（authorization.k8s.io/reason）。审计事件可以流式传输到 Webhook 进行监控、跟踪或警报。

审计事件看起来类似于以下内容：

{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":"","pod-security.kubernetes.io/audit":"allowPrivilegeEscalation != false (container \"busybox\" must set securityContext.allowPrivilegeEscalation=false), unrestricted capabilities (container \"busybox\" must set securityContext.capabilities.drop=[\"ALL\"]), runAsNonRoot != true (pod or container \"busybox\" must set securityContext.runAsNonRoot=true), seccompProfile (pod or container \"busybox\" must set securityContext.seccompProfile.type to \"RuntimeDefault\" or \"Localhost\")"}}

审计也是评估你的集群当前是否符合 Pod 安全性的良好第一步。Kubernetes 增强提案 (KEP) 暗示，未来 baseline 可能是未标记命名空间的默认值。

为 Pod 安全事件调整的示例 audit-policy.yaml 配置

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: RequestResponse
  resources:
    - group: "" # core API group
      resources: ["pods", "pods/ephemeralcontainers", "podtemplates", "replicationcontrollers"]
    - group: "apps"
      resources: ["daemonsets", "deployments", "replicasets", "statefulsets"]
    - group: "batch"
      resources: ["cronjobs", "jobs"]
  verbs: ["create", "update"]
  omitStages:
    - "RequestReceived"
    - "ResponseStarted"
    - "Panic"

启用审计后，如果使用 --audit-log-path，请查看配置的本地文件，或者如果使用 --audit-webhook-config-file，请查看 Webhook 的目标。

如果使用文件 (--audit-log-path)，请运行 cat /PATH/TO/API/AUDIT.log | grep "is forbidden:" 以查看所有被拒绝的已审计工作负载。

PSP 迁移

如果你已经在使用 PSP，SIG Auth 创建了一个指南并发布了从 PSP 迁移的步骤。

总结一下该过程

  • 将所有现有的 PSP 更新为非可变
  • 在 warn 或 audit 模式下应用 Pod 安全策略
  • 将 Pod 安全策略升级到 enforce 模式
  • 从 --enable-admission-plugins 中删除 PodSecurityPolicy

SIG Auth 提出了提供一个工具来辅助迁移的想法，该工具被列为“可选的未来扩展”，目前不在范围内。更多详细信息在 KEP 中。

总结

Pod Security 是一项很有前景的新功能，它提供了一种开箱即用的方法，允许用户提高其工作负载的安全性。与任何已成熟为 Beta 的新增强功能一样，我们要求你尝试一下，提供反馈，或者通过提出 Github 问题或加入 SIG Auth 社区会议来分享你的经验。我们希望 Pod Security 能够部署在每个集群上，以作为我们社区为使 Kubernetes 安全成为优先事项而不断努力的一部分。

有关如何使用 Pod 安全准入功能启用“基线”Pod 安全标准的逐步指南，请参阅这些专门的教程，其中涵盖了集群级别和命名空间级别所需的配置。

其他资源