[almighty] Almighty Build Service and Private repositories

[Tomas Nozicka]

Comments inline.

On Thu, 2016-10-27 at 11:56 +0200, Michael Kleinhenz wrote:
> I think using ssh keys is different from a compliance perspective. We
> are creating a key pair on our system, telling the user to allow the
> key GitHub access by putting the pubkey into GitHub. Then we are
> giving the seckey to the 3rd party build provider. Thats like someone
> creates door keys *by himself* and gives them to a 3rd party. The
To me, that sounds like OAuth flow. Plus the deploy key is only for a
specific repo and read-only; like scoped OAuth.

Is there a difference from security point of view in comparison to
giving build provider a copy of the repository? I don't see one.

> other way around would be different: I think it is critical when
> GitHub would have created the key and we distribute them to 3rd
Github doesn't create such keys, only in the case of cloning with HTTPS
and OAuth tokens.

parties. While technically the same, it is fundamentally different in
> policy terms.
Would you mind elaboration on why it is different? The public key is
set up as deploy key in both cases and private key is given to build
provider to access the repo. Why should github generate such keys and
not Almighty?

> 
> So I think this would work as long as we clearly notify the user that
> we're giving the seckey to the connected build providers.
Sure, we can ask the user. Let's tell him that Build Service requires
giving access to the provider and we will setup a read-only deploy key
for his repository on (Gitlab, Github, ...)

> 
> -- Michael
> 
> On Wed, Oct 26, 2016 at 5:40 PM, Max Rydahl Andersen
> <manderse at redhat.com> wrote:
> > Hi Tomas,
> > 
> > Just some questions about terminology.
> > 
> > > 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
> > 
> > 
> > Which of the three above is what Github call access tokens ?
> > (https://github.com/blog/1509-personal-api-tokens and
> > https://help.github.com/articles/creating-an-access-token-for-comma
> > nd-line-use/)
> > 
> > Is that what you call OAuth tokens ?
> > 
> > And around Deploy keys - I couldn't find a way to limit access to
> > specific
> > repositories.
> > Got a link/screenshot where that happens ?
> > 
> > /max
> > http://about.me/maxandersen
> 
> 
>