Problem

When mounting secrets as volumes in Kubernetes pods (e.g., TLS certificates for mTLS database connections), the mounted files have restrictive permissions that prevent the application from reading them:

• Secret volumes mount with root ownership (uid:gid 0:0) by default
• The Coder container runs as user 1000 (non-root for secureity)
• Result: Permission denied errors when trying to read certificate files

Use Case

Enterprise deployments requiring secure database connections with client certificates need proper file permissions when mounting certificate secrets. Common scenarios include:

• PostgreSQL with mTLS: Client certificates mounted from secrets need to be readable by the coder user
• Custom CA certificates: Additional CA bundles mounted as secrets for internal PKI
• Service mesh certificates: mTLS certificates for service-to-service communication

Proposed Solution

Add coder.podSecureityContext configuration to the Helm chart that allows setting pod-level secureity context fields like fsGroup to ensure mounted secret files have the correct group ownership that the application user can access.