Closed zd9KgA closed 7 months ago
You can specify the same secret when specifying the secret and the upstream ca:
spec:
tlsSecretName: your-tls-secret
dispatchUpstreamCASecretName: your-tls-secret
We do this exact thing in the e2e tests. We intentionally match the cert-manager conventions here.
I'll leave this issue open because I think it indicates a deficiency in the docs. Please ping again if the above doesn't work for you.
Hi @ecordell:
This is from a spicedb deployed as suggested (repeated use of the same secret):
│ SPICEDB_DATASTORE_ENGINE: postgres
│ SPICEDB_DATASTORE_TLS_SECRET_NAME: postgresql-tls
│ SPICEDB_DISPATCH_CLUSTER_ENABLED: true
│ SPICEDB_DISPATCH_UPSTREAM_CA_PATH: /dispatch-tls/tls.crt
The secret is mounted at /dispatch-tls/
, but the CA path refers to tls.crt
rather than ca.crt
. The certificate in tls.crt
is not the root certificate, but derived from an intermediate certificate for ca.crt
is the root.
Have I misconfigured / misunderstood something?
No, you're absolutely right, the tests tricked me because the connection will validate when using the cert directly instead of the CA.
I opened https://github.com/authzed/spicedb-operator/pull/273 to address this. Thanks for the report!
I've configured a CA-type ClusterIssuer with cert-manager to include the ca.crt in the certificate (https://cert-manager.io/docs/configuration/ca/#deployment, see "Note").
This option allows to include the CA certificate as ca.crt into a secret that otherwise resides in a different namespace (cert-manager). The outcome is that generated secrets contain tls.crt, tls.key, and ca.crt.
I'd like to feed this into the tls configuration without additional processing (like copying the ca.crt from the secret and placing it as tls.crt into another one). In the present state I needed to reverse engineer from the PodSpec how the input it expected and then provide it accordingly.