Description of problem:

I have a developer enquiry about functionality in buildah bud in comparison to docker build use of the —ssh parameter. 

The developer is currently porting their work to OpenShift 4.7 from GCP and therefore have based their toolchain around docker build. Now they are using an OpenShift BuildConfig using buildah via the RHEL8/buildah:latest image. However they currently make use of the docker build —ssh parameter to pass through ssh-agent info to help them dynamically securely git clone from a private repo inside the docker environment.

It appears buildah bud is missing an equivalent argument to docker build --ssh.

Now, yes I’m sure they could re-work their build process so all source is initially fetched from multiple repos, or alternative they could mount ssh keys into the buildah environment and populate ssh-agent via script using mounted data, but they consider the latter to be insecure in comparison to mounting the ssh-agent via socket. 

Their current workaround is to avoid builds in OpenShift and instead use GitHub actions using docker.

Version-Release number of selected component (if applicable):


How reproducible:

Always

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Have discussed this via email wtih Dan Waslh and Ashely Cui, below is an extract of that email:

@Ashely: The RUN mount syntax was implemented (https://github.com/containers/buildah/pull/3177), so it shouldn't be too much of a jump to --mount type=ssh. I'm not too familiar with how ssh actually works; Is this just a matter of mounting $SSH_AUTH_SOCK or a .pem file and setting $SSH_AUTH_SOCK as the target (default  /run/buildkit/ssh_agent.${N}) inside the build container? 

@Me in reply:

In the docker case yes in essence the existing ssh-agent (SSH_AUTH_SOCK) is passed in as a parameter to docker build and this becomes the ssh-agent made available inside the docker execution to authenticate any ssh activity that occurs (in this case git):

Using a customer example that I have truncated to protect the innocent, this is the docker build invocation example:

$docker build --progress plain --ssh default=${SSH_AUTH_SOCK} -t ${IMAGE_ID} -f ./Dockerfile .

The Dockerfile itself would include some ssh setup before mounting the SSH agent socket and performing some processing:

RUN mkdir /root/.ssh/ && \ 
	ssh-keyscan -t rsa github.com > /root/.ssh/known_hosts

ENV MIX_ENV=prod

RUN --mount=type=ssh mix do deps.get --only $MIX_ENV, deps.compile

Finally to indicate the unpredictable nature of embedded execution this shows while the ssh-agent is available (mounted) some jsonnet function performs a git clone for a 
specific private repo library and tag needing ssh keys for access.

defp deps do
    [
      {:floki, ">= 0.27.0", only: :test},
      {:jason, "~> 1.0"},
      {:plug_cowboy, "~> 2.0"},
      {:telemetry_metrics, "~> 0.4"},
      {:telemetry_poller, "~> 0.4"},
      {:telemetry, git: "git:XXXX/telemetry.git", tag: "0.1.2"},
    ]
  end