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