Weaviate Deployment not possible due to Azure Policies

Hello everyone,

when deploying Weaviate in our Azure Kubernetes Cluster, two policies currently prevent the weaviate container “configure-sysctl” from being created/started.

Policies:

  1. Kubernetes cluster should not allow container privilege escalation
  2. Kubernetes cluster should not allow privileged containers

Does someone know what this container is doing and if it is essential? Why does it not fulfill these privileges?

  • Deployment Method: Helm Chart

Thanks for your help!

hi @Ines !! Welcome to our community :hugs:

We have recently added support for unprivileged docker image in our helm.

Have you tried that option?

Not sure it can help here, but it definitely seems related :thinking:

Let me know if that helps.

THanks!

Thanks @DudaNogueira for the help.
Sharing it for others what changes worked for us.
In values.yaml we set the below properties.

initContainers:
  sysctlInitContainer:
    enabled: false
 ensureFileOwnershipContainer:
   enabled: true

containerSecurityContext:
  runAsUser: 1000
  runAsGroup: 1000
  fsGroup: 1000
  fsGroupChangePolicy: "OnRootMismatch"
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  privileged: false
  readOnlyRootFilesystem: true

securityContext:
  runAsUser: 1000
  runAsGroup: 1000
  fsGroup: 1000
  fsGroupChangePolicy: "OnRootMismatch"
  runAsNonRoot: true
  allowPrivilegeEscalation: false
  privileged: false
  readOnlyRootFilesystem: true

Not sure what is the impact of disabling sysctlInitContainer init containers(not setting vm.max_map_count and vm.overcommit_memory).

Thanks for sharing!!!

I have edited your topic to format it better and marked and a solution!

Thanks!

Thank you @DudaNogueira and @dassum a lot for your help.

@DudaNogueira Unfortunately. This did not help.
But we would like to try the option @dassum mentioned. However, before doing so, does anyone know what the “sysctlInitContainer” is used for?

Hi @Ines !!

Check here the info for this option:

for instance:

# it is possible to change the sysctl's 'vm.max_map_count' using initContainer for Weaviate,
# the init Container runs before Weaviate Container and sets the value for the WHOLE node
# to the one provided below.
# it is possible to run additional initContainer before Weaviate is up and running. You can specify the
# containers as a list in `extraInitContainers`, exactly how they are defined in a kubernetes manifest:
#   https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
1 Like

@DudaNogueira Thank you again for your help. I checked also with my colleagues. Problem is still, that we do not know what this container is doing and therefore we don’t want to just disable it.
Any idea how to find out what this privileged container is doing?

hi! AFAIK, this is not a container, but this will define some configuration to the container running Weaviate.

Hi! @DudaNogueira What configurations will be changed then by doing so?

Hi!

Those settings, as fair as I could understand, will run a init container to just set the proper ownerships if this deployment didn’t have the security context.

I believe for new deployments ensureFileOwnershipContainer may not be required.

# it is possible to change the sysctl's 'vm.max_map_count' using initContainer for Weaviate,
# the init Container runs before Weaviate Container and sets the value for the WHOLE node
# to the one provided below.
# it is possible to run additional initContainer before Weaviate is up and running. You can specify the
# containers as a list in `extraInitContainers`, exactly how they are defined in a kubernetes manifest:
#   https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
initContainers:
  sysctlInitContainer:
    enabled: true
    sysctlVmMaxMapCount: 524288
    image:
      registry: docker.io
      repo: alpine
      tag: latest
      pullPolicy: IfNotPresent
  ensureFileOwnershipContainer:
    # This init container sets the file ownerships of /var/lib/weaviate directory to the ones set in
    # containerSecurityContext.runAsUser and containerSecurityContext.fsGroup settings to ensure that Weaviate is able
    # to start in unprivileged configuration.
    # Enable this init container only if Weaviate was configured previously without security context
    # and now containerSecurityContext is provided to run Weaviate container with non-root user.
    # Please be sure to set at least containerSecurityContext.runAsUser and containerSecurityContext.fsGroup.
    enabled: false