This is an automated email from the ASF dual-hosted git repository.
dongjoon-hyun pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/spark-kubernetes-operator.git
The following commit(s) were added to refs/heads/main by this push:
new 4a00f01 [SPARK-57494] Add `Pod Security Admission` section to
`SECURITY.md`
4a00f01 is described below
commit 4a00f012a5301b31eb82f891eac078ddba04aa2d
Author: Dongjoon Hyun <[email protected]>
AuthorDate: Tue Jun 16 15:03:36 2026 -0700
[SPARK-57494] Add `Pod Security Admission` section to `SECURITY.md`
### What changes were proposed in this pull request?
Add a **Pod Security Admission** section to `SECURITY.md` documenting that
the security posture of user-supplied pod templates is enforced by the
Kubernetes API server, not the operator:
- Administrators set the [Pod Security
Admission](https://kubernetes.io/docs/concepts/security/pod-security-admission/)
level on workload namespaces; it applies to every pod the operator launches.
- The pod template is the only place to set a pod's security context, so
meeting a stricter level requires supplying one. This covers `SparkApplication`
(`.spec.driverSpec/executorSpec.podTemplateSpec`) and `SparkCluster`
(`.spec.masterSpec/workerSpec.statefulSetSpec.template`).
### Why are the changes needed?
The operator passes pod templates through unchanged, which is what lets
users satisfy stricter Pod Security Admission levels. Documenting this
clarifies that pod security is a Kubernetes responsibility, not a missing
operator control.
### Does this PR introduce _any_ user-facing change?
No. Documentation only.
### How was this patch tested?
Documentation-only change; no code is affected.
### Was this patch authored or co-authored using generative AI tooling?
Generated-by: Claude Code (Claude Opus 4.8)
Closes #709 from dongjoon-hyun/SPARK-57494.
Authored-by: Dongjoon Hyun <[email protected]>
Signed-off-by: Dongjoon Hyun <[email protected]>
---
SECURITY.md | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/SECURITY.md b/SECURITY.md
index 51419b0..8ccb12a 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -11,3 +11,21 @@ This repository extend K8s resource manager to manage Apache
Spark applications
<https://spark.apache.org/docs/latest/security.html>
Automated security scanning agents should consult that document for the
project's in-scope / out-of-scope declarations before reporting issues.
+
+## Pod Security Admission
+
+Cluster administrators should label workload namespaces with the desired
+[Pod Security
Admission](https://kubernetes.io/docs/concepts/security/pod-security-admission/)
level.
+The chosen level is enforced by the Kubernetes API server on every pod the
operator launches,
+whether or not a pod template is supplied. The pod template is, however, the
only place to set the
+pods' security context: Spark's default pods omit the fields that stricter
profiles require (`runAsNonRoot`,
+`allowPrivilegeEscalation: false`, `capabilities.drop: [ALL]`,
`seccompProfile`), so running under a
+stricter level requires supplying a pod template that carries them. A pod that
does not meet the
+enforced level is rejected by the API server, so the pods never start and the
workload fails to
+launch.
+
+The operator passes these pod templates through unchanged. For a
`SparkApplication`, the driver and
+executor pods come from `.spec.driverSpec.podTemplateSpec` and
`.spec.executorSpec.podTemplateSpec`,
+mirroring Apache Spark's native
`spark.kubernetes.[driver/executor].podTemplateFile` feature. For a
+`SparkCluster`, the master and worker pods come from the StatefulSet pod
templates
+`.spec.masterSpec.statefulSetSpec.template` and
`.spec.workerSpec.statefulSetSpec.template`.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
