Code module: Security recommendations

This document represent security recommendation of each level for Deckhouse Code installation in Deckhouse Kubernetes Platform: infrastructure, application settings and daily routines. It contains best known practices from official documentation of related instruments.

Security recommendations for infrastructure level (target DKP)

This section focused on security practices for Deckhouse Code installation on target infrastructure, including product level practices implementations. Requires access to target DKP cluster for administration d8-code namespace and CodeInstance custom resource

Components communication settings (TLS)

Implemented by default

Severity: Critical

All inter-components connections secured with TLS encryption inside namespace

Incoming traffic settings

Implemented by default

Severity: Critical

The nginx.ingress.kubernetes.io/backend-protocol: https, proxy-ssl-verify: 'on' annotations and the use of a dedicated TLS secret (proxy-ssl-secret) in the Ingress resource configuration ensure encryption and authentication of the connection between nginx-ingress-controller and backend services (i.e., Deckhouse Code components directly). This eliminates the possibility of data interception or spoofing within the cluster, enhancing the overall security of internal traffic.

Secret rotation settings for product access

Implemented by default

Severity: Critical

The operator uses the deckhouse-sa service account for fine-tuning and retrieving technical information about Deckhouse Code via API. For authorization, it uses tokens whose values are stored in secrets within the d8-code namespace. The operator automatically rotates the tokens it uses on a schedule to enhance the security level of the product’s perimeter.

Stay on the latest product version

Implemented by default

Severity: Moderate

It is recommended to regularly update the Deckhouse Code module to receive timely fixes for any security-related issues. To fine-tune the update parameters, use the ModuleUpdatePolicy resource.

Access to the d8-code namespace

Severity: Critical

The d8-code namespace contains not only application pods but also configuration with sensitive information, such as encryption keys, TLS certificates and keys, access tokens for the Deckhouse Code API, and so on.

Access to d8-code must be restricted to a limited and verified set of individuals or service accounts. Such access is required for maintaining Deckhouse Code, including manually triggering backup, checking the running application state, and enabling certain features via the rails console.

To access the d8-code namespace, Role / RoleBinding primitives should be used (not ClusterRole, unless required).

For example, the manifest below grants the user with email code@deckhouse.ru the PrivilegedUser access level. More details about the Deckhouse Kubernetes Platform role model can be found at this link.

These permissions are sufficient for accessing containers, reading secrets, and deleting pods of the Deckhouse Code module located in the d8-code namespace.

apiVersion: deckhouse.io/v1
kind: ClusterAuthorizationRule
metadata:
  name: code-test
spec:
  accessLevel: PrivilegedUser
  allowScale: false
  namespaceSelector:
    labelSelector:
      matchExpressions: []
      matchLabels:
        module: code
  portForwarding: false
  subjects:
    - kind: User
      name: code@deckhouse.ru

Rotate the administrator account password

Severity: Critical

Immediately after deploying the product, it is necessary to obtain the administrator password from the initial-root-password secret, change it, and store it in a secure location, thereby invalidating the secret’s content. The password in the secret is intended to be used by the administrator only for the initial system setup.

To obtain the administrator password, use the following command:

kubectl -n d8-code get secret initial-root-password -o jsonpath='{.data.password}' | base64 -d

To change the password, log in to the application interface, click on the user avatar, and select the “Settings” section. In the settings, select the “Password” menu and change the password.

Configure network access policies in the d8-code namespace

Severity: Moderate

To minimize attack vectors and reduce the access surface, it is recommended to configure and use Kubernetes NetworkPolicy in accordance with the organization’s needs. An example of how to configure NetworkPolicy is described at this link.

Network connectivity is described at this link.

Audit event export

Severity: Moderate

It is recommended to configure an event collector to the company’s SIEM system using the streaming of security audit events to stdout by Deckhouse Code components in CEF format.

What to collect:

In the webservice-default and sidekiq-default deployments, there is a sidecar container audit that streams audit events in CEF format to stdout.

Example: kubectl -n d8-code logs deployments/webservice-default -c audit

It is recommended to collect these logs and deliver them to your SIEM system using the log shipper utilized in your Deckhouse Kubernetes Platform installation.

Security recommendations for application settings during deployment

This section covers the Deckhouse Code product settings itself, user management, authentication, audit, and CI/CD protection. Most settings are available through the UI in the administrative panel; otherwise, it is explicitly stated.

LDAP / SSO integration

Severity: Critical

It is recommended to use LDAP / SAML / OIDC for centralized authentication, disable local accounts where possible, and synchronize groups (Group Sync). This helps reduce the attack surface and improves the convenience of granting and revoking user access rights.

Configured using the corresponding section in the Kubernetes CodeInstance CR. More details here.

Deckhouse Code in-application settings

Project and group visibility settings and access control

Partially implemented by default

Severity: Critical

How to find: Navigate to the administrator panel by clicking the Admin button at the bottom of the menu on the right. In the Settings section, go to the General section and expand the “Visibility and access control” menu. In the menu, review the settings and change them as indicated below:

It is required to set the project content visibility and configure Git access protocols.

• Default minimum role for project creation - Implemented by default - it is recommended to set the default minimum role for project creation to no lower than Developers
• Project deletion protection - Implemented by default - a period should be configured during which a deleted project or group can be restored; the recommended period is 7 days
• Default project visibility level - Implemented by default - it is recommended to set the default project visibility level to Private
• Default snippet visibility level - Implemented by default - it is recommended to set the default snippet visibility level to Private
• Default group visibility level - Implemented by default - it is recommended to set the default group visibility level to Private
• Visibility level restrictions - it is recommended to prohibit non-administrators from using the selected visibility levels. The minimum required visibility levels for new projects should be configured. For example, it is advisable to check the “Public” and “Internal” checkboxes to allow regular users to create projects only with the Private visibility level
• Enabled Git access protocols - it is recommended to allow only the protocols in use (SSH or HTTP(S)); if one of them is not needed, it should be disabled to restrict repository downloads via one of the protocols
• SSH keys - the allowed algorithms and key sizes should be configured. Available algorithms: RSA, DSA, ECDSA, ED25519, ECDSA_SK, ED25519_SK. The use of deprecated and weak algorithms must be prohibited:
  1. It is recommended to disable “DSA SSH keys”, as they are considered insecure
  2. For “RSA SSH keys”, it is recommended to set the minimum key length to 3072 bits
  3. For “ECDSA SSH keys”, it is recommended to set the minimum key length to 256 bits
  4. ECDSA_SK SSH keys and ED25519_SK SSH keys can be left enabled if hardware FIDO2/U2F keys are planned to be used

User account restrictions

Partially implemented by default

Severity: Moderate

How to find: Navigate to the administrator panel by clicking the Admin button at the bottom of the menu on the right. In the Settings section, go to the General section and expand the “Account and limits” menu. In the menu, review the settings and change them as indicated below:

It is required to configure project parameters, maximum size limits, session durations, and user parameters. These are basic settings for organizing security and access management.

It is recommended to set limits on repository sizes, pushes, imports/exports. TTL for sessions and tokens should be configured.

• Default project limit - it is recommended to configure the maximum number of projects per user
• Maximum session duration - implemented by default - session duration in minutes. Changing this parameter requires restarting webservice, sidekiq pods. Default is 7 days.
• Session settings - implemented by default - determine whether the user session expiration is calculated from the session creation time (application login) or from the time of the user’s last action
• Remember me - enable or disable the automatic session renewal mechanism. If enabled, the user will never be logged out as long as they periodically access the interface within the time configured in the Maximum session duration setting
• Require expiration date - implemented by default - require setting an expiration date for the access token when creating a user token
• User OAuth applications — Allow users to register any applications to use GitLab as an OAuth provider. This permission allows regular users to register their OAuth2 clients in Deckhouse Code (i.e., use Deckhouse Code as an OAuth2 provider for internal/third-party applications). It is strongly recommended to disable this setting
• OAuth authorization — Allow the use of the Resource Owner Password Credentials (ROPC) mechanism. This setting allows users (or scripts) to obtain OAuth tokens using login/password without registering an OAuth client (i.e., without application identification). It is strongly recommended to disable this setting
• Allow new users to create top-level groups - This changes the default setting for new users who will be created manually or log in for the first time via SSO/LDAP. This does not change settings for already created users. For existing users, this setting is changed individually in each user’s profile in the administrative user management interface (Admin panel -> Overview -> Users -> select a specific user -> Edit -> “Can create top-level groups:” Yes/No)
• Make new user profiles private by default - recommended to enable
• Allow users with the Guest role to create groups and personal projects - recommended to disable

User sign-up restrictions

Partially implemented by default

Severity: Critical

How to find: Navigate to the administrator panel by clicking the Admin button at the bottom of the menu on the right. In the Settings section, go to the General section and expand the “Sign-up restrictions” menu. In the menu, review the settings and change them as indicated below:

It is required to configure the method for creating new accounts. It is recommended to disable user registration and the login page, and to require email confirmation and set a minimum length for user passwords. Some options may be disabled for modification through the administrator panel in the UI and, for greater security, moved to the specification of the Kubernetes custom resource CodeInstances.

• Sign-up enabled - implemented by default - disable the ability to create new users through the registration page (re-enabling is only possible through the CR specification)
• Require admin approval for new sign-ups - implemented by default - a user must be explicitly approved by an administrator before logging in. Only applies when registration is enabled; does not apply to SSO/LDAP users
• Email confirmation settings - the mandatory email confirmation mode for users should be selected. If registration is enabled, the hard mode must be used
• Minimum password length (number of characters) - implemented by default - applies only to internal accounts; not relevant when authenticating via SSO/LDAP. Default is 8 characters
• Allowed domains for sign-up - a whitelist of email domains with which new users can register. Only applies when registration is enabled; does not apply to SSO/LDAP users
• Denied domains for sign-up - a blacklist of email domains for new user registration. Only applies when registration is enabled; does not apply to SSO/LDAP users
• Email restrictions for sign-up - a method for restricting email addresses of new users using a regular expression. Only applies when registration is enabled; does not apply to SSO/LDAP users

User sign-in restrictions

Partially implemented by default

Severity: Critical

How to find: Navigate to the administrator panel by clicking the Admin button at the bottom of the menu on the right. In the Settings section, go to the General section and expand the “Sign-in restrictions” menu. In the menu, review the settings and change them as indicated below:

It is recommended to restrict the set of individuals who have access to Deckhouse Code, following the principle of least privilege. Some options may be disabled for modification through the administrator panel in the UI and, for greater security, moved to the specification of the Kubernetes custom resource CodeInstances.

• Two-factor authentication grace period - implemented by default - the maximum time during which users can postpone setting up two-factor authentication (in hours). It is recommended to set the value to 0 to require second factor setup at the next sign-in
• Email notification for unknown sign-ins - Enable email notification - implemented by default - notify users by email if the user signed in from a new device or IP address that has not been previously used to access Deckhouse Code
• Allow password authentication for the web interface - this setting can only be configured through the CR specification. It is recommended to disable on a configured instance if all users, including Deckhouse Code administrators, authenticate via SSO/LDAP
• Allow password authentication for Git over HTTP(S) - it is recommended to uncheck this option to use a personal access token instead. This option should be disabled for security purposes
• Require administrators to use two-factor authentication - recommended to enable
• Require all users to enable two-factor authentication - recommended to enable, even when SSO/LDAP authorization is enabled. Recommended to disable if the second factor is verified at the SSO provider level
• Enable admin mode - Require additional authentication to perform administrative tasks. Recommended to enable
• Require email confirmation for blocked accounts - If a user’s account is blocked, GitLab will ask to confirm email ownership: at the next sign-in attempt, the system will send a code/link to the primary email, and without this confirmation, sign-in is not possible. Recommended to enable

Import and export settings

Partially implemented by default

Severity: Moderate

How to find: Navigate to the administrator panel by clicking the Admin button at the bottom of the menu on the right. In the Settings section, go to the General section and expand the “Import and export settings” menu. In the menu, review the settings and change them as indicated below:

To protect the codebase, it is recommended to set restrictions on project and group export and import following the principles of “least privilege” and whitelists.

• Import sources - implemented by default - If needed, allow project imports from specific systems. The “Repository by URL” source allows importing any Git repository by URL. All sources are disabled by default
• Allow transfer of GitLab groups and projects by direct transfer - implemented by default - this action is prohibited by default
• Admin exports without audit - implemented by default - If disabled, export/download of project or group exports will not be written to security audit logs. Exports made by non-admins are still recorded in the audit
• Project export - Allow creation of a .tar.gz archive with project data (repositories, issues, MRs, comments, attachments, settings, and much more) to then import it to another Deckhouse Code/GitLab instance or to another group. Recommended to disable
• Maximum number of simultaneous import jobs for GitHub - it is recommended to set a reasonable limit on the number of simultaneous project imports to preserve system resources
• Maximum number of simultaneous import jobs for BitBucket Cloud - it is recommended to set a reasonable limit on the number of simultaneous project imports to preserve system resources
• Maximum number of simultaneous import jobs for BitBucket Server - it is recommended to set a reasonable limit on the number of simultaneous project imports to preserve system resources

Repository settings

This section allows restricting access and the nature of user interaction with repositories for all existing projects.

How to find: Navigate to the administrator panel by clicking the Admin button at the bottom of the menu on the right. In the Settings section, go to the Repository section. Expand the corresponding menus, review the settings, and change them as indicated below:

Default branch

Implemented by default

Severity: Moderate

• Default initial branch protection - protection is enabled; the branch will initially be a protected branch
• Allowed to push - only users with the Maintainer role and above can perform direct commits to the main branch. Where possible, a complete prohibition on direct commits to the main branch for all users is recommended, working only through branches and creating merge requests (Pull requests)
• Allowed to merge - by default, only users with the Maintainer role and above can merge branches into the main branch
• Allowed to force push - allow all users with push access to perform force push. Disabled by default
• Allow developers to push the initial commit - developers can push the initial commit to a repository, but not subsequent ones. Prohibited by default

Push rules

Severity: Moderate

It is recommended to configure push rules at the product installation level and prohibit their override at the group and project levels. This ensures a unified security policy for all users and projects and minimizes the risk of unauthorized source code changes. The following rules are recommended to configure:

• Regular expression for commit author’s email - prohibit commits from non-corporate email addresses
• Check committer name - the committer’s name must match the profile name in Code
• Check committer email - the committer’s email address must be confirmed in the Code profile
• Check registered user - the commit author must be a Code user
• Block secrets being pushed - files with names such as pem or id_rsa cannot be committed. See the documentation for the full list of prohibited names

CI/CD settings

How to find: Navigate to the administrator panel by clicking the Admin button at the top of the menu on the right. In the Settings section, go to the CI/CD section. Expand the corresponding menus, review the settings, and change them as indicated below:

Continuous integration and deployment

Severity: Moderate

• Authentication token expiration for instance runners - This setting controls the lifetime of authentication tokens for runners created at the instance level. Unlimited by default
• Authentication token expiration for group runners - This setting controls the lifetime of authentication tokens for runners created at the group level. Unlimited by default
• Authentication token expiration for project runners - This setting controls the lifetime of authentication tokens for runners created at the project level. Unlimited by default

It should be noted that when these options are enabled, the runner automatically rotates tokens as their expiration approaches; however, if the runner is offline, rotation will not occur, and such a runner will need to be re-registered.

Runners

Severity: Critical

• Fetch GitLab Runner release version data from GitLab.com - release version data for official runners is periodically requested from GitLab.com to determine whether runner updates are required. In air-gapped environments, it is strongly recommended to disable this setting.
• Allow runner registration tokens - This parameter enables or disables the functionality of creating runners using registration tokens. Runner registration tokens are “shared secrets” at the instance/group/project level, with which anyone who has the token could register a new runner. This mechanism is considered deprecated and insecure; runner authentication tokens must be used instead. Authentication tokens are unique to each runner, support rotation, and are a secure replacement for registration tokens. It is strongly recommended to disable this setting.

CI/CD job token permissions

Implemented by default

Severity: Critical

A critical section for preventing unauthorized access to one project’s data by another project.

• Enable and enforce job token allowlist for all projects - when executing a build job, runners can access other projects within Deckhouse Code. When this option is enabled, the project being accessed within the job must explicitly allow such access from the specific project. The option to allow access from all groups and projects will be hidden. It is recommended to leave this enabled.

Spam and bot protection

Severity: Low

How to find: Navigate to the administrator panel by clicking the Admin button at the bottom of the menu on the right. In the Settings section, go to the “Reporting” section. Expand the corresponding menus, review the settings, and change them as indicated below:

This section allows configuring reCAPTCHA, limiting the number of IP addresses per user, and other similar mechanisms to protect against bots and spam. Configuration is only necessary for installations that are accessible via the internet.

Sending metrics to third-party systems

Implemented by default

Severity: Critical

How to find: Navigate to the administrator panel by clicking the Admin button at the bottom of the menu on the right. In the Settings section, go to the “Metrics and profiling” section. Expand the corresponding menus, review the settings, and change them as indicated below:

It is required to configure the parameters for collecting and sending metrics and other product usage statistics to external systems. Such behavior is undesirable and is disabled by default (except for collecting and sending technical metrics to the Deckhouse monitoring system located in the same cluster).

• Usage statistics - product update checks and sending product usage statistics are disabled at the code level. Update checks are implemented by Deckhouse Kubernetes Platform
• Event tracking - event tracking and sending are disabled at the code level and cannot be enabled

Network restrictions

Implemented by default

Severity: Moderate

How to find: Navigate to the administrator panel by clicking the Admin button at the bottom of the menu on the right. In the Settings section, go to the “Network” section. Expand the corresponding menus, review the settings, and change them as indicated below:

Rate limiting is an important mechanism for protecting the system from DDOS attacks and resource overload.

• User and IP address rate limits - this section allows setting limits on the number of various types of requests to Deckhouse Code, depending on the request type and the user’s IP address
• Package registry rate limits - set rate limits for package registry API requests that override the general user and IP address limits
• Files API rate limits - set specific limits for Files API requests that override the general user and IP address rate limits
• Search rate limits - Set rate limits for search requests via web or API
• Git HTTP rate limits - it is recommended to configure specific limits for Git HTTP requests
• Git SSH rate limits - it is recommended to configure specific limits for Git SSH requests
• Git LFS rate limits - it is recommended to configure specific limits for Git LFS requests
• Outbound requests - Restrict requests to third-party resources from hooks and integrations
• Granular rate limits for various API resources - it is recommended to configure rate limits for various API resources, depending on the API usage profile
• Import and export rate limits - Set rate limits for project and group import and export per user
• Pipeline creation rate limits - Limit the number of pipeline creation requests per minute. This limit includes pipelines created via the user interface, API, and background processing

Daily operation settings

General recommendations for access management, groups, reviews, and maintaining security in daily operations.

Group-level settings

How to find: Navigate to the specific group, then in the left sidebar menu go to the “Settings” tab. The documentation structure reflects the names of menu sections and their subsections.

General

Severity: Critical

It is recommended to control the group visibility level and follow the principle of least privilege, setting it to private wherever possible. The stricter the access level, the easier it is to implement granular control and the lower the risk of information leakage.

Group access rights and capabilities

Partially implemented by default

Severity: Critical

• Members cannot invite groups outside group name and its subgroups - implemented by default available only in the top-level group. Applies to all subgroups. Groups (outside the specific group) that have already been granted access still retain access unless they are manually removed
• Projects in group name cannot be transferred to other groups - applies to all subgroups unless overridden by a subgroup owner. Disables the ability to grant access to other users or groups outside group name
• Wiki access level - it should be controlled who can view and edit the wiki in the group. To prevent compromising internal information, it is advisable to set the private level unless there is a need to do otherwise
• Enabled Git access protocols - granular configuration of protocols (SSH / HTTP(S)) through which Git access is available in the specific group
• Minimum role required to create projects - the minimum user role required to create projects in the specific group. Recommended: “Owner” or “Maintainer”
• Roles allowed to create subgroups - the minimum user role required to create subgroups in the group. Recommended: “Owner” or “Maintainer”
• Users can create group access tokens and project access tokens in this group - this setting allows/prohibits group members from creating group and project tokens for external integrations. Group tokens can only be created by a user with the “Owner” role in this group. Users can create tokens at the project level, but their maximum permissions will be limited by the user’s role in the project
• All users in this group must enable two-factor authentication - the mandatory use of two-factor authentication for all users in the group should be controlled. It is advisable to enable this option and set the 2FA enforcement delay as short as possible, unless there is a need to do otherwise. Also, subgroups should not be allowed to set their own two-factor authentication rules
• Pages access control -> Restrict access to project members only for all projects in the group - When this setting is enabled, access to pages content will be restricted to members of the specific project only. When disabled, access can be configured individually in each project

Repository

Deploy tokens

Severity: Moderate

It is recommended to regularly audit deploy tokens and remove unnecessary ones, as well as ensure that current tokens maintain granularity, are clearly described, and have an expiration date.

Default branch

Severity: Moderate

Security settings for the main branch for all projects in the group. Allows overriding the settings of the entire Deckhouse Code installation for your specific group. See this section for detailed recommendations.

Push rules

Severity: Moderate

It is recommended to configure push rules at the group level. If overriding global rules is allowed, override them for more granular access control to projects and artifacts in the group. The list of recommended rules to configure is provided here.

Also, it is recommended to prohibit group projects from overriding the rules already configured at this level, unless there is a need to do otherwise.

CI/CD

Section for configuring and overriding CI/CD parameters for all projects in the group.

Pipelines

Severity: Moderate

It is recommended to enable the option Enable JWT format for CI/CD job tokens.

Variables

Severity: Moderate

• Mask CI/CD variables that contain sensitive information to avoid their unintentional exposure in pipeline logs or audit events.

Project-level settings

How to find: Navigate to the specific project, then in the left sidebar menu go to the “Settings” tab. The documentation structure reflects the names of menu sections and their subsections.

General

Access level, additional project features, permissions

Partially implemented by default

Severity: Moderate

• It is recommended to keep the project visibility level as low as possible (private where possible); the require authentication to view media files option should be enabled to prohibit viewing media files without authorization
• Reasonable access restrictions to work artifacts (LFS, merge requests, code branches, package and container registries, issues, environments, releases, etc.) should be configured in accordance with the organization’s requirements
• It is recommended to prohibit any user from downloading from the package registry - implemented by default

Repository

Below are recommendations for configuring the basic security parameters of the project repository.

Push rules

Severity: Moderate

It is recommended to configure push rules at the project level. If overriding group-level rules is allowed, override them for more granular access control to projects and artifacts in the group. The list of recommended rules to configure is provided here.

It is recommended to pay attention to applying other push rules if they help improve security in the context of the specific project.

Protected branches

Severity: Low

To ensure the security of the codebase in the main and stable branches of the repository, use the protected branches mechanism, which allows overriding the roles that have the right to merge MRs or make direct commits. By default, only users with the “Maintainer” and “Owner” roles can make direct commits to a protected branch.

Protected tags

Severity: Low

If tags are used in the development process (e.g., for releases), a pattern can be specified to define which tags can be created by a particular role in the project. For example, product version tags of the form _v can only be created by a “Maintainer”.

Deploy tokens

Severity: Moderate

It is recommended to regularly audit deploy tokens and remove unnecessary ones, as well as ensure that current tokens maintain granularity, are clearly described, and have an expiration date.

Deploy keys

Severity: Moderate

Deploy keys are an alternative mechanism to deploy tokens for issuing tokens not tied to a user account, and all the same recommendations apply to them.

Merge requests

Severity: Moderate

This section regulates the rules for working with merge requests (MR) in the project repository.

In addition to enabling the settings from the recommendations below, attention should also be paid to:

• Enabling the code ownership mechanism (CODEOWNERS) to ensure granular review of changes in the project’s codebase
• Enabling extended merge request approval policies (Merge request approval rules) to ensure granular control over the process and participants of reviewing changes in the project’s codebase. Within these rules, the following should also be considered:
  • Prohibiting the MR author from approving their own MR
  • Configuring the minimum number of reviewers (approvers)
  • Prohibiting changes to rules at the project level by including a file with review policy descriptions from another project (the include mechanism), to which developers of this project do not have access

Merge checks

Severity: Moderate

To enhance the security of the codebase, it is recommended to perform a number of manual and automated checks before merging code into the main/stable branches:

• Enable the pipelines must succeed option, and embed the necessary automated security checks into the pipelines themselves, such as: secret scanning, static and dynamic analysis of the codebase, vulnerability scanners for language dependencies, as well as for target and base images
• Enable the All discussions must be resolved option to prevent unreviewed code or code requiring changes after review from being merged into the main/stable branches

CI/CD

Section for configuring and overriding CI/CD parameters for a specific project.

Pipelines

Severity: Moderate

In this section, it is recommended to ensure that the Use separate caches for protected branches option is enabled.

It is also recommended to:

• Control access to .gitlab-ci.yml through the code ownership mechanism (CODEOWNERS) to prevent accidental or intentional modification of pipelines or their components
• Use the manual approval mechanism when writing a pipeline to restrict the execution of critical pipelines or their components

Variables

Severity: Moderate

All recommendations from the group-level settings section apply to this section, and it is also recommended to enable the Show pipeline variables option for explicit display of all pipeline variables in logs to increase process transparency and facilitate troubleshooting in case of issues or suspected security compromise.

In addition, it is recommended to:

• Secrets should not be stored in plaintext; it is preferable to use CI/CD variables or configure integration with Deckhouse Stronghold or another compatible Vault storage. An example of integration with a Vault-compatible storage is available at this link
• Variables should be marked as protected and masked wherever possible to avoid disclosure of their values or accidental overriding in the pipeline

Pipeline trigger tokens

Pipeline trigger tokens can run pipelines with the permissions of the user who issued them, which is a potential attack vector. All recommendations from the group-level settings section apply to such tokens.

CI/CD job token permissions

It is recommended to control the list of groups and projects that are allowed to access the current project’s data from their pipelines using a whitelist approach.

Packages and registries

Severity: Moderate

Protect critical packages published in the package registry using the protected packages mechanism, configuring access to them only for users above a certain role.

The same recommendation applies to the container registry.