<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 26, 2016 at 4:52 PM, Tomas Nozicka <span dir="ltr"><<a href="mailto:tnozicka@redhat.com" target="_blank">tnozicka@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Aslak an Michael,<br>
<br>
this is a follow up on the discussion we had on BlueJeans about how to<br>
best deal with private repositories and Build Service in Almighty<br>
w.r.t. security.<br>
<br>
I haven't realized it at that time but we have been dealing with it in<br>
my previous job as well with Gitlab by using deploy keys. I have been<br>
also looking into how OpenShift deals with private repositories, as we<br>
agreed.<br>
<br>
OpenShift has a section dedicated to dealing with private repositories<br>
in docs[1]. Long story short: they use secrets to store authentication<br>
method and base64 encoded credentials. This secret is then referenced<br>
from a BuildConfig as spec.source.sourceSecret[2]. The only method<br>
currently supported[2] is *ssh-privatekey*. I have tried to set it up<br>
with OpenShift's pipelines, but it didn't work. After talking to Ben<br>
from OpenShift I've found out that there is currently a bug[4], but it<br>
should work in the future.<br>
<br>
My recommendation is that we will start with supporting ssh keys first<br>
as well and have the interface open to add other types of<br>
authentication methods.<br>
<br>
Github generally offers these methods[3]:<br>
1. HTTPS cloning with OAuth tokens<br>
   - probably too broad because you can access all repositories user<br>
has access to<br>
   - doesn't need ssh protocol (some repositories can be only<br>
accessible through https, but that's rare)<br>
<br>
2. Deploy keys<br>
   - Allow you to have special ssh key just for one repository (or more<br>
if you want)<br>
   - only for repository source code<br>
<br>
3. Machine users<br>
   - Regular account, using ssh key<br>
   - You have to create them manually<br>
<br>
It seems best if we will setup an almighty deploy key for a repository<br>
and give the key to Build Service together with repository url and<br>
revision. That way Build Service doesn't need to know user's<br>
credentials, have access to other projects or e.g. issue tracing. It<br>
will get access only to a single repository source code.<br></blockquote><div><br></div><div>I'm not sure how this really change anything described in the original problem statement.</div><div>The user still grants almighty access and almighty give that access away to a 3. party.</div><div>(in this case openshift pipeline is only semi 3. party since we host it.) </div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
<br>
This was only about cloning the project repository so far, but what if<br>
the repository is referencing other private repositories like in case<br>
of Golang dependencies or some scripts?<br>
It will be user's responsibility (as it is in OpenShift) but Build<br>
Service will support secrets, so user can propagate such information to<br>
Build Service job (pipeline). For example he can mount deploy key<br>
secret to $HOME/.ssh/ and have git clone operations work with private<br>
repository.<br></blockquote><div><br></div><div><br></div><div>That's an interesting problem here.. :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Regards,<br>
Tomas<br>
<br>
[1] - <a href="https://docs.openshift.org/latest/dev_guide/builds.html#using-pri
vate-repositories-for-builds" rel="noreferrer" target="_blank">https://docs.openshift.org/<wbr>latest/dev_guide/builds.html#<wbr>using-pri<br>
vate-repositories-for-builds</a><br>
[2] - <a href="https://docs.openshift.org/latest/rest_api/openshift_v1.html#v1-b" rel="noreferrer" target="_blank">https://docs.openshift.org/<wbr>latest/rest_api/openshift_v1.<wbr>html#v1-b</a><br>
uildsource<br>
[3] - <a href="https://developer.github.com/guides/managing-deploy-keys/" rel="noreferrer" target="_blank">https://developer.github.<wbr>com/guides/managing-deploy-<wbr>keys/</a><br>
[4] - <a href="https://github.com/fabric8io/openshift-jenkins-sync-plugin/issues" rel="noreferrer" target="_blank">https://github.com/<wbr>fabric8io/openshift-jenkins-<wbr>sync-plugin/issues</a><br>
/101<br>
</blockquote></div><br></div></div>