Skip to content

proton-bridge: default security context for uid/gid 1000 #4

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
mgarratt merged 1 commit into from
Feb 15, 2026
Merged

proton-bridge: default security context for uid/gid 1000 #4

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion charts/proton-bridge/Chart.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2,5 +2,5 @@ apiVersion: v2
name: proton-bridge
description: Proton Mail Bridge deployment for in-cluster SMTP/IMAP access
type: application
version: 0.1.5
version: 0.1.6
appVersion: "3.22.0"
11 changes: 8 additions & 3 deletions charts/proton-bridge/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -94,7 +94,6 @@ Common overrides:
- `bridge.host`, `bridge.smtpPort`, `bridge.imapPort`
- `container.smtpPort`, `container.imapPort`
- `container.enablePrivilegedPortBinding`
- `podSecurityContext.fsGroup`
- `containerSecurityContext`
- `volumePermissions.enabled`
- `existingSecret`
Expand All @@ -110,11 +109,17 @@ container:

## Troubleshooting Startup Permission Errors

If the container cannot write under `/home/bridge` at startup, set a pod `fsGroup` so Kubernetes adjusts volume group ownership:
By default, the chart runs the container as uid/gid `1000:1000` and sets pod `fsGroup: 1000`, matching the current image defaults.

If you need different ownership semantics for your storage class, override the security contexts:

```yaml
podSecurityContext:
fsGroup: 1000
fsGroup: 1001

containerSecurityContext:
runAsUser: 1001
runAsGroup: 1001
```

If your storage backend still needs explicit ownership fixes, enable the permissions init container:
Expand Down
15 changes: 10 additions & 5 deletions charts/proton-bridge/values.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -37,11 +37,16 @@ container:
# Set true to add NET_BIND_SERVICE capability so non-root process can bind <1024 (e.g. 25/143).
enablePrivilegedPortBinding: false

# Pod-level security context (for example: fsGroup to allow writing mounted volumes).
podSecurityContext: {}

# Container-level security context for the main proton-bridge container.
containerSecurityContext: {}
# Pod-level security context defaults for the bridge image user (uid:gid 1000:1000).
podSecurityContext:
fsGroup: 1000
fsGroupChangePolicy: OnRootMismatch

# Container-level security context defaults for the bridge image user (uid:gid 1000:1000).
containerSecurityContext:
runAsNonRoot: true
runAsUser: 1000
runAsGroup: 1000

# Optional init container to force volume ownership/permissions before bridge starts.
volumePermissions:
Expand Down