Jenkins CI authorization

Brad Bishop bradleyb at fuzziesquirrel.com
Thu Jan 31 13:21:06 AEDT 2019


I'd like to migrate our "general-developers" group from Github to Gerrit.  You
can find the rationale below - I've filled out the design template and included
it in this email.

I know, I know...it seems like a minor change to fill out the design template -
but at least the magic behind 'Ok to test' will be written down somewhere.

You can reply with comments, or just head over to
https://gerrit.openbmc-project.xyz/#/c/openbmc/docs/+/17795/ and leave feedback
there.

thx - brad

---------------------------------------------------------------------
# Continuous integration and authorization for OpenBMC

Author:
  Brad Bishop !radsquirrel
Primary assignee:
  Brad Bishop !radsquirrel
Other contributors:
  None
Created:
  2019-01-30

## Problem Description
The OpenBMC project maintains a number of Jenkins CI jobs to ensure incoming
contributions to the project source code meet a level of quality.  Incoming
contributions can be made by the general public - anyone with a Github account.
However unlikely, it is possible for a bad actor to make code submissions that
attempt to compromise project resources, e.g. build systems, and as such some
amount of authorization of contributors must occur to provide some level of
protection from potential bad actors.


The project already has contributor authorization for CI.  This proposal serves
to describe the drawbacks of the current solution and propose an alternative
that addresses those drawbacks.

## Background and References
The current authorization solution checks the user for membership in the
openbmc/general-developers Github team.  If the contributor is a member of the
team (or a general-developers sub-team), the automated CI processes are
triggered without any human intervention.  If the contributor is not a member of
the general-developers team, manual intervention (ok-to-test) is required by a
project maintainer to trigger the automated CI processes.


Additonal reading:
https://en.wikipedia.org/wiki/Continuous_integration
https://jenkins.io/
https://help.github.com/articles/about-organizations/

## Requirements
The existing method for authorization has a singular problem - the Github
organization owner role.  In order for contributors to be added to the
openbmc/general-developers Github team, the contributor must first be a member
of the openbmc Github organization.  Only organziation owners can invite Github
users to become members of an organization.  Organization owners have
unrestricted access to all aspects of the project - it would be unwise to bestow
organization ownership for the sole purpose of enabling
openbmc/general-developers group membership administrative capability.


An alternative authorization method for CI should:
 - Not require the Github organization owner role to administer the list of
   users authorized for CI.
 - Enable a hierarchical trust model for user authorization (groups nested
   within groups).

## Proposed Design
The proposal is to simply migrate the current openbmc/general-developers Github
team, and all subordinate teams, to Gerrit groups:

group: xyzcorp
group: abccorp

The general-developers group can contain users that are not associated with any
specific organization, as well as organizational groups:

group: general-developers
contains:
    group xyzcorp, group abccorp, nancy, joe

This proposal also specifies a convention for administration of organizational
groups:

group: xyzcorp-admin administers -> xyzcorp
group: abccorp-admin administers -> abccorp
group: general-developers-admin administers -> general-developers

Finally, any Jenkins Ci jobs must be updated to test for membership of the
Gerrit group instead of the Github team.

## Alternatives Considered
Assigning Github organization owner roles to organizational group administrators
was considered but is a major violation of the least-priviledge-required
principle.

## Impacts
Github has vastly superior load balancing and backup capability so there is a
potential for decreased service availability and data loss.

## Testing
Deploy on a live production server 😀


More information about the openbmc mailing list