gorse-runasnonroot-failure

Gorse runAsNonRoot Container Failure

Problem

Gorse recommendation engine containers (master, server, worker) crash immediately on startup when running with Kubernetes runAsNonRoot: true and a custom UID like 65532.

Context / Trigger Conditions

• Gorse pods show CrashLoopBackOff or Error status
• Pod logs show:

  {"level":"fatal","ts":...,"caller":"model/built_in.go:95","msg":"failed to get user directory","error":"user: unknown userid 65532"}
  

• Deployment has securityContext.runAsNonRoot: true and runAsUser: 65532
• Using official gorse images (zhenghaoz/gorse-master, zhenghaoz/gorse-server, zhenghaoz/gorse-worker)

Root Cause

The gorse codebase calls Go's os.UserHomeDir() during initialization in model/built_in.go. This function requires the running UID to have an entry in /etc/passwd. When running as a non-root user that doesn't exist in the container's passwd file, the lookup fails.

Solution

Remove the runAsNonRoot and runAsUser constraints from the pod security context:

# Before (broken)
spec:
  template:
    spec:
      securityContext:
        runAsNonRoot: true
        runAsUser: 65532
        fsGroup: 65532

# After (working)
spec:
  template:
    spec:
      securityContext:
        fsGroup: 1000

Apply to all gorse deployments:

• deployment-master.yaml
• deployment-server.yaml
• deployment-worker.yaml
• init-db-job.yaml (if using init job)

Verification

After updating the security context:

1. Delete existing crashing pods: kubectl delete pods -l app.kubernetes.io/name=gorse -n gorse
2. Wait for new pods to start
3. Check logs: kubectl logs -l app=gorse-master -n gorse
4. Verify master shows connection to data store and cache store

Notes

• This is a limitation of the official gorse images, not a Kubernetes issue
• The gorse project may fix this in future versions by not requiring home directory
• If security policy requires non-root, you would need to build custom gorse images with proper /etc/passwd entries for the desired UID
• Redis Stack images used for gorse cache have the same issue with UID 65532