GitHub SSO allows the neat feature that login and permission can be selected depending on the access rights a user has to a project. Somebody with write access (committers) would be get different permissions than somebody with only read access.
We could check back with Apache for SSO, but this would involve Apache infra. We could put it up to a vote whether to use GitHub or Apache SSO. In order to reproduce a build failure we have been thinking about changing the ci_build.sh in such a way that it can be run manually without Jenkins. The setup I took over binds the Jenkins work directory into the docker containers and uses a few hacks which are hard to reproduce locally. We plan to reengineer this script to make it easier to run manually. But making the AMI public is a good idea! We plan to make the whole infrastructure code (based on Terraform) completely public - at the moment it's in a private repository as it contains credentials, but they will be moved to KMS soon. It would definitely be a good approach to just supply the AMI so everybody could recreate the environment in their own account. -Marco Am 05.01.2018 7:51 nachm. schrieb "Chris Olivier" <cjolivie...@gmail.com>: Well, login to the Jenkins server, I would imagine. github or Apache SSO (does Apache support OAUTH?) seems like a good idea as long as there's a way to not let everyone with a github account log in. Access to actual slave machines could be more restricted, I imagine. Eventually, a public current AMI for a build slave would be good in order to reproduce build or test problems that can't be reproduced locally. wdyt? On Fri, Jan 5, 2018 at 10:41 AM, Marco de Abreu < marco.g.ab...@googlemail.com> wrote: > Would it be an acceptable solution if we add SSO or do you also want access > to the actual AWS account and all machines? > > Yes, the build jobs are automatically getting created for new branches. > > -Marco > > Am 05.01.2018 7:35 nachm. schrieb "Marco de Abreu" < > marco.g.ab...@googlemail.com>: > > I totally agree, this is not the way it should work in an Apache Project. > It's running on an isengard account, meaning it is only accessible for > Amazon employees. The problem is that a compromised account could cause > damage up to 170,000$ per day. There are alarms in place to notice those > cases, but we still have to be very careful. These high limits have been > chosen due to auto scaling being added within the next week's. > > I'd be happy to introduce a committer into the CI process and all the > necessary steps as well as granting them permission. The only restriction > being that it has to be and Amazon employee and access to console, master > and slave only being possible from the Corp network. > > There is no open ticket. What would you like to request? > > -Marco > > > Am 05.01.2018 7:22 nachm. schrieb "Chris Olivier" <cjolivie...@gmail.com>: > > Like John and other mentors were saying, it's not proper for CI to be a > closed/inaccessible environment. Is it running on an Isengard account or > in PROD or CORP or just generic EC2? I think that we should remedy this. > It's very strange that no committers have access at all. Is there a ticket > open to IPSEC? > > On Fri, Jan 5, 2018 at 10:17 AM, Marco de Abreu < > marco.g.ab...@googlemail.com> wrote: > > > Hello Chris, > > > > At the moment this is not possible due Amazon AppSec (Application > security) > > restrictions which does not permit user data and credentials on these > > machines. > > > > I have been thinking about adding single sign on bound to GitHub, but we > > would have to check back with AppSec. > > > > Is the reason for your request still the ability to start and stop > running > > builds? > > > > Best regards, > > Marco > > > > Am 05.01.2018 7:11 nachm. schrieb "Chris Olivier" <cjolivie...@gmail.com > >: > > > > Marco, > > > > Are all committers able to get login access to the Jenkins Server? If > not, > > why? > > > > -Chris > > >
