Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [che-dev] Using of cluster default TLS certificate for Che ingresses
If I understand correctly the new behavior is:

IF spec.k8s.tlsSecretName is set AND the secret doesn't exist 
THEN create the secret, generate a new self-signed cert and add it to the secret

IF spec.k8s.tlsSecretName is set AND the secret exist
THEN trust the TLS cert from the secret 

IF spec.k8s.tlsSecretName is not set 
THEN use the default ingress controller certificate

My questions are:
Are those behaviors consistent on OpenShift and plain Kubernetes? In particular are we generating a self signed cert on OpenShift if none is provided?
Is there any documentation PR planned?


On Fri, Oct 30, 2020 at 3:13 PM Mykola Morhun <mmorhun@xxxxxxxxxx> wrote:
Hello.
In terms of the issue [1], Deploy team is going to slightly change the behaviour of `spec.k8s.tlsSecretName` property of Che custom resource.

Current behaviour:
 - if field is set, then operator checks if the secret exists and use it, otherwise creates it with the provided name.
 - if the field isn't set, then operator uses the default value `che-tls` and sets this value back to the CR.

New behaviour:
 - if field isn't set, then the default ingress controller certificate will be used.

We changed the default value of the property in Che CR from empty to `che-tls` to not to affect current behaviour. Here is proposed changes on Che operator side [2]. If someone has concerns, please let us know.


--

Mykola Morhun

Software engineer

Red Hat

_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/che-dev

Back to the top