[feature] Allow setting securityContext (privileged) for container component pods

[zswf-mle]

Feature Area

What feature would you like to see?

Allow users to configure Kubernetes securityContext (for example privileged: true, allowPrivilegeEscalation...) for user runtime pods created by @dsl.container_component using .set_security_context function.

What is the use case or pain point?

Some valid workloads require privileged containers, such as:

• BuildKit (buildctl-daemonless.sh) for building container images
• Dockerless image builds
• Low-level system tooling
• Kernel-adjacent workloads

Currently, these workloads cannot run inside Kubeflow Pipelines, even though:

• Kubernetes supports privileged pods
• Argo Workflows supports privileged pods
• The same containers work correctly when run as standalone Kubernetes pods

This limitation blocks legitimate production use cases and forces users to bypass Kubeflow Pipelines.

Is there a workaround currently?

No clean workaround exists today.

---

Love this idea? Give it a 👍.

[AnupamSingh2004]

Hi, I'd like to work on this feature request.

Proposed Implementation

Proto Schema (kubernetes_platform/proto/kubernetes_executor_config.proto)

• Add a SecurityContext message with fields: privileged, allow_privilege_escalation, run_as_user, run_as_group, run_as_non_root, and read_only_root_filesystem
• Add the new message as a field in KubernetesExecutorConfig

Python SDK (kubernetes_platform/python/kfp/kubernetes/)

• Create security_context.py with a set_security_context() function following existing patterns
• Export the function from __init__.py

Go Backend (backend/src/v2/driver/k8s.go)

• Extend extendPodSpecPatch to apply security context settings to the container spec

Tests

• Add unit tests for Python SDK and Go backend

Questions

1. Should I include support for additional fields like capabilities, seLinuxOptions, and seccompProfile in the initial implementation, or would you prefer to start with the core fields and extend in follow-up PRs?
2. Are there any specific validation requirements or security considerations I should be aware of?

Happy to adjust the approach based on feedback
Thanks

[droctothorpe]

That sounds like a great plan, @AnupamSingh2004!

WRT your questions:

1. I think it's okay to include additional fields in the same PR.
2. If there are existing large / e2e tests that validate kfp-kubernetes functionality, I recommend amending those to include tests for this feature as well.

My only concern, and it's probably a lengthier discussion that should happen independent of this PR is this: to what extent are we rewriting the K8s interface? At what point does it make more sense to make all this kind of stuff path through and expect someone who is knowledgeable enough to have to set a security context to be capable of using the python kubernetes client? CC @mprahl curious to hear your thoughts.

[AnupamSingh2004]

Thanks @droctothorpe for the feedback

I'll proceed with the implementation including the full SecurityContext spec:

• privileged
• allowPrivilegeEscalation
• runAsUser / runAsGroup / runAsNonRoot
• readOnlyRootFilesystem
• capabilities (add/drop)
• seLinuxOptions
• seccompProfile

I'll also look into the existing e2e tests under kubernetes_platform/ and add coverage for this feature.

For now, I'll follow the existing patterns in the codebase. Happy to adapt if there's guidance on the broader K8s interface discussion.

I'll open a PR soon. Thanks

/assign