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: 33 34- <https://en.wikipedia.org/wiki/Continuous_integration> 35- <https://jenkins.io/> 36- <https://help.github.com/articles/about-organizations/> 37 38## Requirements 39 40The existing method for authorization has a singular problem - the GitHub 41organization owner role. In order for contributors to be added to the 42openbmc/general-developers GitHub team, the contributor must first be a member 43of the openbmc GitHub organization. Only organization owners can invite GitHub 44users to become members of an organization. Organization owners have 45unrestricted access to all aspects of the project - it would be unwise to bestow 46organization ownership for the sole purpose of enabling 47openbmc/general-developers group membership administrative capability. 48 49An alternative authorization method for CI should: 50 51- Not require the GitHub organization owner role to administer the list of users 52 authorized for CI. 53- Enable a hierarchical trust model for user authorization (groups nested within 54 groups). 55 56## Proposed Design 57 58The proposal is to simply migrate the current openbmc/general-developers GitHub 59team, and all subordinate teams, to Gerrit groups: 60 61group: `openbmc/ci-authorized` 62 63group: `xyzcorp/ci-authorized` 64 65group: `abccorp/ci-authorized` 66 67The openbmc/ci-authorized group can contain users that are not associated with 68any specific organization, as well as organizational groups: 69 70group: `openbmc/ci-authorized` contains -> 71 72group `xyzcorp/ci-authorized` 73 74group `abccorp/ci-authorized` 75 76user `nancy` 77 78user `joe` 79 80This proposal also specifies a convention for administration of organizational 81groups: 82 83group: `xyzcorp/ci-authorized-owners` administers -> `xyzcorp/ci-authorized` 84 85group: `abccorp/ci-authorized-owners` administers -> `abccorp/ci-authorized` 86 87group: `openbmc/ci-authorized` administers -> `openbmc/ci-authorized` 88 89Finally, any Jenkins CI jobs must be updated to test for membership of the 90Gerrit group instead of the GitHub team. 91 92New organizational groups (and associated owner groups) will be created when a 93CCLA is signed and accepted by the project. 94 95## Alternatives Considered 96 97Assigning GitHub organization owner roles to organizational group administrators 98was considered but is a major violation of the least-privilege-required 99principle. 100 101## Impacts 102 103GitHub has vastly superior load balancing and backup capability so there is a 104potential for decreased service availability and data loss. 105 106## Testing 107 108Deploy on a live production server �� 109