Перейти к содержанию

Конфигурация

Настройки Системы находится в едином конфигурационном файле /etc/gitlab/gitlab.rb.

Чтобы получить доступ к конфигурационному файлу Системы, можно запустить сессию командной оболочки в работающем контейнере. Таким образом появится возможность просматривать все директории и использовать предпочитаемый текстовый редактор:

docker exec -it appseccode /bin/bash

Можно просто редактировать файл /etc/gitlab/gitlab.rb:

docker exec -it appseccode editor /etc/gitlab/gitlab.rb

Открыв /etc/gitlab/gitlab.rb, убедитесь, что external_url ссылается на валидный URL.

Чтобы получать сообщения от Системы по электронной почте, необходимо сконфигурировать SMTP-сервер, который не входит в комплект поставки Системы.

Настройка доступа по HTTPS также осуществляется отдельно.

После внесения всех необходимых изменений следует перезапустить контейнер, чтобы произошло переконфигурирование Системы.

docker restart appseccode

Запуск Системы на публичном IP-адресе

Можно создать Docker-контейнер для использования внешнего IP-адреса и перенаправлять весь трафик на контейнер Системы, изменив флаг --publish.

Например, чтобы Система работала на IP 198.51.100.1:

docker run --detach \
    --hostname yoursite.ru \
    --publish 198.51.100.1:443:443 \
    --publish 198.51.100.1:80:80 \
    --publish 198.51.100.1:22:22 \
    --name appseccode \
    --restart always \
    --volume $GITLAB_HOME/config:/etc/gitlab \
    --volume $GITLAB_HOME/logs:/var/log/gitlab \
    --volume $GITLAB_HOME/data:/var/opt/gitlab \
    --shm-size 256m \
    appseccode/appseccode:latest

Открытие Системы на различных портах

Если необходимо использовать другие порты вместо 80 (HTTP) или 443 (HTTPS), следует добавить отдельную директиву --publish к команде docker run.

Например, чтобы веб-интерфейс работал на порту 8929, а SSH-сервис на порту 2289:

  1. Используйте следующую команду для запуска:

    docker run --detach \
    --hostname yoursite.ru \
    --publish 8929:8929 --publish 2289:22 \
    --name appseccode \
    --restart always \
    --volume $GITLAB_HOME/config:/etc/gitlab \
    --volume $GITLAB_HOME/logs:/var/log/gitlab \
    --volume $GITLAB_HOME/data:/var/opt/gitlab \
    --shm-size 256m \
    appseccode/appseccode:latest

  2. Перейдите в работающий контейнер:

    docker exec -it appseccode /bin/bash

  3. Откройте /etc/gitlab/gitlab.rb и задайте external_url:

    # For HTTP
external_url "http://yoursite.ru:8929"

or

# For HTTPS (notice the https)
external_url "https://yoursite.ru:8929"

    Порт, указанный в данном URL, должен соответствовать порту, опубликованном на хосте Docker’ом. Кроме этого, если NGINX «слушает» порт, неявно указанный в nginx['listen_port'], он будет извлечен из external_url.

  4. Укажите gitlab_shell_ssh_port:

    gitlab_rails['gitlab_shell_ssh_port'] = 2289

  5. В завершение выполните реконфигурацию Системы:

    gitlab-ctl reconfigure

    В соответствии с приведенным выше примером можно работать с Системой через веб-браузер по адресу <hostIP>:8929 или, через SSH на 2289 порту.

Параметры конфигурации для пакетов Linux

Чтобы настроить AppSec.Code, установите соответствующие параметры в файле /etc/gitlab/gitlab.rb. Файл gitlab.rb описывается в запускаемом docker compose файле.

gitlab.rb.template содержит полный список доступных опций. Новые установки включают все опции шаблона по умолчанию в /etc/gitlab/gitlab.rb.

Примечание

Примеры, предоставляемые при редактировании /etc/gitlab/gitlab.rb, могут не всегда отражать настройки по умолчанию для экземпляра.

Настройка внешнего URL для AppSec.Code

Чтобы ваши пользователи могли видеть правильные ссылки на клонирование репозиториев, необходимо предоставить AppSec.Code URL, который используют ваши пользователи для доступа к репозиторию. Вы можете использовать IP-адрес вашего сервера, но предпочтительнее использовать полностью определенное доменное имя (FQDN).

Чтобы изменить внешний URL:

  1. Опционально. Перед изменением внешнего URL определите, определяли ли вы ранее пользовательский URL домашней страницы или путь после выхода из системы. Оба эти параметра могут привести к непреднамеренному перенаправлению после настройки нового внешнего URL. Если были определены какие-либо URL-адреса, удалите их полностью.

  2. Отредактируйте /etc/gitlab/gitlab.rb и измените external_url на предпочитаемый вами URL:

    external_url "http://asc.example.com"

    Альтернативно, можно использовать IP-адрес вашего сервера:

    external_url "http://10.0.0.1"

    В приведенных выше примерах используется простой HTTP. Если вы хотите использовать HTTPS, ознакомьтесь с инструкциями по настройке SSL.

  3. Переконфигурируйте AppSec.Code:

    gitlab-ctl reconfigure

  4. Опционально. Если вы использовали AppSec.Code некоторое время, после изменения внешнего URL также рекомендуется очистить кеш Markdown.

Настройка относительного URL для AppSec.Code

Примечание

Для самостоятельно собранных (исходных) установок существует отдельный документ.

Хотя мы рекомендовали устанавливать AppSec.Code в собственном (под)домене, иногда это невозможно. В таком случае, AppSec.Code может быть установлен под относительным URL, например, https://example.com/asc.

Изменение URL приводит к изменению всех удалённых URL, поэтому вам нужно вручную отредактировать их в любом локальном репозитории, указывающем на ваш экземпляр Системы.

Чтобы включить относительный URL в Системе:

  1. Задайте external_url в /etc/gitlab/gitlab.rb:

    external_url "https://example.com/asc"

    В данном примере относительный URL, под которым работает Система, — /gitlab. Измените его по своему усмотрению.

  2. Переконфигурируйте Систему:

    gitlab-ctl reconfigure

Чтение сертификатов из файла

Сертификаты могут храниться в отдельных файлах и загружаться в память при выполнении команды gitlab-ctl reconfigure. Файлы, содержащие сертификаты, должны быть обычными текстовыми файлами.

В этом примере сертификат сервера PostgreSQL читается непосредственно из файла, вместо того чтобы копировать и вставлять его непосредственно в /etc/gitlab/gitlab.rb.

postgresql['internal_certificate'] = File.read('/path/to/server.crt')

Этот код считывает содержимое файла /path/to/server.crt и присваивает его значению internal_certificate в разделе конфигурации PostgreSQL.

Хранение данных Системы в альтернативном каталоге

По умолчанию, установки пакетов Linux хранят данные репозитория Системы в каталоге /var/opt/gitlab/git-data/repositories, а служба Gitaly слушает сокет unix:/var/opt/gitlab/gitaly/gitaly.socket.

Чтобы изменить расположение каталога:

  1. Откройте /etc/gitlab/gitlab.rb для редактирования:

    gitaly['configuration'] = {
    storage: [
        {
            name: 'default',
            path: '/mnt/nas/git-data/repositories',
        },
    ],
}

    Вы также можете добавить более одного каталога для данных Системы:

    gitaly['configuration'] = {
    storage: [
        {
            name: 'default',
            path: '/var/opt/gitlab/git-data/repositories',
        },
        {
            name: 'alternative',
            path: '/mnt/nas/git-data/repositories',
        },
    ],
}

    Целевые каталоги и любые их подкаталоги не должны быть символическими ссылками.

  2. Переконфигурируйте AppSec.Code:

    gitlab-ctl reconfigure

  3. Опционально. Если у вас уже есть существующие репозитории Системы в /var/opt/gitlab/git-data, вы можете переместить их в новое местоположение:

    • Предотвратите возможность записи пользователей в репозиторий во время перемещения:

      sudo gitlab-ctl stop

    • Синхронизируйте репозитории с новым местоположением. Обратите внимание, что за repositories нет слэша, но он есть за git-data:

      rsync -av --delete /var/opt/gitlab/git-data/repositories /mnt/nas/git-data/

    • Переконфигурируйте, чтобы начать необходимые процессы и исправить любые неправильные права доступа:

      sudo gitlab-ctl reconfigure

    • Проверьте структуру каталогов в /mnt/nas/git-data/. Ожидаемый вывод должен быть таким: repositories:

      ls /mnt/nas/git-data/

    • Запустите AppSec.Code и проверьте, можете ли вы просматривать репозитории через веб-интерфейс:

      gitlab-ctl start

Если вы запускаете Gitaly на отдельном сервере, ознакомьтесь с документацией по настройке Gitaly.

Если вы не планируете перемещать все репозитории, но хотите переместить определенные проекты между существующими хранилищами репозиториев, используйте конечную точку API для редактирования проекта и укажите атрибут repository_storage.

Настройка запрета неудачной аутентификации

Вы можете настроить запрет на неудачную аутентификацию для Системы и контейнеризированного реестра. Когда клиент заблокирован, возвращается ошибка 403.

Ниже приведены параметры, которые можно настроить:

Параметр Описание
enabled По умолчанию false. Установите значение true, чтобы включить запрет аутентификации для Системы и реестра.
ip_whitelist Список IP-адресов, которые не будут блокироваться. Адреса должны быть отформатированы как строки в массиве Ruby. Можно указывать как отдельные IP-адреса, так и диапазоны в нотации CIDR, например: ["127.0.0.1", "127.0.0.2", "127.0.0.3", "192.168.0.1/24"].
maxretry Максимальное количество попыток аутентификации с одного IP-адреса за указанное время.
findtime Время в секундах, в течение которого подсчитываются неудачные попытки аутентификации перед тем, как IP-адрес будет добавлен в черный список.
bantime Общее время в секундах, на которое IP-адрес будет заблокирован после превышения допустимого количества неудачных попыток аутентификации.

Для настройки запрета аутентификации Системы и реестра контейнеров:

  1. Откройте /etc/gitlab/gitlab.rb для редактирования:

    gitlab_rails['rack_attack_git_basic_auth'] = {
    'enabled' => true,
    'ip_whitelist' => ["127.0.0.1"],
    'maxretry' => 10, # Ограничьте количество попыток аутентификации по HTTP для Git с одного IP
    'findtime' => 60, # Сбросьте счетчик попыток аутентификации для IP каждые 60 секунд
    'bantime' => 3600  # Блокируйте IP на один час (3600 секунд) после слишком большого числа попыток аутентификации
}

  2. Переконфигурируйте Систему:

    gitlab-ctl reconfigure

Отключение автоматической очистки кеша во время установки

Если у вас крупная инсталляция Системы, возможно, вы не захотите выполнять задачу rake cache:clear, поскольку её выполнение может занять длительное время. По умолчанию задача очистки кеша выполняется автоматически во время перенастройки.

Чтобы отключить автоматическую очистку кеша во время установки:

  1. Откройте /etc/gitlab/gitlab.rb для редактирования:

    # Это расширенная функция, используемая в крупных развертываниях Системы, где загрузка 
# всей среды Rails занимает много времени.
gitlab_rails['rake_cache_clear'] = false

  2. Переконфигурируйте Систему:

    gitlab-ctl reconfigure

Отчеты об ошибках и журналирование с использованием Sentry

Примечание

Начиная с AppSec.Code 2025.1.1, будут поддерживаться только версии Sentry 21.5.0 и выше. Если вы используете более раннюю версию Sentry, которую размещаете самостоятельно, вам потребуется обновить Sentry, чтобы продолжать собирать ошибки из сред AppSec.Code.

Sentry — это инструмент с открытым исходным кодом для создания отчетов об ошибках и ведения журнала, который можно использовать как SaaS (например, через сайт https://sentry.io) или размещать локально.

Настройка Sentry:

  1. Создайте проект в Sentry.
  2. Найдите Data Source Name (DSN) вашего проекта.

  3. Откройте /etc/gitlab/gitlab.rb для редактирования:

    gitlab_rails['sentry_enabled'] = true
gitlab_rails['sentry_dsn'] = 'https://<public_key>@<host>/<project_id>' # значение, используемое SDK Rails
gitlab_rails['sentry_clientside_dsn'] = 'https://<public_key>@<host>/<project_id>' # значение, используемое JavaScript SDK браузера
gitlab_rails['sentry_environment'] = 'production'

    Среду Sentry можно использовать для отслеживания ошибок и проблем в разных развернутых средах Системы, таких как лабораторная, разработка, промежуточная и производственная среды.

  4. Дополнительно: если вы хотите задать пользовательские теги Sentry для каждого события, отправляемого с конкретного сервера, можно установить переменную окружения GITLAB_SENTRY_EXTRA_TAGS. Эта переменная представляет собой JSON-кодированный хеш, представляющий любые теги, которые должны передаваться в Sentry для всех исключений с этого сервера. Например, установив:

    gitlab_rails['env'] = {
    'GITLAB_SENTRY_EXTRA_TAGS' => '{"stage": "main"}'
}

    Будет добавлен тег stage со значением main.

  5. Переконфигурируйте Систему:

    gitlab-ctl reconfigure

Установка URL-адреса сети доставки контента (CDN)

Используйте сеть доставки контента (CDN) или хост активов для обслуживания статических активов с помощью gitlab_rails['cdn_host']. Это настроит хост активов Rails.

Чтобы настроить CDN/хост активов:

  1. Откройте /etc/gitlab/gitlab.rb для редактирования:

    gitlab_rails['cdn_host'] = 'https://mycdnsubdomain.fictional-cdn.com'

  2. Переконфигурируйте Систему:

    gitlab-ctl reconfigure

Установка политики безопасности контента (CSP)

Настройка политики безопасности контента (CSP) может помочь предотвратить атаки межсайтового скриптинга (XSS). Подробнее смотрите в документации Mozilla по CSP.

Неправильная настройка правил CSP может нарушить работу AppSec.Code. Прежде чем развернуть политику, вы можете протестировать её, изменив report_only на true.

Чтобы добавить CSP:

  1. Откройте /etc/gitlab/gitlab.rb для редактирования:

    gitlab_rails['content_security_policy'] = {
    enabled: true,
    report_only: false
}

    AppSec.Code автоматически предоставляет безопасные значения по умолчанию для CSP. Явная установка <default_value> для директивы эквивалентна отсутствию установки значения и будет использовать значения по умолчанию.

    Чтобы добавить пользовательский CSP:

    gitlab_rails['content_security_policy'] = {
    enabled: true,
    report_only: false,
    directives: {
        default_src: "'none'",
        script_src: https://example.com
    }
}

    Директивы, которые явно не настроены, используют безопасные значения по умолчанию.

    Чтобы отменить директиву CSP, установите значение false.

  2. Переконфигурируйте AppSec.Code:

    gitlab-ctl reconfigure

Установка начального пароля root при установке

Начальный пароль для администратора root может быть установлен во время установки:

  1. Откройте /etc/gitlab/gitlab.rb для редактирования:

    gitlab_rails['initial_root_password'] = 'password'

  2. Переконфигурируйте AppSec.Code:

    gitlab-ctl reconfigure

Установка разрешенных хостов для предотвращения атак на заголовки хостов

Чтобы запретить AppSec.Code принимать заголовок хоста, отличный от предполагаемого:

  1. Откройте /etc/gitlab/gitlab.rb для редактирования:

    gitlab_rails['allowed_hosts'] = ['gitlab.example.com']

  2. Переконфигурируйте Систему:

    gitlab-ctl reconfigure

Хотя в AppSec.Code нет известных проблем безопасности, связанных с незаданными allowed_hosts, это рекомендуется для дополнительной защиты от потенциальных атак с использованием заголовков HTTP Host.

Если вы используете внешний прокси-сервер, такой как Apache, вам может потребоваться добавить адрес или имя localhost (localhost или 127.0.0.1). Добавьте фильтры к внешнему прокси-серверу, чтобы смягчить возможные атаки на заголовки HTTP Host, проходящие через прокси-сервер на workhorse.

gitlab_rails['allowed_hosts'] = ['asc.example.com', '127.0.0.1', 'localhost']

Конфигурация сеансовых cookie-файлов

Чтобы изменить префикс сгенерированных значений cookie-файлов веб-сеанса:

  1. Откройте /etc/gitlab/gitlab.rb для редактирования:

    gitlab_rails['session_store_session_cookie_token_prefix'] = 'custom_prefix_'

  2. Переконфигурируйте AppSec.Code:

    gitlab-ctl reconfigure

По умолчанию используется пустая строка "".

Предоставление чувствительной конфигурации компонентам без хранения в виде простого текста

Некоторые компоненты предоставляют опцию extra_config_command в gitlab.rb. Это позволяет внешнему скрипту динамически предоставлять секреты, а не считывать их из хранилища простого текста.

Доступны следующие параметры:

Параметры в gitlab.rb Ответственность
redis['extra_config_command'] Предоставляет дополнительную конфигурацию для файла конфигурации сервера Redis.
gitlab_rails['redis_extra_config_command'] Предоставляет дополнительную конфигурацию для файлов конфигурации Redis, используемых приложением GitLab Rails (resque.yml, redis.yml, redis.<redis_instance>.yml).
gitlab_rails['db_extra_config_command'] Предоставляет дополнительную конфигурацию для файла конфигурации базы данных, используемой приложением GitLab Rails (database.yml).
gitlab_kas['extra_config_command'] Предоставляет дополнительную конфигурацию для сервера агента GitLab для Kubernetes (KAS).
gitlab_workhorse['extra_config_command'] Предоставляет дополнительную конфигурацию для GitLab Workhorse.
gitlab_exporter['extra_config_command'] Предоставляет дополнительную конфигурацию для GitLab Exporter.

Значение, присваиваемое любому из этих параметров, должно быть абсолютным путём к исполняемому скрипту, который записывает чувствительную конфигурацию в нужном формате в стандартный вывод (STDOUT). Компоненты:

  1. Выполняют предоставленный скрипт.
  2. Заменяют значения, установленные пользователем и файлами конфигурации по умолчанию, значениями, полученными из скрипта.

Предоставление пароля Redis серверу и клиентским компонентам

Как пример, вы можете использовать скрипт и фрагмент gitlab.rb ниже, чтобы указать пароль для сервера Redis и компонентов, которым требуется подключиться к Redis.

Примечание

При указании пароля для сервера Redis этот метод лишь избавляет вас от необходимости иметь пароль в виде простого текста в файле gitlab.rb. Пароль окажется в виде простого текста в файле конфигурации сервера Redis, находящемся по адресу /var/opt/gitlab/redis/redis.conf.

  1. Сохраните скрипт ниже как /opt/generate-redis-conf:

    #!/opt/gitlab/embedded/bin/ruby

require 'json'
require 'yaml'

class RedisConfig
    REDIS_PASSWORD = `echo "toomanysecrets"`.strip # Измените команду внутри обратных кавычек, чтобы получить пароль Redis

    class << self
        def server
            puts "requirepass '#{REDIS_PASSWORD}'"
            puts "masterauth '#{REDIS_PASSWORD}'"
        end

        def rails
            puts YAML.dump({
                'password' => REDIS_PASSWORD
            })
        end

        def kas
            puts YAML.dump({
                'redis' => {
                    'password' => REDIS_PASSWORD
                }
            })
        end

        def workhorse
            puts JSON.dump({
                redis: {
                    password: REDIS_PASSWORD
                }
            })
        end

        def gitlab_exporter
            puts YAML.dump({
                'probes' => {
                    'sidekiq' => {
                        'opts' => {
                            'redis_password' => REDIS_PASSWORD
                        }
                    }
                }
            })
        end
    end
end

def print_error_and_exit
    $stdout.puts "Usage: generate-redis-conf <COMPONENT>"
    $stderr.puts "Supported components are: server, rails, kas, workhorse, gitlab_exporter"

    exit 1
end

print_error_and_exit if ARGV.length != 1

component = ARGV.shift
begin
    RedisConfig.send(component.to_sym)
rescue NoMethodError
    print_error_and_exit
end

  2. Убедитесь, что созданный скрипт доступен для исполнения:

    chmod +x /opt/generate-redis-conf

  3. Добавьте следующий фрагмент в /etc/gitlab/gitlab.rb:

    redis['extra_config_command'] = '/opt/generate-redis-conf server'

gitlab_rails['redis_extra_config_command'] = '/opt/generate-redis-conf rails'
gitlab_workhorse['extra_config_command'] = '/opt/generate-redis-conf workhorse'
gitlab_kas['extra_config_command'] = '/opt/generate-redis-conf kas'
gitlab_exporter['extra_config_command'] = '/opt/generate-redis-conf gitlab_exporter'

  4. Запустите:

    gitlab-ctl reconfigure

Предоставление пароля пользователя PostgreSQL для GitLab Rails

Укажите пароль пользователя PostgreSQL для GitLab Rails.

Как пример, вы можете использовать скрипт и конфигурацию, представленные ниже, чтобы предоставить пароль, который компонент GitLab Rails должен использовать для подключения к серверу PostgreSQL.

  1. Сохраните скрипт ниже как /opt/generate-db-config:

    #!/opt/gitlab/embedded/bin/ruby

require 'yaml'

db_password = `echo "toomanysecrets"`.strip # Измените команду внутри обратных кавычек, чтобы получить пароль базы данных

puts YAML.dump({
    'main' => {
        'password' => db_password
    },
    'ci' => {
        'password' => db_password
    }
})

  2. Убедитесь, что созданный скрипт доступен для исполнения:

    chmod +x /opt/generate-db-config

  3. Добавьте следующий фрагмент в /etc/gitlab/gitlab.rb:

    gitlab_rails['db_extra_config_command'] = '/opt/generate-db-config'

  4. Запустите:

    gitlab-ctl reconfigure