Author: Brad Bishop !radsquirrel Primary assignee: Brad Bishop !radsquirrel Other contributors: None Created: 2019-01-30
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.
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/
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 organization 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:
The proposal is to simply migrate the current openbmc/general-developers GitHub team, and all subordinate teams, to Gerrit groups:
group: openbmc/ci-authorized
group: xyzcorp/ci-authorized
group: abccorp/ci-authorized
The openbmc/ci-authorized group can contain users that are not associated with any specific organization, as well as organizational groups:
group: openbmc/ci-authorized contains ->
group xyzcorp/ci-authorized
group abccorp/ci-authorized
user nancy
user joe
This proposal also specifies a convention for administration of organizational groups:
group: xyzcorp/ci-authorized-owners administers -> xyzcorp/ci-authorized
group: abccorp/ci-authorized-owners administers -> abccorp/ci-authorized
group: openbmc/ci-authorized administers -> openbmc/ci-authorized
Finally, any Jenkins CI jobs must be updated to test for membership of the Gerrit group instead of the GitHub team.
New organizational groups (and associated owner groups) will be created when a CCLA is signed and accepted by the project.
Assigning GitHub organization owner roles to organizational group administrators was considered but is a major violation of the least-privilege-required principle.
GitHub has vastly superior load balancing and backup capability so there is a potential for decreased service availability and data loss.
Deploy on a live production server 😀