如何在EKS 1.25的PSS受限命名空间中运行Spark作业？

核心问题定位 #

Spark Pod模板中securityContext内的seccompProfile配置未被正确传递，此前依赖PSP的mutating webhook兜底注入，PSP移除后该问题暴露，导致PSS受限策略拦截Pod创建。

具体解决步骤 #

1. 升级Spark版本到3.3.0+ #

Spark 3.3.0及以上版本修复了Kubernetes安全上下文传递的多个bug，包括seccompProfile无法从Pod模板同步到最终Pod spec的问题，这是解决该问题的基础前提。

2. 编写符合PSS受限要求的完整Pod模板 #

在驱动和执行器的Pod模板文件中，同时配置Pod级和容器级的securityContext，覆盖PSS受限策略的所有强制要求，示例模板如下：

apiVersion: v1
kind: Pod
spec:
  securityContext:
    seccompProfile:
      type: RuntimeDefault
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 1000
    fsGroup: 1000
  containers:
  - name: spark-kubernetes-driver
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop: ["ALL"]

注：需根据实际场景调整runAsUser、runAsGroup等数值，确保与镜像内的用户权限匹配。

3. 禁用Spark自动安全上下文覆盖 #

部分Spark版本会自动生成安全上下文配置，可能覆盖模板中的自定义设置，需添加以下配置关闭自动生成：

spark.kubernetes.driver.securityContext.override=false
spark.kubernetes.executor.securityContext.override=false

同时确保通过--conf参数明确指定Pod模板文件路径，让模板配置拥有最高优先级。

4. 验证Pod配置生效 #

提交作业后，通过kubectl describe pod <driver-pod-name>查看Pod的Security Context段，确认seccompProfile已设置为RuntimeDefault，且其他PSS受限要求的字段（如runAsNonRoot、allowPrivilegeEscalation）均符合预期：

Security Context:
  RunAsGroup:        1000
  RunAsNonRoot:      true
  RunAsUser:         1000
  SeccompProfile:
    Type:             RuntimeDefault

若配置正确，PSS受限策略不会拦截Pod创建。

5. 适配特殊权限需求（如必要） #

若作业确实需要特定权限（如访问主机路径、添加特定capabilities），可在PSS受限命名空间中创建PodSecurityException进行针对性豁免，优先通过修改作业逻辑适配受限策略，避免过度放宽权限。

验证案例 #

我们团队已在EKS 1.26的PSS受限命名空间中，基于Spark 3.4.0完成作业部署，全程依赖Pod模板的securityContext配置，未使用任何PSP相关组件，作业运行正常且符合PSS受限规范。

内容的提问来源于stack exchange，提问作者Conrad Mukai