Group owners and project maintainers apply these settings to protect projects on a daily basis. Open the group’s or the project’s “Settings” page in the left sidebar, then the tab named in each section below.
Group-level settings
Settings a group owner applies to every project in the group.
General
Set the group visibility level to “Private” wherever possible, in “Settings” → “General”: the group and its projects are visible only to members, which lowers the risk of unintended access to source code and issues.
Group access rights and capabilities
Configure access rights and capabilities for the group in “Settings” → “General”:
- Whether members can invite groups outside this group and its subgroups.
- Whether projects in this group can be transferred to other groups.
- The wiki access level for the group.
- The Git access protocols (SSH, HTTP(S)) enabled for the group.
- The minimum role required to create projects in the group.
- The minimum role required to create subgroups.
- Whether members can create group and project access tokens in the group. A group access token can only be created by a member with the
Ownerrole; a project access token created by a group member is limited by that member’s role in the project. - Whether two-factor authentication is required for every member of the group, and the grace period before it is enforced. Subgroups cannot set their own two-factor authentication rules once this is enabled.
- Whether Pages content is restricted to project members for every project in the group.
Repository
Settings that apply to the Git repository of every project in the group.
Deploy tokens
Deploy tokens grant access to the group’s repositories and packages without a personal account. Review deploy tokens regularly, remove the ones no longer in use, and give the remaining tokens a clear description, a limited scope, and an expiration date.
Default branch
Configure default branch protection for every project in the group in “Settings” → “Repository”. A project inherits this setting from the group unless the group allows a project to override it.
Push rules
Configure push rules for every project in the group in “Settings” → “Repository”. If overriding the instance-level rules is allowed, override them here for a policy specific to the group. See Push rules for the available rules.
Prohibit overriding these rules at the project level unless a project needs its own policy.
CI/CD
Settings that apply to CI/CD pipelines and variables in every project in the group.
Pipelines
Enable “Enable JWT format for CI/CD job tokens” in “Settings” → “CI/CD”.
Variables
Mask CI/CD variables that hold sensitive values, in “Settings” → “CI/CD”. A masked variable’s value does not appear in job logs or audit events.
Project-level settings
Settings a project maintainer or owner applies to a single project.
General
General project settings control who can view the project and what they can do without an assigned role.
Project visibility, features, and permissions
Set the project visibility to “Private” wherever possible, in “Settings” → “General”. Enable “Require authentication to view media files” to prevent unauthenticated access to media embedded in issues and merge requests, and restrict access to LFS objects, merge requests, branches, package and container registries, issues, environments, and releases according to your organization’s requirements. Downloading from the package registry is disabled for every user by default.
Repository
Settings that apply to the project’s Git repository.
Push rules
Configure push rules for the project in “Settings” → “Repository”. If overriding the group-level rules is allowed, override them here for a policy specific to the project. See Push rules for the available rules.
Protected branches
Use protected branches, in “Settings” → “Repository”, to control which roles can merge into the main and stable branches or push to them directly. By default, only members with the Maintainer or Owner role can push directly to a protected branch. See Protected branches.
Protected tags
If tags mark releases or other significant points in the project’s history, restrict which role can create tags matching a pattern, in “Settings” → “Repository”. For example, restrict version tags matching *_v* to the Maintainer role.
Deploy tokens
Deploy tokens grant access to the project’s repository and packages without a personal account. Review deploy tokens regularly, remove the ones no longer in use, and give the remaining tokens a clear description, a limited scope, and an expiration date.
Deploy keys
Deploy keys are an alternative to deploy tokens for granting access to the repository without a personal account, in “Settings” → “Repository”. The same review applies to them: scope, description, and expiration date.
Merge requests
Settings that control how a merge request is reviewed and merged into the project’s main or stable branches, in “Settings” → “Merge requests”.
Merge checks
- Enable “Pipelines must succeed” and add the security checks the project needs to its pipeline: secret scanning, static and dynamic analysis, and vulnerability scanning for dependencies and container images.
- Enable “All discussions must be resolved” so that code still under review cannot reach the main or stable branches.
Assign code paths to reviewers with a CODEOWNERS file, and configure merge request approval rules to set the minimum number of approvers, to prohibit an author from approving their own merge request, and to restrict who can change the approval rules themselves, for example by including the review policy file from another project through the include mechanism. See CODEOWNERS and Approval rules for merge requests.
CI/CD
Settings that apply to CI/CD pipelines, variables, and tokens in the project, in “Settings” → “CI/CD”.
Pipelines
Enable “Use separate caches for protected branches”. Assign a CODEOWNERS entry to .gitlab-ci.yml to control who can change the pipeline configuration, and require manual approval before a critical pipeline or job runs.
Variables
Mark CI/CD variables that hold sensitive values as protected and masked, and store secrets in CI/CD variables or in an external Vault or Deckhouse Stronghold instead of the repository. See External Vault integration. Enable “Show pipeline variables” to display pipeline variable values in job logs, which helps diagnose pipeline failures and detect unexpected values.
Pipeline trigger tokens
A pipeline trigger token runs a pipeline with the permissions of the member who issued it. Review trigger tokens with the same care as CI/CD job token permissions, below.
CI/CD job token permissions
Restrict which groups and projects can access this project’s data from their own pipelines, in “Settings” → “CI/CD”, using an allowlist.
Packages and registries
Protect packages published to the project’s package registry with the protected packages mechanism, in “Settings” → “Packages and registries”, restricting access to members above a given role. The same applies to the container registry.