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