-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Che 7, TLS and self signed certs #12634
Comments
That sounds like a bug/regression. |
@slemeur it's hard to treat this as a bug because we didn't have this feature before for Che7. All activity we did relate to TLS and self-signed certs were made for che master and GWT-based IDE. |
hello, would let's encrypt help ? Because with let's encrypt I don't see anymore many ppl using self-signed certificates. |
@benoitf so you propose not to have support for self signed certs? Let's encrypt requires a public dns - this isn't always the case for many. |
@eivantsov I see it like a requirement for Che 7 GA, not beta. @benoitf self signed certs were considered critical for Che 6 because we considered that let's encrypt doesn't work for every use case. |
Just wondering if there's any updates on this? Is a fix for this targeted for the Che 7 GA? Hitting the same issue on my cluster with self-signed certs:
|
+1. Any updates on this would be helpful. Thanks! |
@l0rd Is this one part of GA plan? |
@gorkem it wasn't actually. I have added that to the GA list. Still wondering what we need to do to fix this. Will try to make a list here:
@skabashnyuk @benoitf @sleshchenko please review this list and comment if I am missing something @johnmcollier can you provide more details to reproduce your problem? To setup the self-signed cert have you followed Che 6 documentation? With what stack are you testing? |
@l0rd stack does not matter here. Just deploy Che in TLS mode with support of self signed certs. Installer script will create a secret |
@vparfonov @skabashnyuk has one of you taken this issue in your sprint? |
@skabashnyuk this issue is labelled team/platform isn't it? And the error faced by @johnmcollier happens before the plugin-btoker and che-theia are involved. |
That is correct. As well as osio and ide2 since they know about che-theia and plugin-brocker packaging and architecture more
The issue says that che-theia and plugin-brocker processes have to be taught to work with self-signed certificates. Do you want us to take this task in the next sprint? |
@skabashnyuk I had listed 3 distincts subtasks above. The first task should be on your side. The remaining 2 should be easier to analyse / work on when the first one is fixed. |
Yes please. Even if it's not a bug that's still a regression compared to Che 6 hence it's important. |
related to #12971 |
Che Plugin broker is almost adapted to self-signed certificates but unfortunately, Theia does not work out-of-the-box. Here is a demo of state of Che with self-signed certificates with changes that will be merged soon #13565: https://youtu.be/8z8WXA82G28 |
I believe there should not be any issues with self-signed certs, our testing result can be found here #14035 and #13869 (comment) |
There are multiple problems:
A secret with cert body isn't created but che-plugin-broker pod is configured to use it
Once Update DTD for GWT-module descriptors #1 is fixed I expect that che-plugin-broker isn't aware of such a cert and will fail to communicate with master using tls route/ingress.
Once Update DTD for GWT-module descriptors #1 and Package docker runner in Che #2 is solved, Theia server side will be the next suspect since Theia communicates with Che master to grab workspace config and other info. So, Theia should also use the cert or trust all insecure endpoints.
@slemeur @l0rd is this smth that should be taken care of for after beta Che 7 releases?
The text was updated successfully, but these errors were encountered: