sysctl init container doesn"t have privileges

[alexku7]

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 ?

[DandyDeveloper]

@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.

[alexku7]

Hi @DandyDeveloper Sure https://github.com/DandyDeveloper/charts/commit/7fe673e5c9e1ef3be2f2f21302322db62488fa0d#diff-7197ebaebe181f0077ae6cc761a1b2173dd7963340f628217a8a68f425784d46L126

Line number 126 in the previous file version

[j771]

Is there a plan to separate out the securityContext for each container? Currently it looks like you can only set haproxy and redis securityContext (all init containers for redis use the same securityContext).

[DandyDeveloper]

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.

[maxisam]

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

[silvpol]

@maxisam You can also use chart's built in features - extraInitContainers, containerSecurityContext.allowPrivilegeEscalation: true and extraVolumes to replicate the old behaviour

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

[alexku7]

up :)

the using of the extraInitContainers not always possible due to some limitations :(