[chectl] Make it possible to install Eclipse Che with "--no-tls" option

[dmytro-ndp]

Is your enhancement related to a problem? Please describe.

There is no chectl option to install Eclipse Che without TLS support which is default now.
At the same time -s, --tls doesn't make much sense so as chectl installing Eclipse Che with TLS mode enabled by default by both operator and helm chart.

Describe the solution you'd like

• add support of --no-tls option which to install Eclipse Che without TLS encryption
• remove -s, --tls option which looks useless now

[l0rd]

That's a good point @dmytro-ndp. For who is going to work on that: there is an interesting allowNo attribute of the oclif booleans flags...

[sleshchenko]

@dmytro-ndp I've already asked Mykola about --no-tls flag in his first PR related to TLS by default. The answer was

My plan was to remove that option at all when TLS by default is finished. In most cases people use default Che-Theia editor which in some cases doesn't work properly without TLS (all webview are broken). And, of course, the security...

From che-incubator/chectl#476 (comment)
So, could you elaborate more about cases when Che with no-tls and broken Theia Webview is needed? Maybe it's better to support TLS installation only?

[tolusha]

@dmytro-ndp
Do you still have cases to deploy Che without tls?

[dmytro-ndp]

Eclipse Che and CRW are actually support http-mode, and it's not actually simple to configure https mode on minishift.
So, IMHO, it does still make sense to implement the issue.

[l0rd]

@dmytro-ndp @tolusha @sleshchenko we need to support OpenShift 3.11 but we do NOT need to support minishift at all. If we can run Che on OpenShift 3.11 with TLS enabled I would deprecate TLS installation and disabled it at all in a couple of sprints.

[nickboldt]

+1 to "remove -s, --tls options", since HTTP + Theia = broken.

Similarly, CRW 2.x is now TLS-mode-only. HTTP is no longer supported and let's be real, it's 2020. Security is important.

[azatsarynnyy]

Note, that VS Code compatible Theia WebView Plugin API won't work on http.
As it works in the secure contexts only: https and localhost.
Today, more and more VS Code extensions are adopting WebView API, e.g. OpenShift Connector.
Not only Che Theia Welcome Plugin that provides WebView-based Welcome page.

[dmytro-ndp]

I see. So, closing the issue with "won't fix" resolution.

[nickboldt]

Actions from today's Che Community call:

Should we allow users to have no-TLS mode in Eclipse Che deployed to minikube | openshift?

• we should drop all flags related to tls as Che should only supports TLS
• drop non-secure http
• minishift addon is not supported anymore (and has been unsupported for some time)

all options around TLS should be gone:

• operator hub UI
• CSV
• chectl / crwctl

Finally...

• Need to investigate about breaking compatibility on the custom resource

[l0rd]

@nickboldt in the meantime I had created this one #17012

[gorshkov-leonid]

Hello, this is my case:
I ran custom devfile/plugin registries over http, because I don't need WebView and http is easier - no certificates, no extra steps. But as you suggested I cannot disable https in che-server. As result, my custom regestries won't work with Che over http because browser refuses it.
What do you think of my case?

[tolusha]

@gorshkov-leonid
Could you clarify:

• infrastructure ?
• installation method (operator, helm) ?

In general when Eclipse Che is deployed, you should import the certificate into a browser.
To extract certificate we introduce chectl cacert:export command.

[gorshkov-leonid]

I use

• minikube platform
• operator (by default)
• custom regestries

Command looks like chectl server:start --platform minikube --devfile-registry-url=http://${CHE_LOCALHOST}:8083 --plugin-registry-url=http://${CHE_LOCALHOST}:8082/v3 .
I know that I can get ca sertificate via cacert:export. But I do not know how to use it with regestries. Is it true that regestries can be not runned before running of Che Server? And goal is to run regestries with usage of this certificate? May be I missed something in documentation?

May be my questions are stupid, but https -> http and http -> https lead to mixed-up content problems and true solution is to run Che and regestries with the same sertificate with tls under minikube (or other platforms). But it seems that this case is not covered by docs. And I think what all would like is simplification for regestries as it done in chectl. Otherwise it would have necessary to comrehend each platform

[tolusha]

I see. so, either
1 Run registries over https (I don't know what ${CHE_LOCALHOST} means)
or
2 Deploy Eclipse Che without tls, it is still possible with litter trick: https://www.eclipse.org/lists/che-dev/msg03674.html

[gorshkov-leonid]

@tolusha

1. export CHE_LOCALHOST=$(netsh interface ip show addresses name="vEthernet (Default Switch)" | findstr "IP Address" | egrep -o '([[:digit:]]|\.)+') - localhost where regestries were ran but translated to subnet of VM, windows specific, but the same can be done via ifconfig or ip in linux.
2. Che without tls I tried this variant but not successfully, because even under http Che sends request to keycloak via https.. .have no idea why.

Here full config:

apiVersion: org.eclipse.che/v1
kind: CheCluster
metadata:
  name: eclipse-che
spec:
  server:
    cheImage: 'quay.io/eclipse/che-server'
    cheImageTag: '7.15.0'
    externalDevfileRegistry: true
    devfileRegistryUrl: 'http://192.168.251.161:8083'
    externalPluginRegistry: true
    pluginRegistryUrl: 'http://192.168.251.161:8082/v3'
    cheFlavor: ''
    cheWorkspaceClusterRole: ''
    selfSignedCert: false
    gitSelfSignedCert: false
    tlsSupport: false
    proxyURL: ''
    proxyPort: ''
    proxyUser: ''
    proxyPassword: ''
    nonProxyHosts: ''
    serverMemoryRequest: ''
    serverMemoryLimit: ''
    workspaceNamespaceDefault: ''
    allowUserDefinedWorkspaceNamespaces: false
    airGapContainerRegistryHostname: ''
    customCheProperties:
      CHE_LIMITS_WORKSPACE_IDLE_TIMEOUT: '-1'
  database:
    externalDb: false
    chePostgresHostName: ''
    chePostgresPort: ''
    chePostgresUser: ''
    chePostgresPassword: ''
    chePostgresDb: ''
    postgresImage: 'centos/postgresql-96-centos7:9.6'
  storage:
    pvcStrategy: 'common'
    pvcClaimSize: '1Gi'
    preCreateSubPaths: true
    pvcJobsImage: ''
    postgresPVCStorageClassName: ''
    workspacePVCStorageClassName: ''

  auth:
    externalIdentityProvider: false
    identityProviderURL: ''
    keycloakPostgresPassword: ''
    identityProviderAdminUserName: ''
    identityProviderPassword: 'admin'
    identityProviderRealm: ''
    identityProviderClientId: ''
    openShiftoAuth: false
    oAuthClientName: ''
    oAuthSecret: ''
    identityProviderImage: 'quay.io/eclipse/che-keycloak:7.15.0'
  k8s:
    ingressDomain: '192.168.251.167.nip.io'
    ingressClass: ''
    ingressStrategy: ''
    tlsSecretName: ''
    securityContextFsGroup: ''
    securityContextRunAsUser: ''
  metrics:
    enable: false

[gorshkov-leonid]

Run registries over https

Might be you know some useful links how to do it. I just started Che with down registries and has error. How I can start Che to get sertifficates to pass them to regestries If Che does not start without regestries ❓

[tolusha]

I've just tried
chectl server:start --platform minikube --installer operator --che-operator-cr-patch-yaml ~/Documents/notls.yaml
and got Eclipse Che on http.

Where notls.yaml is the following:

spec:
  server:
    tlsSupport: false

chectl version
chectl/7.15.1 linux-x64 node-v10.21.0

http mode works. Could you try one more time in a new workspace?

[gorshkov-leonid]

Great thank you. It works. Maybe it did not worked because it was necessary to clear ~/.kube, ~.minikube. At least one way is working. But I am worried about aim to get rid ability of run via http. Are your team going to remove this or it is related to cli arguments only?

[tolusha]

Yes, in the near future (couple of month?) we going to get rid of non-tls deployments
Issue to track #17012

[gorshkov-leonid]

@tolusha Thank you... Could you take in account my case? May be it would be not so difficult to describe "how to run Che" with couple of custom registries via https because of unability of running via http.

[tolusha]

We won't be able mix http and https. It is better to deploy custom registries over https.
I guess this can be helpful:

https://github.com/eclipse/che-devfile-registry#kubernetes
https://github.com/eclipse/che-plugin-registry#run-eclipse-che-plugin-registry-on-kubernetes

To deploy over https additional actions are required

1. Precreate che-tls in the namespace
2. uncomment here https://github.com/eclipse/che-plugin-registry/blob/master/deploy/kubernetes/che-plugin-registry/values.yaml#L13 and https://github.com/eclipse/che-devfile-registry/blob/master/deploy/kubernetes/che-devfile-registry/values.yaml#L13

/cc @amisevsk

[gorshkov-leonid]

@tolusha Thank you. I'll try in this way

[matthewfisch]

@dmytro-ndp @tolusha I see this is old and closed, but I'm deploying Che for the first time and quite flummoxed about the lack of a --no-tls option.

For context, I'm installing via Helm on AWS EKS. I prefer to use the ALB ingress load balancers Amazon supplies, performing TLS gating at the network edge.

Frankly I can't believe noone else brought this use-case up. It's a standard enterprise architecture topology and it has been for decades. Sometimes you want to bring your own security gateway.

I suppose the thinking was removing the option would prevent users from stupid? I'm not sure that's possible, but you can surely make the rest of us work harder.

++ for the --no-tls

[nickboldt]

Theia 1.x no longer works properly on http. Theia is the default IDE in Che. Therefore unless you're rolling your own with a different IDE (or an older version of Theia 0.x)you won't have a working Che instance if you deploy without TLS.

That's why we removed the option.

You can still override this and end up with a semi-broken Che if you want, but the plan is to drop non-TLS support entirely in the next few sprints.

[matthewfisch]

@nickboldt can you clarify "no longer works properly on http"?

I'm talking about an HTTPS deployment where encryption is done at the network edge rather than inside the Che deployment. Is that really something that would break Theia? Just learning about the product so perhaps there's more I don't know.