The tenant needs the CA certificate to verify TLS connections, but the
cert-manager Secrets that back the chain are key-bearing: <name>-ca-tls
holds the CA private key and <name>-tls holds the server private key.
The dashboard Role granted the tenant read access to both whenever TLS
was on, which handed out signing material where only a trust anchor was
required.
Drop both from the tenant grant and mark the CA Secret as the source of
a key-free projection instead. The chart owns the cert-manager chain
here, so it labels the CA Secret directly, inside the existing TLS gate:
with TLS disabled the chain is not rendered and nothing is marked. Only
the CA carries the labels, never the leaf.
The selector added to the ApplicationDefinition is deliberately specific.
An empty selector would compile to a match-everything label selector and
project every Secret in the namespace to the tenant.
The source Secret and the projection are matched by two different
labels on purpose: the source stays key-bearing and internal, while the
published copy is key-free. Selecting the source directly from the
consumer would defeat the split and leak the CA private key.
Note that the labels and the selector are inert until the controller
that produces the projection exists: nothing reads the labels yet, and
the selector matches no Secret.
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Aleksei Sviridkin
b43f00d2bb