-
Notifications
You must be signed in to change notification settings - Fork 146
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
sysctl init container doesn"t have privileges #239
Comments
@alexku7 Can you throw me the commit where this was changed? I'm not entirely sure why this would have been removed in the first place. |
Hi @DandyDeveloper Line number 126 in the previous file version |
Is there a plan to separate out the securityContext for each container? |
I've neglected this a little bit because I'm currently getting ready to move back to my home country. Let me try and sneak some fixes in and some requests next week. |
in case anyone is waiting on this one Here is the Kustomization patches you can use to workaround this patches:
- target:
version: v1
kind: StatefulSet
name: ppw-redis-ha-server
patch: |-
- op: replace
path: /spec/template/spec/initContainers/0/securityContext/capabilities
value: {}
- op: replace
path: /spec/template/spec/initContainers/0/securityContext/runAsUser
value: 0
- op: replace
path: /spec/template/spec/initContainers/0/securityContext/runAsNonRoot
value: false
- op: replace
path: /spec/template/spec/initContainers/0/securityContext/privileged
value: true
- op: replace
path: /spec/template/spec/initContainers/0/securityContext/allowPrivilegeEscalation
value: true |
@maxisam You can also use chart's built in features - sysctlImage:
enabled: false
extraInitContainers:
- name: init-sysctl
image: <IMAGE>
volumeMounts:
- name: host-sys
mountPath: /host-sys
command:
- /bin/sh
- -xc
- |-
sysctl -w net.core.somaxconn=10000
echo madvise > /host-sys/kernel/mm/transparent_hugepage/enabled
securityContext:
runAsNonRoot: false
privileged: true
runAsUser: 0
containerSecurityContext:
allowPrivilegeEscalation: true
capabilities:
drop:
- ALL
runAsNonRoot: true
seccompProfile:
type: RuntimeDefault
extraVolumes:
- name: host-sys
hostPath:
path: /sys
|
up :) the using of the extraInitContainers not always possible due to some limitations :( |
Hello
Recently , the hard coded securityContext has been removed from the sysctl init container.
As result the sysctl runs in the same context as the redis itself without the ability to change it only for the sysctl Init container.
As result the sysCtl is unable to set various system/kernel flags ( for example: sysctl -w net.core.somaxconn=10000)
Can we add an ability to set a separate security context for the sysCtl init container ?
The text was updated successfully, but these errors were encountered: