Need support for adding security context

[kaiyuanlim]

• Would be nice to have security context configurable for the job.
• Use case for me was to add the uid for issues like https://github.com/actions/checkout/issues/760
• Also wanted to enforce nonroot

[krancour]

Can you provide some more context, please?

1. Are you talking about Brigade v1 or v2?

2. I'm unclear how the GitHub Action you have referenced is relevant to Brigade in any way. Was it meant only to be an example of an error that could potentially occur? If Brigade can be compelled to make a similar error occur, please provide a minimal example that reproduces it.

3. Can you clarify what you mean by "enforce nonroot?" Specifically, I think there are a few different ways to interpret the word "enforce." Are you asking for a. The ability to specify which user to run as OR b. The ability to simply set a "policy" that the job must NOT run as root? Those are two different things and I want to be clear on which you are asking for. As with the minimal example for no. 2 above, a small bit of script here that demonstrates how you image this working might make the request more clear.

[krancour]

Without more detail, I am closing this.

@kaiyuanlim please do feel free to re-open the issue if you want to provide more detail.

[kaiyuanlim]

Sure.

Context: I am enforcing security context via OPA policy https://www.openpolicyagent.org/ And I am enforcing nonroot security context as well as read only for root file system.

About your question:

1) No.

2) Sorry, i think that was my mistake. The link was unnecessary now that I think about it.

3) So, with OPA policy, we can enforce that the pods are required to have specific fields set to it. And currently, I want to enforce that the pod should have security context like: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods

So, would be nice if this has a field for security context of the pod

[krancour]

I'm still not clear if this question is in reference to Brigade v1 or v2. v1's EOL is approaching in about 1 month, so new features are off the table. We could see what can be done about this in v2.

v2 carefully abstracts k8s for end users, so it's really only the operator who configures/installs Brigade who's meant to interact directly with the cluster. So instead of modifying Brigadier to allow security context to be directly set on jobs, it probably make more sense to add a policy section (or something like that) to the chart's values.yaml file. The operator who configures and installs Brigade could optionally define a security context that Brigade should apply to all workers and jobs -- and would basically do so with no guarantees. i.e. If you get it wrong, it might not work.

That seems fairly doable and it's something I'd be happy to work on if you're willing to help vet the approach and test drive the feature.

[krancour]

Thinking about this more, there's probably some potential to specify something like what user or userid a job (or one of its containers) should run as without fully exposing a Kubernetes pod/container security context. That could add useful functionality without undermining the abstraction.

[kaiyuanlim]

Yes, can we have this in V2 then?

[krancour]

Tentatively. It's going to require some experimentation and design so that we land in a good place.

For now, I'm relocating this issue to the main Brigade repo.