[almighty] Almighty Build Service and Private repositories

[Tomas Nozicka]

On St, 2016-10-26 at 17:11 +0200, Aslak Knutsen wrote:
> 
> 
> 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.) 
I thought we agreed that we need to give access to build service to
just the source code, otherwise it can't build. This way you create a
special deploy key just for Almighty which allows it to access just the
source code (and no other repository or issue tracking) and in read
only mode. User credentials don't go through the Build Service at all. 

Some sensitive information still needs to go through the semi 3. party
provider, like a token for build and deployment environment and those
are more serious I think.


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