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
Hello Mario.

Are those behaviors consistent on OpenShift and plain Kubernetes? In particular are we generating a self signed cert on OpenShift if none is provided?

Not exactly. On OpenShift we always use the default router certificate, whereas on Kubernetes we can use the existing one or generate it. Such behaviour is historical and probably caused by the fact that in case of OpenShift router is usually configured the right way, but in case of Kubernetes default ingress controller can contain a certificate that doesn't match.

Is there any documentation PR planned?

Yes I already have small changes regarding the spec.k8s.tlsSecretName CR field. Just created PR [1]
Also we do not change default behaviour, so users shouldn't see any difference after merge. That could be changed later if needed.

[1] https://github.com/eclipse/che-docs/pull/1687

On Wed, Nov 4, 2020 at 12:03 AM Mario Loriedo <mario.loriedo@xxxxxxxxx> wrote:
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
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/che-dev


--

Mykola Morhun

Software engineer

Red Hat

Back to the top