Comments (7)
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.
Can you provide some more context, please?
-
Are you talking about Brigade v1 or v2?
-
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.
-
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.
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.
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:
-
No.
-
Sorry, i think that was my mistake. The link was unnecessary now that I think about it.
-
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.
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.
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.
Yes, can we have this in V2 then?
from brigade.
Related Issues (20)
- Add instrumentation to give insight into API request volume
- CI/CD: Wait for Docker port to be open HOT 6
- bug: InvalidImageName not handled correctly
- Update homebrew formula for v2.4.0 HOT 3
- bug: wrong error creating event for project that doesn't exist HOT 3
- Brigade 2.x - Support for PVCs in jobs HOT 4
- bug: if worker uses shared workspace, it's mounted read only, but shouldn't be
- brig update -c fails if project doesn't exist and not logged in as root HOT 9
- bug: new git-initializer cannot check out specific commits that aren't in the default branch HOT 1
- git-initializer component does not work with repos hosted on Azure DevOps HOT 2
- docs home page needs updating HOT 2
- bug: if -c flag is set on `brig project update`, we're not checking for create permission HOT 2
- token auth filter should not be picky about case of word "Bearer" in auth header
- implement a strategy for testing against a live database
- check for whether new user should be an admin should be case insensitive HOT 1
- Readnext documentation page bad links
- Fix [Brigade Developers Guide] Link on topics/index docs page
- Brigade is now a CNCF Archived project: update website, etc HOT 4
- Netlify: select a new build image HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
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.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from brigade.