You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
As far as I can tell, the Data Injection capability requires the container that is being targeted for injection to be running as user 0 (root). Ideally that should not be the case, as it violates standard cluster policies that prevent containers from running as root.
After lots of testing, here is the securityContext that I believe represents the least-privilege for the Data Injection capability. Making it any more secure makes the Data Injection capability break.
Is your feature request related to a problem? Please describe.
As far as I can tell, the Data Injection capability requires the container that is being targeted for injection to be running as user 0 (root). Ideally that should not be the case, as it violates standard cluster policies that prevent containers from running as root.
After lots of testing, here is the securityContext that I believe represents the least-privilege for the Data Injection capability. Making it any more secure makes the Data Injection capability break.
The errors receive are:
Of note is that the desired data IS injected. The errors happen when trying to create the
###ZARF_DATA_INJECTION_MARKER###
file.Describe the solution you'd like
I'm able to use the Data Injection capability without giving my container root. Ideally I'd be able to use this SecurityContext:
(Note: I'm injecting into a mounted PVC. If that weren't the case I wouldn't expect readOnlyRootFilesystem to be able to be
true
)Additional context
link to internal slack conversation
The text was updated successfully, but these errors were encountered: