mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Naveen Swamy <mnnav...@gmail.com>
Subject Re: Commiter access to Jenkins Sevrer
Date Fri, 05 Jan 2018 23:24:58 GMT
this sounds fine to me as long as there is at least one MXNet committer who
is also an admin.

thanks Marco for making this happen :)

 - Naveen

On Fri, Jan 5, 2018 at 2:54 PM, Marco de Abreu <marco.g.abreu@googlemail.com
> wrote:

> I'm proposing following permissions: https://i.imgur.com/uiFBtuW.png. The
> meaning of every permission is explained at https://wiki.jenkins.io/
> display/JENKINS/Matrix-based+security.
>
> Any objections?
>
> On Fri, Jan 5, 2018 at 11:03 PM, Marco de Abreu <
> marco.g.abreu@googlemail.com> wrote:
>
> > I'm currently working on a prototype of SSO based on GitHub and a few
> > issues arose:
> >
> > We are not able to use the permission strategy which determines the
> access
> > rights based on the read/write permission to a project as the
> > Jenkins-plugin is not able to resolve the link between Jenkins-jobs and
> > GitHub-repositories. Instead I would propose to use a role-based approach
> > using https://wiki.jenkins.io/display/JENKINS/Role+Strategy+Plugin. In
> > this case we would have three roles: Anonymous, Administrator and
> > Committer. While everybody would authenticate using their regular GitHub
> > account, the role assignment would have to happen manually. Considering
> > that the amount of administrators and committers doesn't change that
> > frequently, this shouldn't be too much of an issue - auto populating the
> > status is not possible unfortunately.
> >
> > Reason for splitting Administrators and Committers into two separate
> roles
> > has a security reason. At the moment, we're using Chris Oliviers GitHub
> > credentials to populate the commit status. If all committers would gain
> > full admin rights, they would have access to these credentials. Chris is
> > not fine with this approach and would like to limit the amount of people
> > with access to his credentials as much as possible.
> >
> > In order to address his concerns, I propose to add Chris to the committer
> > as well as to the admin role, while all other committers will only
> receive
> > the committer role without read access to the credentials. In a later
> > email, I will make a proposal for the detailed committer role rights. You
> > can check all available options at https://wiki.jenkins.io/
> > display/JENKINS/Matrix-based+security.
> >
> > All people who have access to the underlying AWS account would be granted
> > the Administrator role with full access. At the moment, this would be
> > Meghna Baijal, Gautam Kumar and myself.
> >
> > An alternative solution would be to create a bot account specifically for
> > MXNet CI and use its credentials instead of Chris'. This account requires
> > write permission to the repository, but would give us the advantage that
> > these credentials would be shared within the committers and thus making
> the
> > restrictions regarding credentials obsolete (and Chris would be happy not
> > the see his face within every single PR :P ). I've asked around and
> > received the feedback from multiple people that Apache Infra does not
> want
> > to grant bot accounts write permission to a repository, but I would like
> to
> > confirm back considering that AppVeyor, for example, has a bot account
> with
> > write permission. I would like to check back with a mentor and create an
> > Apache Infra ticket to request details and permission.
> >
> > I would propose to take both approaches at the same time, meaning we can
> > start with Chris in the committer AND admin role while trying to get
> > permission for a bot account in the meantime.
> >
> > wdyt?
> >
> > On Fri, Jan 5, 2018 at 8:21 PM, Chris Olivier <cjolivier01@gmail.com>
> > 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 <
> >> marco.g.abreu@googlemail.com> 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 <cjolivier01@gmail.com>
> >> > 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 <
> >> > > marco.g.abreu@googlemail.com> 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" <
> >> > cjolivier01@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.abreu@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.abreu@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" <
> >> > > cjolivier01@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.abreu@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" <
> >> > > > cjolivier01@gmail.com
> >> > > > > >:
> >> > > > > >
> >> > > > > > Marco,
> >> > > > > >
> >> > > > > > Are all committers able to get login access to the
Jenkins
> >> Server?
> >> > > If
> >> > > > > not,
> >> > > > > > why?
> >> > > > > >
> >> > > > > > -Chris
> >> > > > > >
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message