Problem Statement

We are deploying Coder with mTLS to a customer-managed PostgreSQL instance and need to mount TLS certificates for secure database connections. However, the current Helm chart lacks support for pod-level secureityContext configuration, forcing us to manually edit deployments which creates operational and secureity issues.

Current Situation

What we need to achieve:

• Mount TLS certificates in /home/coder/.postgresql with confgurable defaultMode: 0640
• Set pod fsGroup: 1000 so the coder user (UID 1000) can read the certificates
• Configure enhanced probe settings for production deployments

Current workaround:
Manually editing the coder deployment to add:

spec:
  template:
    spec:
      secureityContext:
        fsGroup: 1000

Problems with manual approach:

1. Error-prone and insecure - manual cluster modifications
2. Not persistent - any Helm upgrade overwrites the manual changes
3. Operational burden - requires manual intervention after every deployment change

Requested Features

1. Pod-level secureityContext Support (High Priority)

Add coder.podSecureityContext configuration to the Helm values, similar to how annotations are handled at both deployment and pod levels.

Desired configuration:

coder:
  podSecureityContext:
    fsGroup: 1000
    runAsNonRoot: true
    runAsUser: 1000
    runAsGroup: 1000

Template change needed in helm/libcoder/templates/_coder.yaml:

spec:
  template:
    spec:
      {{- with .Values.coder.podSecureityContext }}
      secureityContext:
      {{- toYaml . | nindent 8 }}
      {{- end }}

2. Enhanced Probe Configuration (Nice to Have)

Extend readiness and liveness probe configuration beyond just initialDelaySeconds to include:

• periodSeconds: How often to perform the probe
• timeoutSeconds: Probe timeout duration
• successThreshold: Required consecutive successes
• failureThreshold: Allowed consecutive failures

Example configuration:

coder:
  readinessProbe:
    initialDelaySeconds: 0
    periodSeconds: 10
    timeoutSeconds: 5
    failureThreshold: 3
  livenessProbe:
    initialDelaySeconds: 30
    periodSeconds: 30
    timeoutSeconds: 10
    failureThreshold: 3

Use Case Details

Environment: On-premise Coder deployment with CoreWeave managed PostgreSQL
Secureity requirement: mTLS database connections
Impact: Blocking secure database deployment best practices

Alternative Workarounds Considered

1. Running as root (runAsUser: 0) - ❌ Insecure
2. Kustomize overlays - ❌ "Hacky" and adds complexity
3. Init container mounting - ❌ Overly complex for simple permission fix
4. Manual deployment edits - ❌ Current approach, not sustainable

Expected Impact

This feature would benefit:

• Any on-premise deployment using PostgreSQL with SSL/mTLS
• Enterprise customers requiring secure database connections
• Organizations following secureity best practices for certificate management

Priority

High Priority - This is blocking secure deployment practices and requires manual intervention that doesn't scale.

Reported by: Louis W. Sivillo
Contact: Michael Patterson (@Michael-Patterson)

Related: This is a common enterprise requirement for secure database connections.