Support git clone for repos with self-signed SSL certs

[nickboldt]

Is your enhancement related to a problem? Please describe.

Say I'm a customer behind a firewall (air gap).

I have company wide certs for connecting my local laptop to company internal git repos.

But when I fire up Che 7, launch a workspace from a devfile...

projects:
  - name: java-maven-helloworld
    source:
      type: git
      location: "https://git.mycorp.com/projects-r-us/java-maven-helloworld.git"

... and try to clone from the repo, I can't connect:

The only workaround is to open a console in the Che 7 workspace, and do this:

git config --global http.sslverify “false”
git clone https://git.mycorp.com/projects-r-us/java-maven-helloworld.git

So... how can I get those certs into my che 7 workspace OOTB via the devfile, so I can clone from those repos as part of workspace creation, rather than via a manual step?

Describe the solution you'd like

We can do it in same way how it works for Keycloak at the moment, here helm template and Java code in Che repository. Also need to configure git trust store.

Workflow will be:

• admin put somewhere correct SSL certificate for internal Git server (with name like CHE_GIT_SSL_CERT);
• during start workspace we will:
  • mount this certificate on each container as k8s secret, in specified path;
  • modify git config git config --global http.sslCAInfo /home/some-path/git-certs/cert.pem;

[tsmaeder]

@nickboldt having trouble assessing a priority here: is this some esoteric case or mainstream? Also, does it tie into an epic about airgapped operations?

[tsmaeder]

Airgapped seems to be important and short term: p1

[nickboldt]

If we could somehow embed a cert inside a devfile, could we then use that cert when starting the workspace?

Or what about some sort of tiny cert-hosting container that a customer would create, which could be mounted into the theia container like https://stackoverflow.com/questions/26028971/docker-container-ssl-certificates ?

[skabashnyuk]

What I can suggest: we need to provide the ability of additional configuration for git plugin such as.

projects:
  - name: java-maven-helloworld
    source:
      type: git
      location: "https://git.mycorp.com/projects-r-us/java-maven-helloworld.git"
      config:
            http.sslverify: false
            user.name: Scott Chacon
            user.email:  schacon@gmail.com
            color.status:  auto
            color.branch: auto
            color.interactive:  auto
            color.diff: auto
      

wdyt @l0rd @sunix @metlos @nickboldt @benoitf ?

[l0rd]

Another option: since in user preferences we already persist git.username and git.email it may make sense to persist git.http.sslverify as well. I mean user config should probably not live in a devfile.

[l0rd]

After discussions disabling the SSL verification at the user level is a security exposure hence not ideal, not even as a workaround.

We still need to find out how we could address this issue in the right way:

• How can we add a CA among git trusted CAs? Mounting the CA public certificate in the container?
• How could an admin specify, when installing Che, the list of CAs certificates to trust?

@vparfonov Once we have a plan for that we should provide an estimation.

@nickboldt in the meantime it would be useful to understand if using a git + ssh address (like git@github.com:eclipse/che.git) would fix the specific user problem. That would make this issue of lower priority.

[RickJWagner]

The problem is also noted by Che 6 (CRW 1.x) users. Here's a note from a user discussion:

"Users want to have a private git server with it's own SSL certificate. To use it, CodeReady Workspaces must allow the use of a user-provided CA certificate in the workspace."

[ghost]

I am on 7.2.0 and I am trying to add the config tag under git in the workspace "create&modify". The auto save kicks in and remove the git config away.

[nickboldt]

If the dashboard is fighting you, you can create a devfile offline, put it into a gist or fpaste or other hosting solution, then:

https://che-che.your.openshift.com/f?url=http://path/to/devfile.yaml

eg., https://che.openshift.io/f?url=https://github.com/eclipse/che/devfile.yaml

[nickboldt]

FWIW I was able to do this:

• go to https://che.openshift.io
• import a devfile
• generate an ssh key
• upload key to github

But then in a console these didn't work to pull code from a private GH repo:

• git clone https://github.com/redhat-developer/codeready-workspaces-productization/ or
• git clone git@github.com:redhat-developer/codeready-workspaces-productization.git

Neither one worked. Then I tried to restart the workspace to see if that would help... and #14830 happened. :(

[l0rd]

@nickboldt I have tested this scenario on 7.3-SNAPSHOT and it worked fine. There are a few recent fixes in the GIT+SSH scenario that are not yet on che.openshift.io.

[l0rd]

I have updated the "solution" part in the issue description to match @vparfonov proposal.

[nickboldt]

Latest details from @rbcminghou suggests that even with 7.2.0, neither of these work with internal GH repo:

git clone git@mygithub.bigcorp.com:minghou/java-maven-helloworld.git

and

bash-4.4 /projects $ git clone ssh://minghou@mygithub.bigcorp.com/java-maven-helloworld.git
Cloning into 'java-maven-helloworld'...
The authenticity of host 'mygithub.bigcorp.com (10.101.xy)' can't be established.
ECDSA key fingerprint is ******
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'mygithub.bigcorp.com,10.101.x.y' (ECDSA) to the list of known hosts.
Permission denied (publickey).
fatal: Could not read from remote repository.
Please make sure you have the correct access rights
and the repository exists.

So we'll need to test with 7.3.0-SNAPSHOT/latest/next. Can you list ALL the images he'll need to pull to get a full 7.3.0 install set up?

[l0rd]

@nickboldt the problem seems to be that the public SSH key hasn't been uploaded to the user account:

• github
• gitlab

[ghost]

@nickboldt I have tested the git access with ssh-kegen on my mac and uploaded the public key into my profile at my corporate github, and it works fine.

Tried the 7.2.0 "generate ssh key pair..." and uploaded the public key into my profile (same steps at the above), and it did not work and complained:

Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

The next question, do I have to generate the ssh key pair for a new workspace?

[l0rd]

@rbcminghou in 7.2, after the generation of the key pair, you had to stop and restart your workspace otherwise the key was not mounted in the container (that's something we fixed in7.3)

[ghost]

@l0rd Thanks and it works after restart the workspace.

Do I have to upload the new public key for every new workspace?

[l0rd]

No, once you generate the key pair it will be persisted with your profile, it will be available in any new workspace and you don't need to regenerate/upload it again.

[ghost]

Thanks, and it does work of killing the existing workspace and creating new workspace.

Does the key information store in the Postgres database with the che login profile?

[l0rd]

Thanks, and it does work of killing the existing workspace and creating new

workspace. Does the key information store in the Postgres database with the che login profile?

Yes

…

[vparfonov]

Sub issue:

• [che-operator] - enable support git clone for repositories with self-signed SSL certs [che-operator] - enable support git clone for repositories with self-signed SSL certs #15285

[vinokurig]

Sub issue is resolved: eclipse-che/che-operator#142