Update default container security context

[ChenYi015]

Purpose of this PR

Proposed changes:

• Update default container security context

Change Category

Indicate the type of change by marking the applicable boxes:

• [ ] Bugfix (non-breaking change which fixes an issue)
• [x] Feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that could affect existing functionality)
• [ ] Documentation update

Rationale

Checklist

Before submitting your PR, please review the following:

• [x] I have conducted a self-review of my own code.
• [ ] I have updated documentation accordingly.
• [ ] I have added tests that prove my changes are effective or that my feature works.
• [ ] Existing unit tests pass locally with my changes.

Additional Notes

[ChenYi015]

/assign @jacobsalway @ImpSy

[jacobsalway]

Might need to do some investigation to map out all the disk usage of spark-submit but what are your thoughts on also using an emptyDir volume in the controller and adding readOnlyRootFilesystem: true as well?

Might not be worth it if this isn't a common Kubernetes cluster security requirement in the same way that running as non-root and dropping all capabilities are.

Related PR: https://github.com/kubeflow/spark-operator/pull/2219

[ImpSy]

Might need to do some investigation to map out all the disk usage of spark-submit but what are your thoughts on also using an emptyDir volume in the controller and adding readOnlyRootFilesystem: true as well?

Yeah I feel like readOnlyRootFilesystem is a bit too restrictive especially while we are actively modifying the usage of the controller with pod templates

But like the PR #2219 propose we could mount a volume on /tmp and use os.CreateTemp everytime we need a local file

[jacobsalway]

Could push the user and group directives down to the Dockerfile rather than the container security context. I'm not sold on read-only FS because any temporary disk usage that isn't on a volume could cause a panic but it's an enhancement we can make later down the line if requested/it's a common security requirement or implemented in the other PR.

[ChenYi015]

Could push the user and group directives down to the Dockerfile rather than the container security context. I'm not sold on read-only FS because any temporary disk usage that isn't on a volume could cause a panic but it's an enhancement we can make later down the line if requested/it's a common security requirement or implemented in the other PR.

I have pushed the user and group directives down to the Dockerfile. Agree on that we would better implement the readOnlyRootFileSystem in a dedicated PR.

[ChenYi015]

/approve

[google-oss-prow[bot]]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ChenYi015, jacobsalway

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• ~~OWNERS~~ [ChenYi015]

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment

[cccsss01]

Might need to do some investigation to map out all the disk usage of spark-submit but what are your thoughts on also using an emptyDir volume in the controller and adding readOnlyRootFilesystem: true as well?

Yeah I feel like readOnlyRootFilesystem is a bit too restrictive especially while we are actively modifying the usage of the controller with pod templates

But like the PR #2219 propose we could mount a volume on /tmp and use os.CreateTemp everytime we need a local file

majority of these local files created don't need to be stored permanently correct?