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?
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:
git config --global http.sslCAInfo /home/some-path/git-certs/cert.pem;@nickboldt having trouble assessing a priority here: is this some esoteric case or mainstream? Also, does it tie into an epic about airgapped operations?
Airgapped seems to be important and short term: p1
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 ?
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: [email protected]
color.status: auto
color.branch: auto
color.interactive: auto
color.diff: auto
wdyt @l0rd @sunix @metlos @nickboldt @benoitf ?
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.
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:
@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 [email protected]:eclipse/che.git) would fix the specific user problem. That would make this issue of lower priority.
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."
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.
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
FWIW I was able to do this:
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 [email protected]:redhat-developer/codeready-workspaces-productization.gitNeither one worked. Then I tried to restart the workspace to see if that would help... and https://github.com/eclipse/che/issues/14830 happened. :(
@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.
I have updated the "solution" part in the issue description to match @vparfonov proposal.
Latest details from @rbcminghou suggests that even with 7.2.0, neither of these work with internal GH repo:
git clone [email protected]:minghou/java-maven-helloworld.git
and
bash-4.4 /projects $ git clone ssh://[email protected]/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?
@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?
@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)
@l0rd Thanks and it works after restart the workspace.
Do I have to upload the new public key for every new workspace?
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.
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?
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
>
Sub issue:
Sub issue is resolved: https://github.com/eclipse/che-operator/pull/142
Most helpful comment
Another option: since in user preferences we already persist
git.usernameandgit.emailit may make sense to persistgit.http.sslverifyas well. I mean user config should probably not live in a devfile.