Skip to content

GitLab

Commit 5399e84f authored by Zen Fu's avatar Zen Fu
Browse files
Options

Move GitLab operations doc to new page under sysadmins role (sysadmin#17733)

parent e0c68ad6
Hide whitespace changes
Inline Side-by-side
Showing with 156 additions and 153 deletions
wiki/src/contribute/working_together/GitLab.mdwn
View file @ 5399e84f
......@@ -436,155 +436,5 @@ Please check these views once in a while and talk to us! :)
# Operations
## Administration of GitLab
Our friends at <https://www.immerda.ch/> 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
<a id="access-control"></a>
## 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.<br/>
This was already a problem with Redmine.<br/>
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;<br/>
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;<br/>
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
<a id="request-access"></a>
#### 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]].
wiki/src/contribute/working_together/roles/sysadmins.mdwn
View file @ 5399e84f
......@@ -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
......
wiki/src/contribute/working_together/roles/sysadmins/gitlab.mdwn
View file @ 5399e84f
......@@ -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 <https://www.immerda.ch/> 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
<a id="access-control"></a>
# 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.<br/>
This was already a problem with Redmine.<br/>
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;<br/>
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;<br/>
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
<a id="request-access"></a>
### 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.
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment