Open misohu opened 3 months ago
Thank you for reporting us your feedback!
The internal ticket has been created: https://warthogs.atlassian.net/browse/KF-6180.
This message was autogenerated
There is currently no plan in the TLS team to support passing a key and certificate directly. The current tls-certificates
interface does not contain any way of transferring a private key, by design.
I could see a config charm sending this data over a relation inside a secret working for this use case, but this does not follow the semantics of the interface. Simply modifying the interface would be problematic also, because a specific (certificate, key)
combo should only be shared on one relation. The current interface is designed to support multiple different requirers simultaneously.
That would leave creating a new interface to support a simple configuration charm to pass secrets around. I do not think it is a good solution for a couple of reasons:
I think that having the option to manually provide a certificate and key should be limited to only a few charms that cannot do without this feature. In that case, I think the better option is to leverage user secrets to pass things directly to the charm.
Adding @gruyaume to also take a look at this.
Here's the basics of the TLS integration: the requiring charm generates a CSR, which is sent over the TLS relation. The TLS provider will take this CSR, generate a certificate and insert it in the relation data. This approach makes it possible to:
The intent with this approach is to be secure, reliable and easy to use.
Passing pre-generated private-key/certs combos is not secure , it often involves certs and private keys being shared via messages. It is also a pain to manage over the lifecycle (i.e. certs expire and need to be renewed). We really want to avoid this.
You mentioned that "Customers are generating key and certificate from CA", can you please tell us what system or process they use to generate the certificate. Most systems will accept a CSR and should work with this approach.
Context
The plan was to remove the TLS juju secret from
istio-pilot
by kubeflow 1.10 (istio operators version > 1.22). https://github.com/canonical/istio-operators/issues/380 https://github.com/canonical/istio-operators/pull/394For now we cant remove the secret object because it is the way customers are setting up their TLS termination on ingress level. Customers are generating key and certificate from CA and they set it with the istio-pilot secret objects
tls-secret-id
. Currently none of the TLS charms are providing this functionality. (docs) https://charmhub.io/topics/security-with-x-509-certificatesAnother issue we are facing with integration of TLS charms is that the proposed solution requires a server with HTTP endpoint which knows how to talk to DNS server to help resolve the DNS 01 challenge (or any other certificate authority challenge).
For now we were not considering the implementation of this functionality on istio side, because we need to define if we want all ingress charms to be involved in resolving the challenge, or we want the users to setup the HTTP endpoint of a custom challenge solver for themselves.
Regardless of the approach we need to expose the end-to-end use case in the charmed kubeflow docs and be able to link external TLS to support this use case (HTTP endpoint challenge solver).
What needs to get done
Passing key and CA to charm
HTTP endpoint on challenge solver problem
Chamred kubeflow
Definition of Done
tls-secret-id
but is using proposed solution.