Init Container permission problem

[oazabir]

The init containers are failing with permission denied when trying to write configuration files:

Error writing to file: open /conf/homeserver.yaml: permission denied

This is affecting:

• ess-synapse-main-0 - render-config container
• ess-matrix-authentication-service - render-config container
• ess-matrix-rtc-sfu - render-config-keys-yaml container

the pods are running as non-root user (10091)
with strict security contexts, but the init containers need to write
configuration files to emptyDir volumes. The fsGroup should handle
this, but it's not working properly.

There's no way to override security context via values.yaml:

# Override security context to allow init containers to write configs
synapse:
  securityContext:
    runAsUser: 0
    runAsGroup: 0
    runAsNonRoot: false
    fsGroup: 0

matrixAuthenticationService:
  securityContext:
    runAsUser: 0
    runAsGroup: 0
    runAsNonRoot: false
    fsGroup: 0

matrixRTC:
  sfu:
    securityContext:
      runAsUser: 0
      runAsGroup: 0
      runAsNonRoot: false
      fsGroup: 0

This does not work. The pods have to be manually patched.

[benbz]

All components allow some configuration of the Pod's securityContext - including all the properties you've specified. This is done through <path to component/sub-component>.podSecurityContext., e.g. synapse.podSecurityContext.{fsGroup,runAsGroup,runAsNonRoot,runAsUser}. ESS Community uses a strict Helm schema, so helm should have informed you the above values are not valid (securityContext is not in the schema and additionalProperties is set to false).

However given all this is done through the Pod's securityContext, the initContainers and containers will be running with the same values and so should all work.

Could you provide some detail of your cluster/environment that may explain why this isn't working?

[oazabir]

I have installed microk8s on a Ubuntu server and then applies the ess helm.

[benbz]

I've quickly installed ESS Community 25.11.1 on an existing microk8s 1.32 cluster I have. My values file only sets the serverName and the various <component>.ingress.host values. It all worked happily without issue.

Are there any particular security modules or hardenings that have been applied to either the underlying Ubuntu server or microk8s itself?

[oazabir]

Thanks for trying. I do not have any customization done. It was a standard microk8s installation where DNS and hostpath add-ons were enabled. However, I have had several attempts of installing Matrix Element Suite using another open source Helm chart. Maybe some of those have changed something in the cluster.

[benbz]

• Can you post the full logs from one of the init-containers that fails after undoing any and all security context changes and deleting the pods?
  • Can you provide a kubectl get pod -o yamlof one of the failingPods` in this case
• Is SELinux or AppAmor in use on the underlying Ubuntu server?
• Anything interesting been done with quotas or ACLs on the filesystems on the server?