Giter Club home page Giter Club logo

Comments (7)

krancour avatar krancour commented on June 26, 2024 1

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.

from brigade.

krancour avatar krancour commented on June 26, 2024

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.

from brigade.

krancour avatar krancour commented on June 26, 2024

Without more detail, I am closing this.

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

from brigade.

kaiyuanlim avatar kaiyuanlim commented on June 26, 2024

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

from brigade.

krancour avatar krancour commented on June 26, 2024

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.

from brigade.

krancour avatar krancour commented on June 26, 2024

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.

from brigade.

kaiyuanlim avatar kaiyuanlim commented on June 26, 2024

Yes, can we have this in V2 then?

from brigade.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.