Open huntc opened 3 years ago
I think a reasonable 2-part approach here aligned with the Red Hat approach would be:
That would allow developers to support a wide range of init tasks via custom images, while also providing a new avenue for value-adds from the enterprise suite. Once these capabilities exist, the helm templates could be revised to make this specific use case much simpler to configure at deploy time.
Would it be possible to have Cloudflow support the delivery of TLS certificates by Kubernetes for the purposes of both supporting trusted ingress and egress?
Kubernetes provides a degree of support for managing and delivering TLS certificates to containers. Our client has self-signed certificates and wishes these to made available to Cloudflow application containers at the point of deployment. My understanding is that a directory for the TLS certificates is declared using
kubectl
.From a Cloudflow perspective, I'd imagine that its focus is to assume a directory where certificates are delivered to. For the purposes of egress, the startup of a Cloudflow application container could invoke
keytool
to make the certificate known to the contained JVM, and therefore trusted. For the purposes of ingress, this directory path should be provided as a JVM property whereupon some naming convention could be used to locate certificates for the purposes of binding (for example).I note a previous issue raised similar in nature, where the solution was to encode the secret at build time; again, we wish to defer encoding sensitive data until the point of deployment.
Also, as pointed out to me, Red Hat Developer documents an approach to supporting the setup of CAs for the JVM on Kubernetes. At a minimum, having the Cloudflow documentation describe or reference this approach might be useful.
Thanks.