+1

On Fri, Jan 5, 2018 at 1:41 PM, Indhu <[email protected]> wrote:

> Objective is to make sure committers has access to CI. As far as that
> objective is met, it shouldn't matter whether the auth mechanism uses
> GitHub or Apache SSO.
>
> If GitHub SSO is easier to implement, let's go ahead and do that unless
> someone in the list objects.
>
>
> On Fri, Jan 5, 2018 at 11:21 AM Chris Olivier <[email protected]>
> wrote:
>
> > I am fine without a vote unless a vote is required?  Any objections,
> > anyone?  You're sort of adding functionality here, not changing or
> > restricting...  We can always change to Apache later.
> >
> > On Fri, Jan 5, 2018 at 11:18 AM, Marco de Abreu <
> > [email protected]> wrote:
> >
> > > I'd be in favour of GitHub. Shall we open a vote or would you like me
> to
> > > create a POC with GitHub first and afterwards we can check if that's
> > > enough?
> > >
> > > -Marco
> > >
> > > On Fri, Jan 5, 2018 at 8:13 PM, Chris Olivier <[email protected]>
> > > wrote:
> > >
> > > > Apparently Apache supports OATH, so I am open to either.
> > > > Good idea for the docker thing.
> > > >
> > > > On Fri, Jan 5, 2018 at 11:02 AM, Marco de Abreu <
> > > > [email protected]> wrote:
> > > >
> > > > > 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" <
> > > [email protected]
> > > > >:
> > > > >
> > > > > 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 <
> > > > > [email protected]> 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" <
> > > > > > [email protected]>:
> > > > > >
> > > > > > 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" <
> > > > [email protected]
> > > > > >:
> > > > > >
> > > > > > 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 <
> > > > > > [email protected]> 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" <
> > > > > [email protected]
> > > > > > >:
> > > > > > >
> > > > > > > Marco,
> > > > > > >
> > > > > > > Are all committers able to get login access to the Jenkins
> > Server?
> > > > If
> > > > > > not,
> > > > > > > why?
> > > > > > >
> > > > > > > -Chris
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Reply via email to