Proposal: SSH key sharing

[tonistiigi]

ref: moby/moby#33343

This proposal was partially implemented for Moby in tonistiigi/docker@a175773 (the existing agent can be forwarded, but one cannot be dynamically created from a custom key yet) but never proposed as a PR.

A common use case for build secrets brought up by the users is that they want to access their SSH keys. Most often to access private repositories but maybe just to use scp etc.

Build secrets are not very useful for this problem because they involve sending the unencrypted private key to the build server (to a specific location) while SSH itself is designed to avoid the private key ever leaving the client.

Instead, we can use the client session to sign the auth requests using the SSH agent protocol so that the private key is never shared.

Changes:

Git source operation:

If repo is defined with a ssh protocol, a default SSH configuration sent from client is automatically attached. There is a special attribute to define custom name if one is needed.

Exec source operation:

A special mount can be defined with ssh=name (usually ssh=default) option without any inputs and outputs. SSH agent socket will be mounted to the specified path. For the process to use the agent it also needs to define SSH_AUTH_SOCK env to that path.

Buildctl

buildctl allows specifying --ssh for the client to opt-in to ssh sharing. The values could be either existing agent socket or exposed keys. If keys are passed, the client will automatically create an agent for them using golang package(only implement the sign method). Using the keys is the preferred way as users are supposed to use the project specific readonly access keys instead of their developer keys.

buildctl build --ssh default=$SSH_AUTH_SOCK
buildctl build --ssh default=key1,key2
buildctl build --ssh myapp.ssh=key1

Similar filtering is needed for subbuilds as in build secrets.

@tiborvass @n4ss

[tiborvass]

https://www.youtube.com/watch?v=hFDcoX7s6rE&t=5s

Docker's CLI may be different but that's off topic here.

• What happens if SSH_AUTH_SOCK was already defined? It's very unlikely because it couldn't be used anyway, so I think overwriting is fine.

[tonistiigi]

What happens if SSH_AUTH_SOCK was already defined? It's very unlikely because it couldn't be used anyway, so I think overwriting is fine.

For BuildKit that doesn't matter as env needs to be manually defined in LLB anyway. For Dockerfile I think it is fine to override (could error as well of course).

[tonistiigi]

#655