Security settings

Administrator account

The instance starts with the root administrator account, whose password is generated during the installation.

1. Sign in as root with the initial password.
2. Open the user menu and select “Edit profile”.
3. Go to “Access” → “Password and authentication” and set a new password.
4. Keep the new password outside the instance.

After the password is changed, remove the initial password from the place the delivery keeps it:

Sign-up and sign-in

New user accounts

After an installation of the Linux package, of Omnibus Docker or of the Helm Chart, anyone who reaches the instance over the network creates an account for themselves. To close registration:

1. Go to “Admin” → “Settings” → “General”.
2. Expand “New user account restrictions”.
3. Clear the “Allow new user accounts” checkbox.
4. Click “Save changes”.

In the Deckhouse Kubernetes Platform module, registration is closed after the installation; the operator sets it from the appConfig.signUpEnabled field of the CodeInstance resource.

In the other installation types the same is done from the console:

sudo gitlab-rails runner 'ApplicationSetting.current.update!(signup_enabled: false)'
sudo gitlab-rails runner 'puts ApplicationSetting.current.signup_enabled'

docker exec code gitlab-rails runner 'ApplicationSetting.current.update!(signup_enabled: false)'
docker exec code gitlab-rails runner 'puts ApplicationSetting.current.signup_enabled'

d8 k -n code exec deploy/code-toolbox -- gitlab-rails runner 'ApplicationSetting.current.update!(signup_enabled: false)'
d8 k -n code exec deploy/code-toolbox -- gitlab-rails runner 'puts ApplicationSetting.current.signup_enabled'

The second command prints false while registration is closed.

While registration stays open, the same section of the admin area limits who gets an account:

• “Require admin approval for new user accounts” — an account waits for an administrator before its first sign-in;
• “Email confirmation settings” — in the “Hard” mode the address is confirmed before the first sign-in;
• “Domains allowed for new users” and “Domain denylist” — the email domains that may and may not register;
• “Minimum password length (number of characters)” — applies to accounts that sign in with a password, 8 characters by default.

None of these settings applies to an account created through an external provider.

Sign-in restrictions

1. Go to “Admin” → “Settings” → “General”.
2. Expand “Sign-in restrictions”.
3. Select “Enforce two-factor authentication for administrators”.
4. Click “Save changes”.

The same section holds:

• “Enable Admin Mode” — the administrator authenticates once more before the admin area opens;
• “Email notification for unknown sign-ins” — the user gets a message when a sign-in comes from a device or an IP address that was not used before;
• “Require email verification when account is locked” — a locked account confirms its mailbox before it signs in again.

Two-factor authentication for every user of the instance, the enabled Git access protocols and password authentication for Git over HTTPS are set in the same section, see the Users and access page. Password authentication for the web interface is described on the Authentication page.

External authentication provider

With LDAP, SAML or OIDC, the accounts and the group memberships live in the directory, and an account closed there loses access to Deckhouse Code without an action inside the instance. The providers, the synchronization and the linking of accounts are described on the Authentication page.

Visibility and access control

The settings are in “Admin” → “Settings” → “General” → “Visibility and access controls”:

• “Default project visibility”, “Default snippet visibility” and “Default group visibility” — set them to “Private”, so that a new project, snippet or group is closed until someone opens it;
• “Restricted visibility levels” — the levels a non-administrator cannot choose. With the public and internal levels selected here, a regular user creates private projects only;
• the retention period for a deleted group or project — the time during which a deletion is still reversible;
• “Default minimum role required to create projects” and “Enabled Git access protocols” — see the Users and access page;
• “RSA SSH keys”, “DSA SSH keys”, “ECDSA SSH keys” and the other key lists — each one forbids its algorithm or sets the minimum key length the instance accepts from a user.

Forbid DSA keys, set the minimum length of an RSA key to 3072 bits and of an ECDSA key to 256 bits. Leave the ECDSA_SK and ED25519_SK lists enabled while hardware FIDO2 or U2F keys are in use.

User account restrictions

The settings are in “Admin” → “Settings” → “General” → “Account and limit”:

• “Default projects limit” — the maximum number of projects one user creates;
• “Session timeout duration” — the session length in minutes, 7 days by default; the change applies after the instance is restarted;
• “Remember me” → “Allow users to extend their session” — with the checkbox cleared, a session ends when the timeout expires, whatever the user does;
• “Require expiration date” — a new personal, group or project token gets an expiry date;
• “User OAuth applications” — with the checkbox cleared, a user does not register an OAuth client of their own on the instance;
• the “User restrictions” group — group and project creation, see the Users and access page.

Restart the instance after changing the session length:

sudo gitlab-ctl restart

docker restart code

d8 k -n code rollout restart deploy/<WEBSERVICE_DEPLOYMENT>

d8 k -n d8-code rollout restart deploy -l 'app.kubernetes.io/component in (webservice, sidekiq)'

Import and export

The settings are in “Admin” → “Settings” → “General” → “Import and export settings”:

• “Import sources” — the systems a project is imported from; every source is off by default, and the “Repository by URL” source accepts any Git repository by its address;
• “Project export” — with the checkbox cleared, a user does not build a .tar.gz archive of a project to carry it to another instance;
• “Allow migrating GitLab groups and projects by direct transfer” — off by default;
• “Silent exports by admins” — while the checkbox is selected, an export made by an administrator leaves no audit event.

Repository settings

Default branch

1. Go to “Admin” → “Settings” → “Repository”.
2. Expand “Default branch”.
3. In the “Initial default branch name” field, enter the branch name every new repository starts with.
4. In “Initial default branch protection”, select the protection a new repository’s default branch starts with, then set “Allowed to push” and “Allowed to merge” to the role the branch accepts changes from.
5. Clear “Allowed to force push” and “Allow developers to push the initial commit”.
6. Click “Save changes”.

The settings apply to repositories created after the change; an existing repository keeps its branch rules.

Push rules

The “Push rules” section of the same page sets the rules every project of the instance starts with: the regular expressions for the commit message, the author email address, the file name and the branch name, the committer checks, and the block on committing secrets such as pem or id_rsa files. A rule whose override is cleared cannot be changed in a group or a project. The rules are described on the Push rules page, and the instance level on the Users and access page.

CI/CD settings

Runner authentication tokens

“Admin” → “Settings” → “CI/CD” → “Continuous Integration and Deployment” sets the lifetime of the authentication tokens of instance, group and project runners; the lifetime is unlimited until a value is entered. An online runner rotates its token as the expiry approaches; a runner that was offline at that moment is registered anew.

Runners

“Admin” → “Settings” → “CI/CD” → “Runners” holds:

• “Fetch GitLab Runner release version data from GitLab.com” — while the checkbox is selected, the instance requests the runner release versions from GitLab.com; clear it on an installation that has no access to the internet;
• “Allow runner registration token” — with the checkbox cleared, a runner is registered with an authentication token of its own instead of a registration token shared by the instance, the group or the project.

Job token permissions

“Admin” → “Settings” → “CI/CD” → “Job token permissions” holds “Enable and enforce job token allowlist for all projects”. While it is selected, a job reaches another project only when that project lists the job’s project in its allowlist, and the option that opens a project to every group and project is hidden.

Spam and bot protection

“Admin” → “Settings” → “Reporting” → “Spam and Anti-bot Protection” holds reCAPTCHA and the limit on the number of accounts per IP address. The section applies to an instance that is reachable from the internet.

Usage statistics

In “Admin” → “Settings” → “Metrics and profiling”, the “Usage statistics” section holds the version check and Service Ping, and the “Event tracking” section holds the sending of events. Event tracking is off and its checkbox is read-only; a version check that is off is not turned back on from the interface.

Network rate limits

“Admin” → “Settings” → “Network” holds the request limits: “User and IP rate limits” for the instance as a whole, “Git HTTP rate limits”, “Git LFS rate limits”, “Search rate limits”, “Pipeline creation rate limits” and “Import and export rate limits” for their own kind of request, each overriding the general limit. “Outbound requests” restricts the addresses that hooks and integrations reach from the instance.

Platform-level hardening

In the Deckhouse Kubernetes Platform module, the traffic between the components, access to the d8-code namespace, the network policies and the export of audit events are set in the cluster. They are described in Security recommendations in the module documentation.