Converge the per-app TLS series onto the ca.crt-only consume contract #2814

Status

Done. Verified against main @ 8a6fe02ee, 2026-09-17: all nine engines in scope hand the tenant a key-free CA, eight through the sentinel and kafka through Strimzi's own Secrets. The last conversion, opensearch (#2682), merged on 2026-09-11. What follows is the record of the contract and of how each engine met it.

Context

The design proposal unified-tls-pki unifies the consume contract, not the CA. The CA stays heterogeneous on purpose: cert-manager or a bring-your-own wildcard at the edge, operator-owned PKI inside the engines. This issue is the per-engine convergence onto that consume contract. Part of #2811. The contract itself landed in #3407.

The problem, restated against main

When the contract landed, exactly two engines handed the tenant a CA object: kafka exports Strimzi's two key-free -ca-cert Secrets, and postgres publishes the canonical projection through the contract. Every other engine exported credentials or an api-key only and delivered no trust anchor at all. So the problem is heterogeneity plus absence, not an existing leak.

That absence is what made the per-app TLS pull requests dangerous. Lacking a key-free object to hand over, several of them reached for a key-bearing one: the CA Secret that also holds ca.key/tls.key, or a leaf key. The contract exists to give every engine one identically-named key-free object, so those PRs had the right thing to deliver.

The contract

Every converged engine publishes its trust anchor as an Opaque Secret named <release>.tenant-ca holding only ca.crt. The engine-agnostic CA-extraction controller (internal/controller/cacert, #3407) produces it; delivery to the tenant rides the existing core.cozystack.io/tenantsecrets API the base tenant roles already grant.

The dot in <release>.tenant-ca is load-bearing, not cosmetic. The dash form <release>-tenant-ca is ambiguous: for a release named foo it renders foo-tenant-ca, which is also CloudNativePG's CA Secret name for a neighbouring cluster named foo-tenant. A dot cannot appear in a generated operator CA Secret name, and #3411 constrains release prefixes to keep it that way.

Two distinct labels — do not conflate them

• internal.cozystack.io/tenant-ca: "true" is stamped by the CA-extraction controller on the <release>.tenant-ca projection. It both marks the object as the trust anchor and is the single engine-agnostic selector each per-app ResourceDefinition uses to include the projection in the tenant-readable set (matchLabels: internal.cozystack.io/tenant-ca: "true", no per-release name templating).
• internal.cozystack.io/tenantresource: "true" is applied by the lineage controller by tracing ownership, and is what the aggregated tenant-secret API surfaces to the tenant. It cannot be forged by a static chart stamp, because the lineage controller computes it from ownership rather than reading it off the object.

The convergence shape

There is one shape, not two. An earlier revision of this issue described a label leg (publish-ca-cert on the CA Secret) and a declared leg (spec.caCert on the ApplicationDefinition). Neither shipped: both belonged to #3299, which was closed in favour of #3407. API-owner review replaced them with a declared sentinel, because a label carries no name, no status and no admission surface of its own, so a broken declaration could only requeue silently.

The chart renders one namespaced object naming the source Secret:

apiVersion: internal.cozystack.io/v1alpha1
kind: TenantProjection
metadata:
  name: {{ .Release.Name }}-ca
spec:
  projections:
    - type: CACert
      sourceSecretName: {{ .Release.Name }}-ca
      sourceKey: ca.crt

Naming the source works for every engine regardless of who creates the CA, so the question the two legs used to answer, whether the chart can stamp a label on that Secret, no longer arises. The reference implementation is packages/apps/postgres/templates/tenant-projection.yaml.

Three invariants, each of which breaks silently when violated. The sentinel carries no ownerReferences: it resolves to its HelmRelease through the helm.toolkit.fluxcd.io/name label Flux stamps, and an owner reference makes the lineage walk return early, so the tenant stops seeing the anchor. It carries no namespace or labels of its own. And it must sit inside the chart's TLS conditional wherever the CA only exists when TLS is on, or the sentinel reports Ready=False/SourceNotFound forever on every plaintext release; postgres is ungated only because CloudNativePG mints its CA either way.

Alongside it, one line in the engine's ResourceDefinition:

- matchLabels:
    internal.cozystack.io/tenant-ca: "true"

Per-engine reality (verified against origin/main)

Kamaji-backed kubernetes is out of the model: its PKI is Kamaji-owned and non-swappable.

Two corrections to what this issue previously claimed. Kafka is not pending: packages/system/kafka-rd/cozyrds/kafka.yaml already grants both -ca-cert Secrets and hack/check-kafka-rd-secrets.bats pins it. And the redis-operator fork does not publish a key-free CA on main, where caCertSecretName has zero occurrences; that fork ships inside #2729, so redis is a from-scratch TLS feature rather than a convergence.

Order

1. postgres, with feat(cozystack-controller): extract application CA into a key-free tenant Secret #3407. Done. It exercised the contract against the hardest input: an operator-created, asynchronous, key-bearing CA Secret.
2. qdrant (feat(qdrant): publish ca.crt-only trust anchor to tenants #3341), nats (feat(nats): publish ca.crt-only trust anchor to tenants #3340) and mongodb (feat(mongodb): add TLS support via PSMDB operator-managed certificates #2692). Done, merged 2026-09-01. qdrant fixed the exact shape the rest copy; mongodb is the reference conversion for an operator-minted CA.
3. mariadb (feat(mariadb): add TLS support via cert-manager #2680), rabbitmq (feat(rabbitmq): add TLS support for AMQPS and management HTTPS #2683), opensearch (feat(opensearch)!: issue HTTP and Dashboards certificates from cert-manager #2682). Done, merged 2026-09-04, 2026-09-07 and 2026-09-11. Same shape; opensearch was converted from the label leg on the way.
4. redis (feat(redis): add opt-in TLS for Redis and Sentinel #2729). The operator is now freshworks v3.3.5 with the TLS support carried as a downstream patch until feat(tls): TLS for RedisFailover via cert-manager freshworks-oss/redis-operator#85 ships; the sentinel is in the same PR. Done, merged 2026-09-04.

Acceptance

• Every converged engine publishes a key-free <release>.tenant-ca holding only ca.crt.
• A tenant can obtain ca.crt without read access to any Secret containing tls.key or ca.key.
• Each engine's chart renders the sentinel and its ResourceDefinition carries the tenant-ca selector, with a helm-unittest asserting both, and no key-bearing Secret projected to a tenant.