From 5399e84fa96ecbdc96a2cf528a6b8a9fbef0bc49 Mon Sep 17 00:00:00 2001 From: Zen Fu Date: Wed, 21 Oct 2020 11:46:18 -0300 Subject: [PATCH] Move GitLab operations doc to new page under sysadmins role (sysadmin#17733) --- .../contribute/working_together/GitLab.mdwn | 154 +----------------- .../working_together/roles/sysadmins.mdwn | 2 +- .../roles/sysadmins/gitlab.mdwn | 153 +++++++++++++++++ 3 files changed, 156 insertions(+), 153 deletions(-) diff --git a/wiki/src/contribute/working_together/GitLab.mdwn b/wiki/src/contribute/working_together/GitLab.mdwn index 835644ddc4..eb5536f5af 100644 --- a/wiki/src/contribute/working_together/GitLab.mdwn +++ b/wiki/src/contribute/working_together/GitLab.mdwn @@ -436,155 +436,5 @@ Please check these views once in a while and talk to us! :) # Operations -## Administration of GitLab - -Our friends at host [[!tails_gitlab desc="our GitLab -instance"]]. - -The Tails [[system administrators|working_together/roles/sysadmins]] -administrate this GitLab instance. - -## Configuration of GitLab - -The configuration of our GitLab instance lives in the private [[!tails_gitlab -tails/gitlab-config]] GitLab project. - -If you have access to this project, you can propose configuration changes: -push a topic branch and submit a merge request. - -This can be useful, for example: - - - to modify group membership when someone joins or leaves a team - - to propose new [[!tails_gitlab groups/tails/-/labels desc="group labels"]] - shared by all our GitLab projects - - to propose a new project under the `tails/` namespace, ensuring our common - project settings & permission model are applied - - - -## Access control - -### Objects - - - _Canonical Git repo_: the authoritative [[!tails_gitlab tails/tails]] - repository, hosted on GitLab - - - _Major branches_: `master`, `stable`, `testing`, `devel`, - and possibly `feature/bullseye` - - - _Release tags_: a signed Git tag that identifies the source code - used to build a specific Tails release; currently all tags - in the authoritative `tails.git` repository are release tags; - the tag name is a version number, with '~' replaced by '-'. - - - _Particularly sensitive data_: confidential data that specific teams - like Fundraising and Accounting need to handle, but that other - contributors generally don't need direct access to. This definitely - include issues; this might include Git repositories at some point. - - Note that as of 2020-03-29, it is undefined: - - - What subset of this data can go to a web-based issue tracker or not.
- This was already a problem with Redmine.
- Fixing this will require discussions between various stakeholders. - - - What subset of this data could live in a cleartext Git - repository hosted here or there, as opposed to requiring - end-to-end encryption between members of these teams. - This is a hypothetical problem for now. - -### Subjects - - - An _admin_: - - can configure GitLab - - As a consequence, an admin can grant themselves - any permission they want if an emergency requires it; - in other situations, better follow due process to request - such status or permissions :) - - MUST comply with our "Level 3" security policy - - - A _committer_: - - can push and force-push to any ref in the canonical Git repo, - including major branches and release tags;
- incidentally, this ensures the following requirement is met: - - their branches are picked up by Jenkins; it follows that they - MUST comply with our "Infrastructure" security policy - - can merge MRs into major branches - - can modify issues metadata - - is allowed to view confidential issues in the [[!tails_gitlab tails/tails]] - GitLab project; that's OK, because particularly sensitive data - lives somewhere else, with stricter access control - - can edit other users' comments - - MUST comply with our "Level 3" security policy - - - A _regular, particularly trusted contributor_: - - can push and force-push to a subset of refs in the canonical Git repo; - this subset MUST NOT include any major branch nor release tag;
- this is required to ensure the following requirement is met: - - their branches are picked up by Jenkins; it follows that they - MUST comply with our "Infrastructure" security policy - - can modify issues metadata - - is allowed to view confidential issues in the [[!tails_gitlab tails/tails]] - GitLab project; that's OK, because particularly sensitive data - lives somewhere else, with stricter access control - - - A _regular contributor_: - - can fork the Git repositories and push changes to their own fork - - can modify issues metadata - - is allowed to view confidential issues in the [[!tails_gitlab tails/tails]] - GitLab project; that's OK, because particularly sensitive data - lives somewhere else, with stricter access control - - - _Anybody with a GitLab account_ on the instance we use: - - can view and submit issues in public projects - - can submit MRs in public projects - -### Implementation - - - -#### Requesting access - -If you need to do something in GitLab and you appear to lack the -needed credentials, please ask the Tails -[[system administrators|working_together/roles/sysadmins#communication]] -to grant you more power. - -For example, you will need "Reporter" access on the [[!tails_gitlab -tails/tails]] project in order to add labels or assign issues. - -#### Adding/removing access - -Do not grant access via the web interface: - - - Such manual changes would be later overwritten by automated processes. - - Manual changes can easily have side effects that violate our access control - requirements. - -Instead, after following the relevant process (if any), -request the access modification from the Tails -[[system administrators|working_together/roles/sysadmins#communication]]. - -#### Relevant GitLab doc - - - [[!tails_gitlab help/user/permissions.html desc="Permissions"]] - - [[!tails_gitlab help/user/project/merge_requests/authorization_for_merge_requests.html desc="Authorization for Merge requests"]] - - [[!tails_gitlab help/user/project/protected_branches.html desc="Protected Branches"]] - - [[!tails_gitlab help/user/group/index.md desc="Groups"]] - -#### Access levels - -We use the [[!tails_gitlab -help/user/project/merge_requests/authorization_for_merge_requests.html#protected-branch-flow -desc="Protected branch flow"]]: - - - Our major branches and release tags are marked as "Protected". - - Committers get "Maintainer" access. - - Regular, particularly trusted contributors, who are not granted full commit - access but have access to our CI, get "Developer" access. They can push - a topic branch to the canonical Git repository and our CI will pick it up. - They can also modify any non-protected topic branch. - - Other contributors get access strictly lower than "Developer". - They push topic branches to their own fork of the repository and - create merge requests. - - Our Jenkins CI jobs generation process is the same as in pre-GitLab days. +See our documentation about [[GitLab for Tails +sysadmins|contribute/working_together/roles/sysadmins/gitlab]]. diff --git a/wiki/src/contribute/working_together/roles/sysadmins.mdwn b/wiki/src/contribute/working_together/roles/sysadmins.mdwn index 50012cb055..c513743a59 100644 --- a/wiki/src/contribute/working_together/roles/sysadmins.mdwn +++ b/wiki/src/contribute/working_together/roles/sysadmins.mdwn @@ -239,7 +239,7 @@ Below, importance level is evaluated based on: - host Tails issues - host most Tails [[Git repositories|contribute/git]] * access: public + some data with more restricted access -* operations documentation: [[contribute/working_together/GitLab#operations]] +* operations documentation: [[contribute/working_together/roles/sysadmin/gitlab]] * end-user documentation: [[contribute/working_together/GitLab]] * configuration: - immerda hosts our GitLab instance using [this Puppet diff --git a/wiki/src/contribute/working_together/roles/sysadmins/gitlab.mdwn b/wiki/src/contribute/working_together/roles/sysadmins/gitlab.mdwn index 5641fd9823..8fddcede17 100644 --- a/wiki/src/contribute/working_together/roles/sysadmins/gitlab.mdwn +++ b/wiki/src/contribute/working_together/roles/sysadmins/gitlab.mdwn @@ -75,3 +75,156 @@ directly or indirectly: tests|https://gitlab.tails.boum.org/tails/puppet-tails/-/blob/master/files/jenkins/slaves/isobuilders/decide_if_reproduce]] and [[whether to send notifications through e-mail|https://gitlab.tails.boum.org/tails/puppet-tails/-/blob/master/files/jenkins/slaves/isobuilders/output_ISO_builds_and_tests_notifications]]. + +# Administration of GitLab + +Our friends at host [[!tails_gitlab desc="our GitLab +instance"]]. + +The Tails [[system administrators|working_together/roles/sysadmins]] +administrate this GitLab instance. + +# Configuration of GitLab + +The configuration of our GitLab instance lives in the private [[!tails_gitlab +tails/gitlab-config]] GitLab project. + +If you have access to this project, you can propose configuration changes: +push a topic branch and submit a merge request. + +This can be useful, for example: + + - to modify group membership when someone joins or leaves a team + - to propose new [[!tails_gitlab groups/tails/-/labels desc="group labels"]] + shared by all our GitLab projects + - to propose a new project under the `tails/` namespace, ensuring our common + project settings & permission model are applied + + + +# Access control + +## Objects + + - _Canonical Git repo_: the authoritative [[!tails_gitlab tails/tails]] + repository, hosted on GitLab + + - _Major branches_: `master`, `stable`, `testing`, `devel`, + and possibly `feature/bullseye` + + - _Release tags_: a signed Git tag that identifies the source code + used to build a specific Tails release; currently all tags + in the authoritative `tails.git` repository are release tags; + the tag name is a version number, with '~' replaced by '-'. + + - _Particularly sensitive data_: confidential data that specific teams + like Fundraising and Accounting need to handle, but that other + contributors generally don't need direct access to. This definitely + include issues; this might include Git repositories at some point. + + Note that as of 2020-03-29, it is undefined: + + - What subset of this data can go to a web-based issue tracker or not.
+ This was already a problem with Redmine.
+ Fixing this will require discussions between various stakeholders. + + - What subset of this data could live in a cleartext Git + repository hosted here or there, as opposed to requiring + end-to-end encryption between members of these teams. + This is a hypothetical problem for now. + +## Subjects + + - An _admin_: + - can configure GitLab + - As a consequence, an admin can grant themselves + any permission they want if an emergency requires it; + in other situations, better follow due process to request + such status or permissions :) + - MUST comply with our "Level 3" security policy + + - A _committer_: + - can push and force-push to any ref in the canonical Git repo, + including major branches and release tags;
+ incidentally, this ensures the following requirement is met: + - their branches are picked up by Jenkins; it follows that they + MUST comply with our "Infrastructure" security policy + - can merge MRs into major branches + - can modify issues metadata + - is allowed to view confidential issues in the [[!tails_gitlab tails/tails]] + GitLab project; that's OK, because particularly sensitive data + lives somewhere else, with stricter access control + - can edit other users' comments + - MUST comply with our "Level 3" security policy + + - A _regular, particularly trusted contributor_: + - can push and force-push to a subset of refs in the canonical Git repo; + this subset MUST NOT include any major branch nor release tag;
+ this is required to ensure the following requirement is met: + - their branches are picked up by Jenkins; it follows that they + MUST comply with our "Infrastructure" security policy + - can modify issues metadata + - is allowed to view confidential issues in the [[!tails_gitlab tails/tails]] + GitLab project; that's OK, because particularly sensitive data + lives somewhere else, with stricter access control + + - A _regular contributor_: + - can fork the Git repositories and push changes to their own fork + - can modify issues metadata + - is allowed to view confidential issues in the [[!tails_gitlab tails/tails]] + GitLab project; that's OK, because particularly sensitive data + lives somewhere else, with stricter access control + + - _Anybody with a GitLab account_ on the instance we use: + - can view and submit issues in public projects + - can submit MRs in public projects + +## Implementation + + + +### Requesting access + +If you need to do something in GitLab and you appear to lack the +needed credentials, please ask the Tails +[[system administrators|working_together/roles/sysadmins#communication]] +to grant you more power. + +For example, you will need "Reporter" access on the [[!tails_gitlab +tails/tails]] project in order to add labels or assign issues. + +### Adding/removing access + +Do not grant access via the web interface: + + - Such manual changes would be later overwritten by automated processes. + - Manual changes can easily have side effects that violate our access control + requirements. + +Instead, after following the relevant process (if any), +request the access modification from the Tails +[[system administrators|working_together/roles/sysadmins#communication]]. + +### Relevant GitLab doc + + - [[!tails_gitlab help/user/permissions.html desc="Permissions"]] + - [[!tails_gitlab help/user/project/merge_requests/authorization_for_merge_requests.html desc="Authorization for Merge requests"]] + - [[!tails_gitlab help/user/project/protected_branches.html desc="Protected Branches"]] + - [[!tails_gitlab help/user/group/index.md desc="Groups"]] + +### Access levels + +We use the [[!tails_gitlab +help/user/project/merge_requests/authorization_for_merge_requests.html#protected-branch-flow +desc="Protected branch flow"]]: + + - Our major branches and release tags are marked as "Protected". + - Committers get "Maintainer" access. + - Regular, particularly trusted contributors, who are not granted full commit + access but have access to our CI, get "Developer" access. They can push + a topic branch to the canonical Git repository and our CI will pick it up. + They can also modify any non-protected topic branch. + - Other contributors get access strictly lower than "Developer". + They push topic branches to their own fork of the repository and + create merge requests. + - Our Jenkins CI jobs generation process is the same as in pre-GitLab days. -- GitLab