TLS juju secret removal

[misohu]

Context

The plan was to remove the TLS juju secret from istio-pilot by kubeflow 1.10 (istio operators version > 1.22).
#380
#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

• https://charmhub.io/route53-lego-k8s
• https://charmhub.io/namecheap-lego-k8s
• https://charmhub.io/httprequest-lego-k8s
• https://charmhub.io/manual-tls-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

• Have a way to pass certificate and key to TLS charms, which will propagate it to requirer charm as explained ssl-key and ssl-crt removal broke compatibility with a specific TLS use case #380 (sync with telco team about the solution)
• Ensure there are docs

HTTP endpoint on challenge solver problem

• Sync with other teams working with ingress and decide if we want the in charm implementation or take it away from charms.
• Ensure there are docs

Chamred kubeflow

• Create end-to-end doc for charmed kubeflow
• Once we agreed on the design of how the TLS operator charms should handle manual certificates then ensure the istio pilot charm aligns with it (remove the current TLS secret id implementation and add the proposed implementation).
• Once we agreed on the design of how we handle the HTTP endpoint for challenge solver ensure our istio-pilot aligns with it (if needed)

Definition of Done

• Documentation in CKF for en-to-end TLS setup with using only TLS operators
  • With links to documentation for passing key and certificate to TLS operators
  • With links to setup HTTP endpoint on challenge resolver (for AWS, Azure, GCP, or any other dns provider)
• Istio charm is not using tls-secret-id but is using proposed solution.
• Istio charm aligns we the agreed proposal for HTTP challenge solver.

[syncronize-issues-to-jira]

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]

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:

• It still passes a private key around, even if it is in a secret, and encourages direct human access to private keys
• It forces charms that want this feature to support 2 interfaces that should be mutually exclusive

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]

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:

• Automatically manage private keys (creation, renewal)
• Automatically manage CSR's
• Automatically manage certificates

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

• https://charmhub.io/topics/security-with-x-509-certificates
• https://charmhub.io/tls-certificates-interface (for charm authors)

---