newsnowlabs / dockside

Develop, stage and test on-prem or in your private cloud. Dockside is a tool for provisioning lightweight access-controlled IDEs, staging environments and sandboxes - aka 'devtainers' - on local machine, on-premises raw metal or VM, or in the cloud
https://dockside.io/
Apache License 2.0
255 stars 17 forks source link

Provision owner's ssh key to their devtainers #11

Open struanb opened 1 year ago

struanb commented 1 year ago

Currently, users' passphrase-protected keys must be provisioned to devtainers using a shared volume mounted at ~/.ssh, and specified within the profile. The user must type ssh-add ~/.ssh/<their key> within a terminal to add their key to the ssh agent that Dockside launches within their devtainer.

Create a generalised system for managing users' ssh keys and deploying (and undeploying) them to devtainers.

This should comprise:

And some of the following:

  1. Dockside deploying the owner's key to their devtainer at ~/.ssh (with file ownership matching ideUser) on devtainer launch; automatically updating the key files on all owned devtainers, if/when the key be changed.
  2. Dockside adding the owner's key to the devtainer's ssh-agent when the devtainer is started (potentially needing a mechanism for obtaining the passphrase that may be used to unlock the key).
  3. Dockside launching one ssh-agent process not for each devtainer, but for each user; providing each devtainer that a user launches with access to the owner's ssh-agent; adding the owner's key to their ssh-agent when required (potentially needing a mechanism for obtaining a passphrase to be used to unlock the key).
struanb commented 1 year ago

No. (3) is complicated, and limiting unless there's a way to reassign which ssh-agent process is associated with the devtainer at any one time.

No. (1) is simplest. Note that ~/.ssh should be a mounted tmpfs or per-devtainer volume, to avoid risk of keys being committed to an image.

No. (2) is probably the next easiest of these options. With a single ssh-agent per devtainer it's still possible for Dockside to manage the keys available in that agent, e.g. zeroing keys from the agent in certain circumstances. There is no need for Dockside to write keys to ~/.ssh - or any other path - though it could additionally do so as an option.

Contrary to the original issue text, provisioning users' preexisting passphrase-protected keys may not be the most secure way to do things. It would be more secure for users to use dedicated keys generated for the specific Dockside use case. To simplify an initial implementation, such keys could then be allowed to be un-passphrase-protected, as they would not be expected to be ever transferred off the Dockside server. Assuming so, and to simplify set up for an organization, such keys could be generated by Dockside for each user. Potentially, such keys could be stored in a separate table to users.json to allow each user to be associated with different keys for different projects or git paths. But one key per user might be a reasonable first case.

As an alternative to per user keys, per project keys may be required. If so such keys could be stored in a separate table and selected according to the best matching git URI domain and path prefix to the git repo specified in the profile all devtainer launch data.