canonical / istio-operators

Charmed Istio
2 stars 17 forks source link

TLS juju secret removal #536

Open misohu opened 3 months ago

misohu commented 3 months ago

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/394

For 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-certificates

Another 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

syncronize-issues-to-jira[bot] commented 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

ghislainbourgeois commented 2 months ago

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.

gruyaume commented 2 months ago

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.

Reference