[Upgrade to 3.52.1-stable] Code executor failed: Failed to apply iptables rules to disallow link-local addresses

Self Hosted Retool
1

Hi team,

Here's my first post on the community forum! On my self-hosted Retool stack on Kubernetes, deployed through the Helm chart version 6.2.0, I just tried to upgrade to the new 3.52.1-stable tag and I'm seeing an error in the code-executor pod which was working well before.

The pod does not have privileged access but it was working fine with 3.33.24-stable.

Here's the full pod log that falls into CrashLoopBackOff

Running code executor container in privileged mode.
iptables: Disallowing link-local addresses
owner: Could not determine whether revision 1 is supported, assuming it is.
iptables v1.8.7 (legacy): can't initialize iptables table `filter': Permission denied (you must be root)
Perhaps iptables or your kernel needs to be upgraded.
owner: Could not determine whether revision 1 is supported, assuming it is.
iptables v1.8.7 (legacy): can't initialize iptables table `filter': Permission denied (you must be root)
Perhaps iptables or your kernel needs to be upgraded.
Failed to apply iptables rules to disallow link-local addresses. Set the DISABLE_IPTABLES_SECURITY_CONFIGURATION environment variable.

I could not find in trace of DISABLE_IPTABLES_SECURITY_CONFIGURATION env var on the web and tried to set it to "true" but result is the same.

The codeExecutor part of my Helm chart values:

codeExecutor:
  # enabled by default from Chart version 6.0.15 and Retool image 3.20.15 onwards
  # explicitly set other fields as needed

  enabled: true

  replicaCount: 1

  # Annotations for code executor pods
  annotations: {}

  # Labels for code executor pods
  labels: {}

  # Config for code executor. Node heap size limits can be overridden here
  config: {}
  # config: {
  #   nodeOptions: --max_old_space_size=1024
  # }
  volumes: {}
  volumeMounts: {}

  # Config affinity and anti-affinity rules for the code executor pods
  affinity: {}

  # Resources for the code executor. Most common issues will be seen with CPU usage as this will
  # most likely be CPU bound. Adjust the CPU if latency increases under load.
  resources:
    limits:
      cpu: 2000m
      memory: 2048Mi
    requests:
      cpu: 1000m
      memory: 1024Mi

  # code executor uses nsjail to sandbox code execution. nsjail requires privileged container access.
  # If your deployment does not support privileged access, you can set `privileged` to false to not
  # use nsjail. Without nsjail, all code is run without sandboxing within your deployment.
  securityContext:
    privileged: false

  image:
    repository: tryretool/code-executor-service
    # defaults to image.tag if >= 3.20.15, otherwise defaults to 1.1.0; explicitly set to override.
    # tag:
    pullPolicy: IfNotPresent

Could you please help me?

1 Like
2

I had the same issue but it was even following later 3.33 stable releases. I managed to find a solution this morning.

The error message about DISABLE_IPTABLE_SECURITY_CONFIGURATION is misleading as it appears the containers don't honor that env var. I was able to find reference to a variable: CONTAINER_UNPRIVILEGED_MODE
Setting this variable to "true" lead to another error about not running as the expected retool_user and I was able to change the containers runtime user using the security context block.

So TLDR on what worked for me: env var CONTAINER_UNPRIVILEGED_MODE: "true" and on the codeExecutor block in values.yml

securityContext:
    privileged: false
    runAsUser: 1001
    runAsGroup: 1001
1 Like
3

Thank you @ndpete ! Worked like a charm.