-
Notifications
You must be signed in to change notification settings - Fork 111
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Helm chart: allow unprivileged deployment of Beyla #1128
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1128 +/- ##
==========================================
+ Coverage 73.06% 82.01% +8.94%
==========================================
Files 139 140 +1
Lines 11553 11562 +9
==========================================
+ Hits 8441 9482 +1041
+ Misses 2454 1555 -899
+ Partials 658 525 -133
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Amazing! Thanks for this.
Waiting for someone else to bring a second pair of eyes before merging.
charts/beyla/values.yaml
Outdated
@@ -59,13 +59,22 @@ podSecurityContext: {} | |||
# fsGroup: 2000 | |||
|
|||
securityContext: | |||
# -- For an unprivileged / less privileged setup, use privileged: false and uncomment the required capabilities in the values file. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we instead of make users uncomment this add them conditionally?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is absolutely possible. In that case I would propose the following:
We don't use the condition based on securityContext.privileged
anymore, instead we add a top-level attribute called privileged
and set it by default true which results in the setup like before. If this is set to false
, we set the securityContext how it needs to be.
In order to make adding the capabilities SYS_RESOURCE
and SYS_ADMIN
optional, because they are not always required, we can add a property extraCapabilities
that allows for adding those two if needed and other ones.
The only 'downside' I see from this approach is that the control over securityContext is removed from the user once the new privileged
attribute is set to false. But I would almost say that is okay, seeing as an unprivileged setup requires a very specific set of configurations to work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds reasonoble to me @marevers ! thanks
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I will make the required changes and push and then re-request review.
* Make privileged optional, add required conditions for the unprivileged / less privileged setup * Update README, bump Beyla version to 1.8.0 and chart version to 1.4.0 * Fix conditions * Make securityContext setup conditional based on new privileged attribute * Fix comments failing validation
Closes #1075
This PR adds a new property
privileged
which can be set tofalse
to add the required configurations to the DaemonSet (based on the unprivileged example).Chart version is increased to 1.4.0 and app version to 1.8.0.