Skip to content

Enable TLS/HTTPS via Kubernetes Secret mounting - #11

Open
geekosphere-net wants to merge 2 commits into
maildev:mainfrom
geekosphere-net:fix/https-config
Open

Enable TLS/HTTPS via Kubernetes Secret mounting#11
geekosphere-net wants to merge 2 commits into
maildev:mainfrom
geekosphere-net:fix/https-config

Conversation

@geekosphere-net

Copy link
Copy Markdown

Enable TLS/HTTPS via Kubernetes Secret mounting

The previous https.key and https.cert configuration was incomplet, as it passed
file paths as environment variables but provided no mechanism to mount actual
certificate files into the container, making HTTPS non-functional.

This change replaces it with a Kubernetes-native approach:

  • Users pre-create a TLS Secret (kubernetes.io/tls type)
  • Reference it via https.secretName in values
  • The chart automatically mounts cert and key to /etc/ssl/certs and /etc/ssl/private

Updated:

  • values.yaml: Replace https.key/cert with https.secretName parameter
  • deployment.yaml: Add volume mounts for TLS secret files, update probes to use the correct scheme (HTTP/HTTPS) and endpoint (/api/healthz)
  • NOTES.txt: Show https:// instead of http:// when HTTPS is enabled
  • README.md: Document the new HTTPS setup process with examples

BREAKING CHANGE:

Users using https.enabled=true must migrate to the new https.secretName approach.
See README for migration instructions.

DEPENDENCY

This pull request assumes that the maildev pull request 546 has been merged to correctly enable HTTPS in the container, and supports the new /api/healthz endpoints.

  Replace incomplete path-based HTTPS configuration with proper Kubernetes TLS
  Secret mounting. Users now reference an existing TLS Secret via https.secretName,
  and the chart automatically mounts files to container paths.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant