Request for clarification on Certificates

[gnoejuan]

Summary

According to chectl : To provide own certificate for Kubernetes infrastructure, 'che-tls' secret with TLS certificate must be pre-created in the configured namespace.

How would I use a certificate deployed with a ClusterIssuer? Before I learned of ClusterIssuer(s), my research led me to: https://cert-manager.io/docs/faq/kubed/ to sync the certificate across namespaces.

Would I need to take the extra step to sync the default cluster certificate to the Che namespace?

Relevant information

[tolusha]

/cc @mmorhun

[mmorhun]

Hello @gnoejuan. As of now Eclispe Che uses a separate TLS certificate to secure its ingresses in Kubernetes cluster. The requirements may vary depending on the cluster and/or Che settings. In general, there are two secrets: che-tls (secret name can be changed with tlsSecretName property) and self-signed-certificate (optional). The secret(s) should be pre-created in the namespace where Che is planned to be installed into. che-tls secret should contain server private key and public part (tls.key, tls.crt data fields respectively). If the cluster configured to use commonly trusted certificate that should be enough. Otherwise, self-signed-certificate secret should be created with CA certificate (only public part) under ca.crt date field.
Please note, that it is required to have CA certificate and then sign with it server one. Just single self-signed certificate is not going to work. If nothing is provided, Che installer generates both self-signed CA certificate and server one.
In case of already existing Cert Manager, this might help. But the idea is to have the secret(s) in place and it doesn't matter how they appeared there.
If it doesn't answer your question or you have follow up questions, feel free to ask.

[gnoejuan]

After double-checking the chectl server:deploy args, I assume changing tlsSecretName and che-tls aren't changed through a chectl deployment.

Sounds like the easiest/fastest way to use a ClusterIssuer / Let'sEncrypt certificate is to have the certificate synced.

[mmorhun]

I assume changing tlsSecretName and che-tls aren't changed through a chectl deployment.

It should be changed in case of Operator installer, otherwise it is a bug.

[gnoejuan]

If the cluster configured to use commonly trusted certificate that should be enough

I might have misread this, but a standard chectl server:deploy -a helm -b url.com -p microk8s did not work with a ClusterIssuer already in place. I ended up copying the tls secret to the che namespace.

Since I was interested in a helm deployment and kubed doesn't appear to work with microk8s, my KISS solution is below:

kubectl get secret acme-secret-prod --namespace=default -o yaml > che-tls.yaml where acme-secret-prod has the tls.crt and tls.key. Edit che-tls.yaml fields name --> che-tls (required with helm, I think) and namespace --> che ( same value from deployment chectl server:deploy --chenamespace=chenamespace )

[mmorhun]

did not work with a ClusterIssuer already in place

Yes, it's true. I meant that default ingress controller already uses a commonly trusted certificate and che-tls is created. Sorry if it wasn't clear enough.

BTW, I think, that soon it will be possible to avoid using of any secret in case of commonly trusted certificate. A bit of details: #18079 and #18259