That seems reasonable. However, I would like to consider that and non-security-impacting usability improvements separately, as a different issue, and focus this thread on the two items from the OP: 1. when we can turn off Cloudera's internal Jenkins, 2. Who should have access to what jobs and in what configuration.
On Wed, Dec 14, 2016 at 4:07 PM, Bharath Vissapragada <[email protected]> wrote: > Yes, in terms of security, it would be the same as a separate Jenkins > login. But this would be much easier to use/manage IMO, both for > contributors as well as admins. > > On Wed, Dec 14, 2016 at 2:00 PM, Jim Apple <[email protected]> wrote: > >> I do not understand the proposed security benefit of using github for >> user authentication over using Jenkins permissions directly. Keep in >> mind that preventing non-+2ed commits from being run is an orthogonal >> question - this can be configured with any user authentication method. >> >> On Wed, Dec 14, 2016 at 1:52 PM, Bharath Vissapragada >> <[email protected]> wrote: >> > That was just for configuring the gerrit trigger. Regarding auth >> > integration, I read this page. Does it not work? >> > >> > https://wiki.jenkins-ci.org/display/JENKINS/GitHub+OAuth+ >> Plugin#GitHubOAuthPlugin-AboutGitHubAuthenticationPlugin >> > >> > On Wed, Dec 14, 2016 at 1:50 PM, Jim Apple <[email protected]> wrote: >> > >> >> I think you're misunderstanding that plugin. It does not associate >> >> Jenkins login with gerrit login. >> >> >> >> On Wed, Dec 14, 2016 at 1:45 PM, Bharath Vissapragada >> >> <[email protected]> wrote: >> >> > On Wed, Dec 14, 2016 at 1:38 PM, Alex Behm <[email protected]> >> >> wrote: >> >> > >> >> >> That integration sounds like a great idea to me. >> >> >> >> >> >> Just to clarify the purpose: We'd like external contributors to be >> able >> >> to >> >> >> run private build+test runs during development, and not just run GVO >> >> once >> >> >> the patch has +2. The hard part is gettig the patch to +2 in the >> first >> >> >> place and we've seen instances where relying on local test runs only >> >> can be >> >> >> difficult. >> >> >> >> >> >> For example, contributors could upload a draft to gerrit and run a >> >> private >> >> >> build to fix problems before publishing the patch fir review. >> >> >> >> >> > >> >> > As per this [1] link, I think that can be configured. I haven't tried >> it >> >> > myself, but from the looks of it, it seems plausible. >> >> > >> >> > [1] >> >> > https://wiki.jenkins-ci.org/display/JENKINS/Gerrit+ >> >> Trigger#GerritTrigger-TriggerConfiguration >> >> > >> >> > >> >> >> >> >> >> On Wed, Dec 14, 2016 at 1:33 PM, Bharath Vissapragada < >> >> >> [email protected] >> >> >> > wrote: >> >> >> >> >> >> > Just wondering why we can't link Jenkins authentication with gerrit >> >> login >> >> >> > in this case instead of having two separate login credentials. That >> >> way >> >> >> we >> >> >> > can retain the audit trail of the jobs and also isolate Jenkins to >> >> only >> >> >> run >> >> >> > code thats approved (+2ed) over gerrit. With this, any new >> contributor >> >> >> > (whoever has signed up on gerrit) can have access to the jenkins >> box >> >> and >> >> >> we >> >> >> > can be sure that they only run the stuff that is approved by >> >> committers. >> >> >> > Thoughts? >> >> >> > >> >> >> > * I'm not totally sure if such an integration is possible but I >> did a >> >> >> quick >> >> >> > search and I got a feeling that shouldn't be difficult. >> >> >> > >> >> >> > On Wed, Dec 14, 2016 at 1:18 PM, Taras Bobrovytsky < >> >> >> > [email protected]> wrote: >> >> >> > >> >> >> > > I would be more in favor of starting with open access instead of >> >> having >> >> >> > to >> >> >> > > hand out credentials. It's both less work for us and it makes it >> >> easier >> >> >> > to >> >> >> > > contribute. If we notice that this is not working well, or gets >> >> abused, >> >> >> > we >> >> >> > > can switch to what Tim is suggesting. Also, we should be able to >> see >> >> >> who >> >> >> > is >> >> >> > > using our Jenkins by looking at Gerrit (because the patch must be >> >> >> > uploaded >> >> >> > > to Gerrit before starting a build). >> >> >> > > >> >> >> > > On Wed, Dec 14, 2016 at 10:57 AM, Alex Behm < >> [email protected] >> >> > >> >> >> > > wrote: >> >> >> > > >> >> >> > > > I'm fine with Tim's approach, but it does add some friction to >> >> >> > > > contributions. >> >> >> > > > >> >> >> > > > On Wed, Dec 14, 2016 at 9:57 AM, Tim Armstrong < >> >> >> > [email protected]> >> >> >> > > > wrote: >> >> >> > > > >> >> >> > > > > I mean the contributor could email an email address (e.g. a >> >> mailing >> >> >> > > list) >> >> >> > > > > asking for credentials and we could email them privately. >> >> >> > > > > >> >> >> > > > > Do we know what other Apache projects do for situations like >> >> this? >> >> >> > > > > >> >> >> > > > > On Wed, Dec 14, 2016 at 9:18 AM, Alex Behm < >> >> [email protected] >> >> >> > >> >> >> > > > wrote: >> >> >> > > > > >> >> >> > > > > > Can you clarify the "credentials by mailing list" approach? >> >> >> > > > > > >> >> >> > > > > > If we send out the credentials on a public list, it's >> pretty >> >> >> close >> >> >> > to >> >> >> > > > > open >> >> >> > > > > > access. >> >> >> > > > > > >> >> >> > > > > > If we send out credentials to contributors privately, we >> have >> >> an >> >> >> > > > > additional >> >> >> > > > > > hurdle to contributions. >> >> >> > > > > > >> >> >> > > > > > On Wed, Dec 14, 2016 at 9:12 AM, Tim Armstrong < >> >> >> > > > [email protected]> >> >> >> > > > > > wrote: >> >> >> > > > > > >> >> >> > > > > > > Got it. >> >> >> > > > > > > >> >> >> > > > > > > I think I'd probably be more in favour of handing out >> login >> >> >> > > > credential >> >> >> > > > > to >> >> >> > > > > > > contributors on demand (e.g. by mailing a list) rather >> than >> >> >> > having >> >> >> > > > > open >> >> >> > > > > > > access, just so we have a clearer idea of who's using >> it. I >> >> >> don't >> >> >> > > > have >> >> >> > > > > a >> >> >> > > > > > > strong objection to the alternative. >> >> >> > > > > > > >> >> >> > > > > > > On Wed, Dec 14, 2016 at 8:52 AM, Jim Apple < >> >> >> [email protected] >> >> >> > > >> >> >> > > > > wrote: >> >> >> > > > > > > >> >> >> > > > > > > > > How isolated is the Jenkins instance? >> >> >> > > > > > > > >> >> >> > > > > > > > As far as I know, the workers have little access to the >> >> >> > > > coordinator. >> >> >> > > > > > See >> >> >> > > > > > > > here: >> >> >> > > > > > > > >> >> >> > > > > > > > https://wiki.jenkins-ci.org/display/JENKINS/Slave+To+ >> >> >> > > > > > > Master+Access+Control >> >> >> > > > > > > > >> >> >> > > > > > > > This flag is on and there are no whitelisted >> exceptions. >> >> >> > > > > > > > >> >> >> > > > > > > > > Does the jenkins user have many privileges on the VM? >> >> >> > > > > > > > >> >> >> > > > > > > > They have passwordless sudo on the worker >> >> >> > > > > > > > >> >> >> > > > > > > > > Could it simply wipe >> >> >> > > > > > > > > out the job history to destroy the trail? >> >> >> > > > > > > > >> >> >> > > > > > > > Job history is stored on the coordinator. >> >> >> > > > > > > > >> >> >> > > > > > > > > Jenkins also presumably has >> >> >> > > > > > > > > credentials to make at least some changes to gerrit - >> >> are >> >> >> > those >> >> >> > > > > > > > privileges >> >> >> > > > > > > > > restrictive enough that it couldn't cause problems >> there >> >> >> too? >> >> >> > > > > > > > >> >> >> > > > > > > > Those are stored only on the coordinator and cannot be >> >> used >> >> >> by >> >> >> > > the >> >> >> > > > > > > slaves. >> >> >> > > > > > > > >> >> >> > > > > > > >> >> >> > > > > > >> >> >> > > > > >> >> >> > > > >> >> >> > > >> >> >> > >> >> >> >> >> >>
