Add TLS auto configuration on DBaaS

As a Cozy administrator or as a user, I would like to enable TLS configuration on the databases application when I deploy them.
Certificate should be handled via cert-manager or manually.

mattia-eleuteri

Hi, mattia-eleuteri. I'm Dosu, and I'm helping the CozyStack team manage their backlog and am marking this issue as stale.

Issue Summary

You requested automatic TLS configuration for databases in DBaaS to allow Cozy admins or users to enable TLS during deployment.
The proposal includes managing certificates either via cert-manager or manually.
There has been no further activity or comments on this issue since it was opened.

Next Steps

Please let me know if this feature request is still relevant for the latest version of CozyStack by commenting on this issue.
If I do not hear back within 7 days, this issue will be automatically closed.

Thank you for your understanding and contribution!

Hey,
issue is still valid, would be nice to have parameters to configure TLS directly in DBaaS, which is something already supported by official helm charts / operator :)

Timofei Larkin (@lllamnyp)

Timofei Larkin (@lllamnyp) The user confirms the issue is still valid and requests parameters to configure TLS directly in DBaaS, similar to what's supported by official helm charts/operator. Could you please assist with this?

This is still in our roadmap

[linstor] Build linstor-server with custom patches (#1726)

TLS for DBaaS Services — Implementation Plan

I've been analyzing the codebase to understand how TLS could be added across all DBaaS services. Here's a detailed implementation plan based on existing patterns (notably the cert-manager setup in packages/system/cozystack-api/templates/certmanager.yaml).

I'd love to get feedback from maintainers before starting any PRs.

Phase 0: Shared helper in cozy-lib

New file: packages/library/cozy-lib/templates/_tls.tpl

A reusable Helm template cozy-lib.tls.certchain that generates 4 cert-manager resources (SelfSigned Issuer → CA Certificate → CA Issuer → Leaf Certificate) from parameters:

releaseName, releaseNamespace
dnsNames (list of SANs)
Configurable durations (CA: 43800h/5y, leaf: 8760h/1y, renewBefore: 720h/30d)

Usage in each chart:

{{- include "cozy-lib.tls.certchain" (dict "releaseName" .Release.Name "releaseNamespace" .Release.Namespace "dnsNames" (list ...)) }}

Generated resources:

Issuer: {releaseName}-selfsigned (selfSigned)
Certificate: {releaseName}-ca (isCA: true, secret: {releaseName}-ca)
Issuer: {releaseName}-ca-issuer (ca, secretName: {releaseName}-ca)
Certificate: {releaseName}-server-cert (leaf, secret: {releaseName}-server-cert)

Reference pattern: packages/system/cozystack-api/templates/certmanager.yaml

Phase 1: PostgreSQL (pilot)

Operator: CloudNative-PG (CNPG) — native TLS support via spec.certificates

File	Change
`packages/apps/postgres/values.yaml`	Add `tls.enabled: true` (default)
`packages/apps/postgres/templates/certmanager.yaml`	New — Call `cozy-lib.tls.certchain` with SANs: `{name}-r`, `{name}-ro`, `{name}-rw`, `{name}-rw.{ns}.svc`, `*.{ns}.svc.cluster.local`
`packages/apps/postgres/templates/db.yaml`	Add conditional `spec.certificates` block referencing cert-manager secrets
`packages/apps/postgres/templates/init-script.yaml`	Add `ca.crt` to `-credentials` secret for client verification
`packages/system/postgres-rd/cozyrds/postgres.yaml`	Add `postgres-{{ .name }}-ca` to `secrets.include` + `tls` to `openAPISchema`

CNPG automatically enables ssl = on when serverTLSSecret and serverCASecret are set. Non-TLS clients can still connect (default mode prefer), ensuring backward compatibility.

# Conditional addition in CNPG Cluster spec
{{- if .Values.tls.enabled }}
certificates:
  serverTLSSecret: {{ .Release.Name }}-server-cert
  serverCASecret: {{ .Release.Name }}-ca
{{- end }}

Phase 2: MariaDB

Operator: mariadb-operator — native TLS support via spec.tls

File	Change
`packages/apps/mariadb/values.yaml`	Add `tls.enabled: true`
`packages/apps/mariadb/templates/certmanager.yaml`	New — `cozy-lib.tls.certchain` with SANs: `{name}`, `{name}-primary`, `{name}-secondary`, `*.{ns}.svc`
`packages/apps/mariadb/templates/mariadb.yaml`	Add conditional `spec.tls.enabled: true` + `spec.tls.serverSecretRef` + `spec.tls.caSecretRef`
`packages/system/mariadb-rd/cozyrds/mariadb.yaml`	Add `mariadb-{{ .name }}-ca` to `secrets.include` + `tls` to schema

{{- if .Values.tls.enabled }}
tls:
  enabled: true
  serverSecretRef:
    name: {{ .Release.Name }}-server-cert
  caSecretRef:
    name: {{ .Release.Name }}-ca
{{- end }}

MariaDB accepts non-TLS connections by default unless require_secure_transport is forced.

Phase 3: Redis (higher complexity)

Operator: Spotahome redis-failover — TLS via customConfig + volume mounts

File	Change
`packages/apps/redis/values.yaml`	Add `tls.enabled: true`
`packages/apps/redis/templates/certmanager.yaml`	New — `cozy-lib.tls.certchain` with SANs for redis and sentinel
`packages/apps/redis/templates/redisfailover.yaml`	Add `tls-port 6380`, cert file paths in `customConfig` + volume mounts
`packages/apps/redis/templates/service.yaml`	Add TLS port (6380) to services
`packages/system/redis-rd/cozyrds/redis.yaml`	Add `redis-{{ .name }}-ca` to `secrets.include` + schema

redis:
  customConfig:
    {{- if .Values.tls.enabled }}
    - tls-port 6380
    - tls-cert-file /tls/tls.crt
    - tls-key-file /tls/tls.key
    - tls-ca-cert-file /tls/ca.crt
    - tls-auth-clients no
    {{- end }}
  {{- if .Values.tls.enabled }}
  extraVolumes:
    - name: tls-certs
      secret:
        secretName: {{ .Release.Name }}-server-cert
  extraVolumeMounts:
    - name: tls-certs
      mountPath: /tls
      readOnly: true
  {{- end }}

Redis listens on both ports (6379 non-TLS + 6380 TLS) for backward compatibility.

Phase 4: MongoDB

Operator: Percona Server MongoDB — native TLS support via spec.tls

File	Change
`packages/apps/mongodb/values.yaml`	Add `tls.enabled: true`
`packages/apps/mongodb/templates/certmanager.yaml`	New — SANs including `*.{name}-rs0.{ns}.svc.{clusterDomain}` for replica set
`packages/apps/mongodb/templates/mongodb.yaml`	Add `spec.tls.mode: preferTLS` + `spec.secrets.ssl/sslInternal`
`packages/system/mongodb-rd/cozyrds/mongodb.yaml`	Add `mongodb-{{ .name }}-ca` to `secrets.include` + schema

preferTLS accepts both TLS and non-TLS connections.

Phase 5: Kafka (already partially TLS)

Operator: Strimzi — manages its own internal PKI

Kafka already has a TLS listener on port 9093. Strimzi automatically creates CAs and certificates.

File	Change
`packages/apps/kafka/values.yaml`	Add `tls.disablePlainListener: false` to allow forcing TLS-only
`packages/apps/kafka/templates/kafka.yaml`	Make `plain` listener conditional
`packages/system/kafka-rd/cozyrds/kafka.yaml`	Add `kafka-{{ .name }}-cluster-ca-cert` to `secrets.include`

No cert-manager resources needed — Strimzi manages its own PKI.

Phase 6: RabbitMQ, NATS, ClickHouse

Same pattern as previous phases, adapting TLS configuration per operator:

RabbitMQ (rabbitmq.com/v1beta1 RabbitmqCluster): spec.tls.secretName + spec.tls.caSecretName
NATS (HelmRelease): config.merge.tls with volume mounts
ClickHouse (Altinity): XML config openSSL.server + volume mounts for certs

Each gets its own certmanager.yaml using cozy-lib.tls.certchain and ApplicationDefinition updates.

Backward Compatibility Strategy

TLS enabled by default (tls.enabled: true) for new installations
Dual mode: All operators configured in "prefer TLS" mode (accept both TLS and non-TLS)
Opt-out: tls.enabled: false disables all cert-manager resources and TLS config
Non-breaking upgrades: Existing clients continue working without changes since TLS is not enforced (no require)
CA exposed: The {release}-ca secret is added to secrets.include in ApplicationDefinitions so client apps can verify the server certificate

Verification Plan

Template tests: helm template to verify correct cert-manager resource generation
Conditional tests: Verify tls.enabled: false produces zero TLS resources
Integration tests: Deploy in a test cluster and verify:
- cert-manager creates secrets correctly
- Databases accept TLS connections
- Non-TLS connections still work (backward compat)
Rotation tests: Verify renewBefore: 720h triggers automatic renewal without downtime
Verification commands:
- PostgreSQL: psql "sslmode=verify-ca sslrootcert=ca.crt"
- MariaDB: mysql --ssl-ca=ca.crt
- Redis: redis-cli --tls --cacert ca.crt
- MongoDB: mongosh --tls --tlsCAFile ca.crt

Recommended Implementation Order

Step	Component	Complexity	Reason
0	cozy-lib helper `_tls.tpl`	Low	Prerequisite for all charts
1	PostgreSQL	Low	Pilot — CNPG has the best native TLS support
2	MariaDB	Low	Native TLS support in operator
3	Redis	High	Requires manual config + volumes
4	MongoDB	Medium	Native support but complex SANs (replica set)
5	Kafka	Low	Already partially done, minor adjustments
6	RabbitMQ	Low	Simple native support
7	NATS	Medium	HelmRelease with config.merge + volumes
8	ClickHouse	Medium	XML config + volumes

Happy to start with a PR for Phase 0 + Phase 1 (cozy-lib helper + PostgreSQL) as a proof of concept. Would appreciate feedback on the overall approach before diving in!

Navigation Menu

Repository navigation

Add TLS auto configuration on DBaaS #473

TLS for DBaaS Services — Implementation Plan

Phase 0: Shared helper in cozy-lib

Phase 1: PostgreSQL (pilot)

Phase 2: MariaDB

Phase 3: Redis (higher complexity)

Phase 4: MongoDB

Phase 5: Kafka (already partially TLS)

Phase 6: RabbitMQ, NATS, ClickHouse

Backward Compatibility Strategy

Verification Plan

Recommended Implementation Order

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Add TLS auto configuration on DBaaS #473

Description

Activity

dosubot commented on Oct 17, 2025

mattiae commented on Oct 18, 2025

dosubot commented on Oct 18, 2025

kvaps commented on Oct 20, 2025

mattia-eleuteri commented on Feb 23, 2026

TLS for DBaaS Services — Implementation Plan

Phase 0: Shared helper in cozy-lib

Phase 1: PostgreSQL (pilot)

Phase 2: MariaDB

Phase 3: Redis (higher complexity)

Phase 4: MongoDB

Phase 5: Kafka (already partially TLS)

Phase 6: RabbitMQ, NATS, ClickHouse

Backward Compatibility Strategy

Verification Plan

Recommended Implementation Order

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions