feat(qdrant): publish ca.crt-only trust anchor to tenants - #3341

Reviewed hermetically. LGTM with non-blocking notes.

Verified:

• The key-bearing CA Secret is stamped internal.cozystack.io/publish-ca-cert, while the tenant-facing cozyrds selector matches internal.cozystack.io/tenant-ca. The leaf cert carries no publish labels. No TLS private key reaches the tenant tier.
• Neither label has an in-tree consumer yet, so this leg is inert until the CA-extraction controller (#3299) lands.
• Upgrade: adding secretTemplate to an existing CA Certificate is an in-place Secret-metadata patch, no reissuance. Fresh install renders identically plus two currently-unused labels.

Non-blocking:

• PR body omits the mandatory Downstream Repositories checklist; the diff is qdrant-only so most likely no downstream repo is affected, but that should be stated rather than omitted.
• The release-note reads in present tense as if shipped, which is slightly ahead of the inert-until-#3299 reality.
• Consider enforcing the hold-until-#3299 intent with a draft/blocking label rather than prose.

NOT LGTM — the contract itself is correct and byte-for-byte identical to #3340's, but this PR ships the same security-shaped change with the key-leak guard missing. Reviewed as a pair with #3340, which is where the gap becomes visible.

Business context: same as #3340 — tenants with TLS enabled get no CA to verify the server against, and the only existing CA Secret carries the private key; this opts qdrant into the shared key-free trust-anchor contract.

A framing note that applies to both PRs: neither actually projects ca.crt. Neither creates a Secret. Each stamps the publish-ca-cert labels on the cert-manager-authored CA Secret and adds a matchLabels selector to the ResourceDefinition; the key-free guarantee lives in #3299's controller. What these PRs own is the inverse risk — stamping a tenant-visible label onto the key-bearing Secret. That is the thing that needs guarding, and it is the thing that is guarded here only partially.

Blocker

The suite stays green when the key-bearing CA Secret is marked tenant-readable

packages/apps/qdrant/tests/certmanager_test.yaml — by absence.

Evidence. I stamped internal.cozystack.io/tenant-ca: "true" onto the CA secretTemplate in packages/apps/qdrant/templates/certmanager.yaml:23-26 — the file this PR touches — and ran both suites:

qdrant  →  Tests: 62 passed, 62 total          ← mutation NOT caught
nats    →  FAIL tests/certmanager_test.yaml
           - key-bearing CA Secret is never marked as a tenant-readable trust anchor
           Tests: 1 failed, 54 passed

This is not a hypothetical mutation. The RD selector added by this very PR (packages/system/qdrant-rd/cozyrds/qdrant.yaml:36-37) is matchLabels: internal.cozystack.io/tenant-ca: "true", and the CA Secret carries the CA private key under tls.key (isCA: true, certmanager.yaml:31). So a one-line edit to a file in this PR's own diff would grant every tenant subject read access to the CA private key — sufficient to issue certificates for anything — with CI fully green.

The existing tests here do cover the adjacent case: leaf certificate does NOT carry publish-ca-cert labels asserts notExists for publish-ca-cert on documentIndex 3. What is missing is the assertion that neither key-bearing cert carries tenant-ca or tenantresource — which is exactly the label the RD selector keys on. #3340 asserts both, on both documents (packages/apps/nats/tests/certmanager_test.yaml:167-190).

Fix is roughly 14 lines, ported from nats — see the inline suggestion.

Action items (non-blocking)

1. Port the RD/Role guard. hack/check-nats-rd-secrets.bats (107 lines) covers a layer helm-unittest structurally cannot: neither the cozyrds nor the dashboard Role is a chart template. qdrant has no equivalent, so deleting its selector or adding a key-bearing name to resourceNames is entirely unguarded. A hack/check-qdrant-rd-secrets.bats is picked up automatically by BATS_UNIT_FILES (Makefile:162). Use ${BATS_TEST_FILENAME:-$0} as nats does — that is the idiom that avoids the set -u abort trap that has bitten other suites here.

2. Quote the release label for parity. certmanager.yaml:26 — {{ .Release.Name }} versus nats's {{ .Release.Name | quote }}. Cosmetic only, and I confirmed it cannot bite: release prefixes are qdrant- (cozyrds:13), so the value always begins with letters and can never parse as a bare numeric or boolean scalar. Worth aligning anyway since the two files are otherwise identical.

3. Settle the docs question across the pair. This PR's body argues user-facing documentation belongs with the controller that creates it (#3299) rather than with a per-app label leg — a defensible position. But #3340, same author and same contract, adds 19 lines of tenant-facing README. Both cannot be right for one contract; worth picking one and applying it to both engines.

Contract consistency — the wire format is genuinely identical

To be clear about what is not wrong here, since the blocker is about guard strength rather than the contract:

All three wire constants match #3299 exactly (SourceLabel reconciler.go:229, SourceReleaseLabel :262, TenantCALabel :268), so tenants do get a consistent contract across both engines. The divergence is entirely in guard strength and documentation.

Root cause of the asymmetry is visible in the diff sizes and is worth naming, because it is not carelessness: #3340 was advertised at +34/-0 and is now +189/-0, having picked up a hardening pass under review. #3341 has the identical 6-line functional core at its originally-advertised +43/-0 — it simply never received that pass. Porting it across is what closes the gap.

Merge order

After #3299, and after the blocker above. Both labels have zero producers and consumers on main (git grep), so this is inert until the controller lands. #3299 is reviewed and ready; #3340 is ready as-is.

Dismissed

• Private-key leak via templating (a range over .data, a whole-secret copy) — neither PR creates a Secret. The projection is built by #3299's projectionData, which returns exactly map[string][]byte{"ca.crt": chain} rebuilt from parsed x509 blocks. Structurally single-key.
• Empty or invalid Secret when TLS is disabled — the template is fully gated at templates/certmanager.yaml:6; nothing renders.
• matchLabels unsupported in RD spec.secrets.include — supported, and already used by bucket-rd, harbor-rd, kubernetes-rd, rabbitmq-rd and vm-instance-rd.
• Missing helm-unittest test: target — present; 62/62 pass locally.

LGTM.

Verified the trust anchor is ca.crt-only: the TenantProjection (<release>-ca, kind CACert, sourceKey ca.crt) matches the merged postgres reference template byte-for-byte, and the cacert controller refuses private-key material. Canonical name <release>.tenant-ca and the internal.cozystack.io/tenant-ca: "true" selector line up with the ADR. Dashboard RBAC coverage via helm-unittest over the tri-state TLS matrix is solid.

Nothing blocking.