Repository navigation
Security Context is Not Set in Init Container #1370
Description
BlueAPI's .Values.securityContext is only applied to the main container, not the init container. (I suspect) this means that the init and main containers can run as different users, root or non root, etc.
This seems to be causing issues, such as scratch dependencies downloaded by the init container not being modifiable by the main container (see #1363). It also makes some issues unreproducible due to not being able to choose the UID of the init container (see #1308 which could only be reproduced if the init container ran as non-1000).
Propagating the security context is easy, but I'm nervous that this may have unforeseen consequences.
Acceptance Criteria
- Init container's security context can be set via
.Values
Activity
abbiemery commentedon Feb 26, 2026
@dan-fernandes is this still an issue after #1322 and #1336?
dan-fernandes commentedon Mar 2, 2026
PRs #1322 and #1336 were fixes to a problem that I suspect was caused by this (but that were a better solution than propagating the security context).
As the lack of security context propagation is not currently causing any issues, I think this can be closed.
If there are errors in the future that stem from this, we can revisit.
dan-fernandes commentedon Mar 2, 2026
If the security context does ever get propagated, it is worth looking at #1096.
The initContainer may not be function if it inherits
readOnlyRootFilesystemfix: Propogate securityContext to initContainer (#1444)