mxnet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marco de Abreu <marco.g.ab...@googlemail.com>
Subject Re: Commiter access to Jenkins Sevrer
Date Fri, 05 Jan 2018 22:54:42 GMT
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