[almighty] Almighty Build Service and Private repositories

Tomas Nozicka tnozicka at redhat.com
Wed Oct 26 14:52:57 UTC 2016


Hi Aslak an Michael,

this is a follow up on the discussion we had on BlueJeans about how to
best deal with private repositories and Build Service in Almighty
w.r.t. security.

I haven't realized it at that time but we have been dealing with it in
my previous job as well with Gitlab by using deploy keys. I have been
also looking into how OpenShift deals with private repositories, as we
agreed.

OpenShift has a section dedicated to dealing with private repositories
in docs[1]. Long story short: they use secrets to store authentication
method and base64 encoded credentials. This secret is then referenced
from a BuildConfig as spec.source.sourceSecret[2]. The only method
currently supported[2] is *ssh-privatekey*. I have tried to set it up
with OpenShift's pipelines, but it didn't work. After talking to Ben
from OpenShift I've found out that there is currently a bug[4], but it
should work in the future.

My recommendation is that we will start with supporting ssh keys first
as well and have the interface open to add other types of
authentication methods.

Github generally offers these methods[3]:
1. HTTPS cloning with OAuth tokens
   - probably too broad because you can access all repositories user
has access to
   - doesn't need ssh protocol (some repositories can be only
accessible through https, but that's rare)

2. Deploy keys
   - Allow you to have special ssh key just for one repository (or more
if you want)
   - only for repository source code

3. Machine users
   - Regular account, using ssh key
   - You have to create them manually

It seems best if we will setup an almighty deploy key for a repository
and give the key to Build Service together with repository url and
revision. That way Build Service doesn't need to know user's
credentials, have access to other projects or e.g. issue tracing. It
will get access only to a single repository source code.


This was only about cloning the project repository so far, but what if
the repository is referencing other private repositories like in case
of Golang dependencies or some scripts?
It will be user's responsibility (as it is in OpenShift) but Build
Service will support secrets, so user can propagate such information to
Build Service job (pipeline). For example he can mount deploy key
secret to $HOME/.ssh/ and have git clone operations work with private
repository.

Regards,
Tomas

[1] - https://docs.openshift.org/latest/dev_guide/builds.html#using-pri
vate-repositories-for-builds
[2] - https://docs.openshift.org/latest/rest_api/openshift_v1.html#v1-b
uildsource
[3] - https://developer.github.com/guides/managing-deploy-keys/
[4] - https://github.com/fabric8io/openshift-jenkins-sync-plugin/issues
/101




More information about the almighty-public mailing list