[almighty] Almighty Build Service and Private repositories

[Aslak Knutsen]

On Wed, Oct 26, 2016 at 4:52 PM, Tomas Nozicka <tnozicka at redhat.com> wrote:

> 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.
>

I'm not sure how this really change anything described in the original
problem statement.
The user still grants almighty access and almighty give that access away to
a 3. party.
(in this case openshift pipeline is only semi 3. party since we host it.)


>
>
> 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.
>


That's an interesting problem here.. :)


>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/almighty-public/attachments/20161026/9a5d2134/attachment.htm>