[RFE] - Deploy SSH keys to enable Git actions on SSH only accessible SCM

[ahussey-redhat]

Is your enhancement related to a problem? Please describe

Some private (not publically accessible) Source Control Management (SCM) solutions can have PKI authentication. In this situation, it is generally much easier to use SSH to interact; for example when cloning, pulling or pushing to a repository.

Currently it doesn't appear as though there is a way to specify SSH keys to use when interacting with a repository, nor a way to deploy/inject SSH keys into the container that is responsible for initially cloning repositories (theia-ide in some cases?), nor in the workspace container.

In the downstream Dev Spaces SSH keys are automatically generated, but this would be inefficient to use, as you would need to add them to the Git repository everytime you start up your workspace.

Describe the solution you'd like

My preferred solution, would be to create a kubernetes secret containing the private and public SSH keys. The secret would have a label or annotation so that CHE/DS is aware the secret exists, and deploys/injects/maps the SSH keys into the appropriate locations in order to allow Git actions to occur without manual intervention.

Describe alternatives you've considered

Current workflow consists of:

1. create secret

   ---
   kind: Secret
   apiVersion: v1
   metadata:
   name: git-ssh-secret
   namespace: <username>-devspaces
   labels:
   controller.devfile.io/watch-secret: 'true'
   controller.devfile.io/mount-to-devworkspace: 'true'
   data:
   id_rsa: >-
   <private-key>
   id_rsa.pub: >-
   <public-key>

2. start workspace a. ensure devfile contains projects that use ssh not https devfile
3. start a terminal for the theia-ide container
4. cp the secrets from /etc/secrets/git-ssh-secret/* to ~/.ssh
5. correct the permissions chmod 0600 ~/.ssh/<private-key>
6. when a timeout or incorrect permissions prompt appears in the IDE, click retry
7. projects clone successfully

Additional context

This is my repo that I have been using for testing: https://github.com/ahussey-redhat/devspaces/tree/develop

@vinokurig - tagging you for reference

[amisevsk]

To add context, there was some work on supporting SSH keys in the DevWorkspace Operator to make project cloning work automatically, but this is generally frustrated by different containers having different home directories (e.g. /home/theia for Theia).

This comment has some initial work in the DevWorkspace Operator to support this. Working from this, I'm able to configure my workspaces to clone private GitHub repos as follows:

# Work in a temporary directory
cd $(mktemp -d)

# Generate a new SSH key with no passphrase. This key must be uploaded to GitHub
ssh-keygen -t ed25519 -C "amisevsk@redhat.com" -N "" -f ./id_ed25519

# Create ssh_config to point to mounted keys
cat > ./ssh_config <<EOF
host *
  IdentityFile /etc/ssh/id_ed25519
  StrictHostKeyChecking = no
EOF

# Create secret to store SSH key and config
kubectl create secret generic git-ssh-key \
  --from-file=id_ed25519=./id_ed25519 \
  --from-file=id_ed25519.pub=./id_ed25519.pub \
  --from-file=ssh_config=./ssh_config

# Annotate secret to mount it to DevWorkspaces. Note we use /etc/ssh
# since this is the global config file and is unaffected by home dir
kubectl patch secret git-ssh-key --type merge -p \
  '{"metadata": {
     "labels": {
        "controller.devfile.io/mount-to-devworkspace": "true",
        "controller.devfile.io/watch-secret": "true"
      },
      "annotations": {
        "controller.devfile.io/mount-path": "/etc/ssh/",
        "controller.devfile.io/mount-as": "subpath"
      }
    }
  }'

This stores the SSH keypair in /etc/ssh/ in workspace containers and configures SSH to use those keys. Testing it locally, I can clone/fetch/push to a private GitHub repo.

[amisevsk]

Note that the solution above works without any intervention from Che itself, and relies on DevWorkspace Operator functionality exclusively. Che could potentially wrap the process above to simplify setting up the DWO secret.

[ahussey-redhat]

Closing this issue now that the documentation has been updated to include the process of using SSH keys.