Commit 4603303c authored by intrigeri's avatar intrigeri
Browse files

Merge remote-tracking branch 'origin/merge-requests/214' into master

parents 93833de5 b88c6abe
......@@ -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]].
......@@ -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/sysadmins/gitlab]]
* end-user documentation: [[contribute/working_together/GitLab]]
* configuration:
- immerda hosts our GitLab instance using [this Puppet
......@@ -251,6 +251,7 @@ Below, importance level is evaluated based on:
- configuration: [[!tails_gitlab tails/gitlab-config]]
* importance: critical (needed to release Tails)
* Tails system administrators administrate this GitLab instance.
* See our [[documentation about GitLab for Tails sysadmins|contribute/working_together/roles/sysadmins/gitlab]].
## Gitolite
......
[[!meta title="GitLab for Tails sysadmins"]]
[[!toc levels=2]]
This page documents what Tails syadmins need to know about our GitLab instance.
The user documentation is kept [[in a separate
page|contribute/working_together/GitLab]].
Tails previously used Redmine, and the migration was coordinated using
[[Salsa|https://salsa.debian.org/tails-team/gitlab-migration]].
# Administration of GitLab
Our friends at <https://www.immerda.ch/> host [[!tails_gitlab desc="our GitLab
instance"]]. We usually contact them through e-mail or their Jabber channel
(see their [[contact info|https://www.immerda.ch/contact.html]]).
The Tails [[system administrators|working_together/roles/sysadmins]]
administrate this GitLab instance. They don't have shell access to the VM
hosting the service so, among many other things, using [[Server
Hooks|https://docs.gitlab.com/ce/administration/server_hooks.html]] is not easy
and would depend on coordination with the service provider.
# 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
Note that GitLab's `root` user is an owner of all projects because that makes
sense for the way Tails currently manages user permissions for the different
groups and projects. Notifications are turned off for that user and it
shouldn't be used for communicating with other users.
<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.
# Interactions with other parts of our infrastructure
The following pieces of the Tails infrastructure interact with GitLab either
directly or indirectly:
- The [[Ticket Gardener|contribute/working_together/roles/ticket_gardener]]
queries GitLab for information about the state of issues and merge
requests.
- The [[Translation
Platform|contribute/working_together/roles/translation_platform]]
constantly merges modifications made through
[[Weblate|https://translate.tails.boum.org]] and pushes them back to the Tails
main repository (see [[the
script|https://gitlab.tails.boum.org/tails/puppet-tails/-/blob/master/files/weblate/scripts/cron.sh]]
for that). We use a local "gatekeeper" repository with a
[[hook|https://gitlab.tails.boum.org/tails/puppet-tails/-/blob/master/files/gitolite/hooks/tails-weblate-update.hook]]
to prevent the Translation Platform from messing with more things than it
should.
- Ikiwiki is notified whenever there's a change in the `master` branch of the
[[main Tails repository|https://gitlab.tails.boum.org/tails/tails]] and
creates/updates `.po` files when new content was added to the Tails website.
For this, GitLab was manually configured to mirror the main Tails repository to
a local repository in the Tails infrastructure, and the local mirror
[[pings|https://gitlab.tails.boum.org/tails/puppet-tails/-/blob/master/files/gitolite/hooks/www_website_ping-post-update.hook]]
Ikiwiki when its master branch was modified. Some other [["underlay"
repositories|https://gitlab.tails.boum.org/tails/puppet-tails/tree/master/manifests/website.pp#n19]]
are also configured to [[cause Ikiwiki to
refresh|https://gitlab.tails.boum.org/tails/puppet-tails/tree/master/files/gitolite/hooks/www_website_underlays-post-update.hook]]
the main website.
- Our [[Jenkins|contribute/working_together/roles/sysadmins/Jenkins]] master
[[is also
notified|https://gitlab.tails.boum.org/tails/puppet-tails/-/blob/master/templates/gitolite/hooks/tails-post-receive.erb]]
when there are relevant changes to the main Tails repository, and its Jenkins
slaves query GitLab to determine [[whether to conduct reproducibility
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]].
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