1# Continuous integration and authorization for OpenBMC 2 3Author: Brad Bishop !radsquirrel 4 5Other contributors: None 6 7Created: 2019-01-30 8 9## Problem Description 10 11The OpenBMC project maintains a number of Jenkins CI jobs to ensure incoming 12contributions to the project source code meet a level of quality. Incoming 13contributions can be made by the general public - anyone with a GitHub account. 14However unlikely, it is possible for a bad actor to make code submissions that 15attempt to compromise project resources, e.g. build systems, and as such some 16amount of authorization of contributors must occur to provide some level of 17protection from potential bad actors. 18 19The project already has contributor authorization for CI. This proposal serves 20to describe the drawbacks of the current solution and propose an alternative 21that addresses those drawbacks. 22 23## Background and References 24 25The current authorization solution checks the user for membership in the 26openbmc/general-developers GitHub team. If the contributor is a member of the 27team (or a general-developers sub-team), the automated CI processes are 28triggered without any human intervention. If the contributor is not a member of 29the general-developers team, manual intervention (ok-to-test) is required by a 30project maintainer to trigger the automated CI processes. 31 32Additional reading: https://en.wikipedia.org/wiki/Continuous_integration 33https://jenkins.io/ https://help.github.com/articles/about-organizations/ 34 35## Requirements 36 37The existing method for authorization has a singular problem - the GitHub 38organization owner role. In order for contributors to be added to the 39openbmc/general-developers GitHub team, the contributor must first be a member 40of the openbmc GitHub organization. Only organization owners can invite GitHub 41users to become members of an organization. Organization owners have 42unrestricted access to all aspects of the project - it would be unwise to bestow 43organization ownership for the sole purpose of enabling 44openbmc/general-developers group membership administrative capability. 45 46An alternative authorization method for CI should: 47 48- Not require the GitHub organization owner role to administer the list of users 49 authorized for CI. 50- Enable a hierarchical trust model for user authorization (groups nested within 51 groups). 52 53## Proposed Design 54 55The proposal is to simply migrate the current openbmc/general-developers GitHub 56team, and all subordinate teams, to Gerrit groups: 57 58group: `openbmc/ci-authorized` 59 60group: `xyzcorp/ci-authorized` 61 62group: `abccorp/ci-authorized` 63 64The openbmc/ci-authorized group can contain users that are not associated with 65any specific organization, as well as organizational groups: 66 67group: `openbmc/ci-authorized` contains -> 68 69group `xyzcorp/ci-authorized` 70 71group `abccorp/ci-authorized` 72 73user `nancy` 74 75user `joe` 76 77This proposal also specifies a convention for administration of organizational 78groups: 79 80group: `xyzcorp/ci-authorized-owners` administers -> `xyzcorp/ci-authorized` 81 82group: `abccorp/ci-authorized-owners` administers -> `abccorp/ci-authorized` 83 84group: `openbmc/ci-authorized` administers -> `openbmc/ci-authorized` 85 86Finally, any Jenkins CI jobs must be updated to test for membership of the 87Gerrit group instead of the GitHub team. 88 89New organizational groups (and associated owner groups) will be created when a 90CCLA is signed and accepted by the project. 91 92## Alternatives Considered 93 94Assigning GitHub organization owner roles to organizational group administrators 95was considered but is a major violation of the least-privilege-required 96principle. 97 98## Impacts 99 100GitHub has vastly superior load balancing and backup capability so there is a 101potential for decreased service availability and data loss. 102 103## Testing 104 105Deploy on a live production server �� 106