Files
helm-charts/stalwart/templates/stalwart.secret.yaml
T
jklein 26be67f4cd
validate-charts.yml / Build ${{ fromJSON(needs.detect-changed-charts.outputs.charts) }} (pull_request) Blocked by required conditions
validate-charts.yml / Trivy config ${{ fromJSON(needs.detect-changed-charts.outputs.scan-charts) }} (pull_request) Blocked by required conditions
Validate Helm Charts / Detect changed charts (pull_request) Successful in 3s
Validate Helm Charts / Resource quantities (pull_request) Successful in 10s
Validate Helm Charts / Build ${{ fromJSON(needs.detect-changed-charts.outputs.charts) }} (pull_request) Successful in 6s
Validate Helm Charts / Trivy config ${{ fromJSON(needs.detect-changed-charts.outputs.scan-charts) }} (pull_request) Successful in 22s
Validate Helm Charts / Install-test (pull_request) Successful in 2m22s
Install-test / Install-test stalwart (pull_request) Successful in 2m22s
feat(stalwart): new chart for the Stalwart mail server
Cluster-capable from the start, with roles rather than symmetry: one
StatefulSet per entry of the "nodes" map, the key passed in STALWART_ROLE.

Since v0.16 Stalwart keeps its whole configuration inside the data store and
manages it over JMAP, so the chart's scope is deliberately narrow: it renders
config.json (exactly the DataStore object), the workloads, the Services, the
NetworkPolicies, the Ingress and a cert-manager Certificate. Listeners, blob
store, in-memory store, TLS object and cluster roles are operator work in the
WebUI, which is why NOTES.txt carries an eight-step first install.

config.json stays secret-free: authSecret uses the EnvironmentVariable variant
(verified against the serde definition of PostgreSqlStore at v0.16.24), so the
password arrives through secretKeyRef and checksum/config stays meaningful.
The username cannot follow it - authUsername is a plain String with no secret
form - so it is a public value and says so.

Services are per PORT, not per group: a NodePort is cluster-unique, so "full"
and "mx" can only accept SMTP behind one Service, selected through a per-port
pod label. The http port gets a per-group ClusterIP Service instead, so the
Ingress reaches exactly ingress.nodeGroup.

Four traps, documented rather than explained away:

- The role lookup FAILS OPEN. A node whose ClusterRole is missing from the
  database enables every listener and every task while staying Running with a
  green probe, and the log line arrives after the listeners are bound. Hence
  mx at replicas 0, per-port Services, and a NetworkPolicy that is a ceiling
  independent of what was bound.
- NET_BIND_SERVICE is a documented deviation needed to EXEC, not to bind. The
  image sets setcap cap_net_bind_service=+ep, which makes the kernel fail
  execve when the bounding set is empty. The values comment says both why it
  is there and that it is never used, because the second half is what stops
  the next hardening pass from removing it.
- externalTrafficPolicy must be Cluster - no pod runs on a control-plane node
  while the HA proxy delivers to them, so Local would drop every packet - and
  the source address that costs is restored only by the HA proxy's PROXY v2
  header.
- /healthz is rate-limited to 100 requests/60s per source IP, which is a node
  IP for kubelet probes, so all pods on a node share one bucket. The probe
  intervals are calculated (6 req/min/pod, ~16 pods per node) and the sum is a
  comment in values.yaml.

A first install needs bootstrap.enabled: true: the setup wizard appears only
when config.json is ABSENT, and this chart always renders one, so recovery
mode is upstream's documented path for a templated config.json.

Second chart in the repo with a dependency - the Valkey project's own chart,
off by default behind condition:, because Stalwart's cluster coordinator rides
on the in-memory store connection. The render aborts when more than one pod
runs with no in-memory store address anywhere.

Also wired up: publish-stalwart.yml through the shared block in
workflow-util/pipelines, the change-app-version.yml choice list, a Renovate
customManagers block anchored on the v prefix (which excludes the moving
latest / v0.16 / -alpine tags), CI fixtures, and the README and CLAUDE.md
lines that claimed ytdlp-web-player was the only chart with a dependency.

Verified locally: ci/helm-dependencies.sh, helm lint --strict (0 failed),
helm package, helm template against chart defaults and against
ci/stalwart/test-values.yaml, the rendered config.json parsed as JSON with the
field types the serde definition requires, ci/run-quantity-render-test.sh
(0 failed, both nodes.*.resources paths exercised), NOTES.txt rendered through
a scratch ConfigMap, and the null-safety and fail paths (securityContext=null
keeps NET_BIND_SERVICE; a cluster without an in-memory store, an unknown port
name, a group without http and an unknown ingress.nodeGroup all abort with a
named message; the schema rejects timeout, a string timeoutMs and a list-shaped
nodes). NO runtime verification was possible - there is no k3d or Docker daemon
in this workspace.

Part of #65
2026-10-02 19:13:49 +00:00

76 lines
3.4 KiB
YAML

{{- /*
The 1Password items this chart materializes. Each is rendered only when its
op:// path is set, because two of the three are genuinely optional.
WHAT THE FIELD NAMES ARE AND WHY THEY ARE NOT FREE-FORM: the operator
materializes one Secret key per FIELD of the item, and these templates mount or
reference those keys by name. An item without the expected field leaves the
container in CreateContainerConfigError. NOTES.txt lists them for the installer.
AND THE LIMIT THAT CANNOT BE CLOSED: a change to the CONTENT of any of these
items does not restart anything. Helm never sees a secret's value - the
operator fills the Secret in-cluster after rendering - so there is nothing to
hash. What this chart does cover is the op:// PATH, through checksum/secret-ref
on the pod template (see the StatefulSet): repointing one of the values below
at a different vault item does roll the pods. For a content change, and after
rotating a password inside the item, the manual step is
kubectl -n <ns> rollout restart statefulset/<release>-stalwart-<group>-sfs
for every group. The 1Password operator's auto-restart annotation is NOT set
here and must not be: verified against operator 1.12.0 it enumerates
Deployments only, so on a StatefulSet it is a silent no-op that advertises a
guarantee it does not provide (README, guideline 9).
*/ -}}
{{- if .Values.secrets.dataStoreSecretRef }}
apiVersion: onepassword.com/v1
kind: OnePasswordItem
metadata:
name: {{ include "stalwart.fullname" . }}-datastore-secret
labels:
app: {{ include "stalwart.fullname" . }}
spec:
# Must carry the field: password
#
# Only the password. The data store's username is dataStore.postgres.username
# and is rendered into the ConfigMap, because authUsername is a plain String
# on the DataStore object while authSecret is a SecretKeyOptional - upstream
# offers a secret form for one and not the other.
itemPath: {{ .Values.secrets.dataStoreSecretRef }}
{{- end }}
{{- if .Values.secrets.recoveryAdminSecretRef }}
---
apiVersion: onepassword.com/v1
kind: OnePasswordItem
metadata:
name: {{ include "stalwart.fullname" . }}-recovery-admin-secret
labels:
app: {{ include "stalwart.fullname" . }}
spec:
# Must carry the field: recovery-admin
#
# Holding the COMPLETE value of STALWART_RECOVERY_ADMIN as one string,
# "admin:<password>". The chart deliberately does not assemble it from a
# username and a password field: the upstream parser splits on the first ":"
# and drops the entry when either half is empty, so a half-filled item would
# silently mean "no recovery admin" rather than failing - and this credential
# is a back door that logs in regardless of directory state, which is not
# something to be uncertain about in either direction.
itemPath: {{ .Values.secrets.recoveryAdminSecretRef }}
{{- end }}
{{- if .Values.secrets.s3SecretRef }}
---
apiVersion: onepassword.com/v1
kind: OnePasswordItem
metadata:
name: {{ include "stalwart.fullname" . }}-s3-secret
labels:
app: {{ include "stalwart.fullname" . }}
spec:
# Must carry the fields: access-key, secret-key
#
# This chart does not configure the blob store - that object lives in the
# database. It exposes both fields to the container as {{ include "stalwart.env.s3AccessKey" . }}
# and {{ include "stalwart.env.s3SecretKey" . }}, so the BlobStore object created in the WebUI can
# reference them by name instead of storing the credentials in the database.
itemPath: {{ .Values.secrets.s3SecretRef }}
{{- end }}