Access Control
==============

This section defines how access to the Shyft project is granted, managed,
and reviewed. The goal is to ensure that all access is intentional,
traceable, and aligned with the project's security principles.

Roles and responsibilities
--------------------------

Shyft uses a role-based access model aligned with GitLab's permission system.

The primary roles are:

- Owner:
  Full administrative control over the project, including access control,
  protected branches, and release procedures.

- Maintainer:
  Delegated responsibility for managing contributors, reviewing code,
  and maintaining specific parts of the project.

- Developer and Contributors:
  Active contributors with write access to the repository.

- Guest:
  Read-only or limited access for observers or inactive contributors.

Detailed day-to-day responsibilities and workflows are described
in the Shyft contribution guide (wiki).


Relationship to Contribution Guide
-----------------------------------

The Shyft contribution guide (wiki) describes practical workflows,
development processes, and collaboration patterns.

This document defines the formal access control and authority model
that governs those activities.


Approval of contributor access
------------------------------

Access is granted based on trust, affiliation, and demonstrated competence.

- Owners have ultimate authority over all access decisions.
- Maintainers may approve and onboard contributors within their domain.
- In practice, maintainers typically represent organizations contributing
  to Shyft (e.g., Statkraft, UiO), and are responsible for evaluating
  the technical maturity and trustworthiness of contributors.

This delegated model enables scalable onboarding while maintaining control.

Protected branches and release tags
------------------------------------

Modification of protected branches and creation of release tags are restricted.

- Only Owners and Maintainers may:
  - create or approve release tags
  - modify protected branches

These permissions are enforced through GitLab branch protection rules.

Use of release-signing keys
----------------------------

Release signing is strictly controlled.

- Release-signing keys are controlled by the Owner.
- The corresponding public key is published as part of the official
  Shyft documentation and release verification process.
- All official releases must be signed using this key.

This creates a verifiable trust anchor for all distributed artifacts.

Contributor authentication requirements
-----------------------------------------

All contributors must establish a verifiable identity before being granted access.

- A GitLab account must be configured with:
  - SSH keys for repository access
  - GPG keys for commit signing

- GPG signing is required prior to granting developer-level access.

Documented procedures are provided to assist both new and existing contributors
in setting up compliant environments.

Access review and lifecycle management
---------------------------------------

Access is reviewed regularly to ensure it remains minimal and relevant.

- The Owner performs periodic reviews (at least annually) of all users
  with repository access.
- Reviews include:
  - last activity
  - continued affiliation and need for access

- Accounts with no recent activity may be downgraded (e.g., to Guest).
- Access can be re-granted upon request if needed.

This ensures that inactive or unnecessary access is removed over time.

Emergency and break-glass access
----------------------------------

Shyft maintains resilience against loss of access to primary infrastructure.

- Multiple Owners (currently four) hold administrative access to GitLab.
- Access levels are intentionally distributed to reduce single-point-of-failure risk.

In the event of GitLab access loss:

- The Git repository is distributed by design, and multiple complete copies exist.
- The project can be reconstructed from existing clones and signed releases.

To further strengthen recovery guarantees:

- The project may maintain an offline, air-gapped repository containing:
  - verified release tags
  - signed source snapshots
  - release artifacts

- This repository can serve as a trusted recovery baseline,
  ensuring that the project can be rebuilt from the latest verified release.

This approach aligns with Shyft's principle of verifiable and recoverable supply chains.