Блокируем заливку приватных ключей, архивов, больших файлов и не только в Gitlab CE

    Git hooks – инструмент, помогающий держать в порядке ваш репозиторий. Можно настроить автоматические правила оформления ваших коммитов.


    Все вы наверное знаете про pre-commit — проверку вашего кода перед коммитом. Но ведь не все можно проверить перед коммитом. Некоторые ограничения хочется использоваться глобально на всем Gitlab.


    Кто запутался в pre-commit и pre-receive хуках, в этом посте описываются различия между ними в абзаце "What are git hooks?".


    Если у вас Gitlab Enterprise Edition, вы можете настроить хуки, которые описаны в посте через WEB интерфейс.


    Но что делать, если у вас Gitlab Community (Core) Edition?


    В этой статье будут описаны 5 pre-receive хуков, которые выполняются на сервере Gitlab Community (Core) Edition:


    • block_confidentials.sh — Блокирование отправки приватных ключей и AWS токенов
    • block_file_extensions.sh — Блокирование отправки архивов (Regex настраивается)
    • check-large-files.sh — Блокирование отправки больших файлов (Размер настраивается)
    • reject-not-allowlist-email.sh — Блокирование коммитов с email не из allow списка (Список email доменов настраивается)
    • require-issue.sh — Блокирование коммитов без issue в названии (Список issue настраивается)

    В основном хуки взяты из репозитория platform-samples в директории pre-receive-hooks (относится к GitHub Enterprise).


    Весь исходный код серверных хуков вы можете посмотреть на Github.


    Установка на Gitlab


    • Необходимо создать директорию /opt/gitlab/embedded/service/gitlab-shell/hooks/pre-receive.d/
    • Скопировать в эту директорию хуки
    • Не забыть выставить права запуска для хуков (chmod +x файл-хука)

    Блокирование отправки приватных ключей и AWS токенов


    В файле block_confidentials.sh настраиваем список regex_list, который описывает конфиденциальную информацию.


    # Define list of REGEX to be searched and blocked
    regex_list=(
      # block any private key file
      '(\-){5}BEGIN\s?(RSA|OPENSSH|DSA|EC|PGP)?\s?PRIVATE KEY\s?(BLOCK)?(\-){5}.*'
      # block AWS API Keys
      'AKIA[0-9A-Z]{16}'
      # block AWS Secret Access Key (TODO: adjust to not find validd Git SHA1s; false positives)
      # '([^A-Za-z0-9/+=])?([A-Za-z0-9/+=]{40})([^A-Za-z0-9/+=])?'
      # block confidential content
      'CONFIDENTIAL'
    )

    Добавляем в репозиторий приватный ключ, делаем коммит и при git push получаем ошибку.



    Блокирование отправки архивов


    В файле block_file_extensions.sh настраиваем case *.zip|*.gz|*.tgz, в котором указываются расширения файлов, которые будут блокироваться.


    Добавляем в репозиторий zip архив, делаем коммит и при git push получаем ошибку.



    Блокирование отправки больших файлов


    В файле check-large-files.sh настраиваем параметр maxsize, который указывает размер файла в мегабайтах, выше которого отправка будет блокироваться.


    Добавляем в репозиторий файл больше 1 мегабайта, делаем коммит и при git push получаем ошибку.



    Блокирование коммитов с email не из allow списка


    В файле reject-not-allowlist-email.sh настраиваем список email-доменов, для которых разрешены коммиты.


    declare -a DOMAIN_ARRAY=("group1.com" "group2.com")

    Меняем почту в git на ту, которой нет в разрешенном списке.


    git config user.email user1@group3.com

    Добавляем в репозиторий любой файл, делаем коммит и при git push получаем ошибку.



    Блокирование коммитов без issue в названии


    Этот серверный хук был взят из блога Majilesh.


    В файле require-issue.sh настраиваем список commit_format, для которых разрешены коммиты.


    commit_format="(JIRA|PROJECTKEY|MULE|ECOM|SAP|XLR-[1-9]+Merge)"

    Добавляем в репозиторий любой файл, делаем коммит, в названии которого нет слов из commit_format и при git push получаем ошибку.



    Надеюсь что мой пост сподвигнет сообщество развивать направление серверных хуков.


    Telegram-чат по Gitlab

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Какая редакция Gitlab у вас используется?

    • 75,0%Gitlab Core Edition21
    • 14,3%Gitlab Starter Edition4
    • 10,7%Gitlab Premium Edition3
    • 0,0%Gitlab Ultimate Edition0

    Будете ли вы покупать Gitlab или сделаете серверные хуки сами, если у вас сейчас бесплатная версия Gitlab?

    • 20,8%Купим Gitlab5
    • 79,2%Cделаю серверные хуки сам19

    Похожие публикации

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 8

      0
      А что такое «приватные ключи архивов больших файлов»?
      +1

      Вопрос менеджмента хуков на серверной стороне не рассмотрели. Объясню. Дело в том, что в текущей архитектуре хранение кода оторвано от веб морды гитлаба. И за хранение Гита отвечает, внезапно, демон gitaly. Соответственно, это чисто внутренняя штука гитлаба, которая не терпит изменений напрямую из ФС. Тем более, если у вас HA инсталляция, которую в принципе можно собрать и бесплатно. Без премиума. Это первый момент. Т.е. хотелось бы обоснования "почему" метод описанный в статье будет работать.
      Второй момент. Окей. Мы руками залезли в ФС, подтюнили гит хуки. Где гарантия, что в какой-то момент времени они не пропадут (например, с обновлением гитлаба) или не перестанут срабатывать?
      В третьих, выглядит так, что действительно проще гитлаб купить. Это всё-таки инструмент, который позволяет зарабатывать деньги, а, следовательно, стоит вложиться в него. На каком там уровне гит хуки появляются? 4 доллара за пользователя в месяц? А заодно и получаем кучу другого полезного функционала и спим спокойно.

        +1
        Вопрос менеджмента хуков на серверной стороне не рассмотрели. Объясню. Дело в том, что в текущей архитектуре хранение кода оторвано от веб морды гитлаба. И за хранение Гита отвечает, внезапно, демон gitaly. Соответственно, это чисто внутренняя штука гитлаба, которая не терпит изменений напрямую из ФС.

        Как не терпит? Где issue что gitaly не терпит изменений напрямую из ФС? Более того у Gitlab инструкция https://docs.gitlab.com/ee/administration/server_hooks.html по использованию серверных хуков.


        Т.е. хотелось бы обоснования "почему" метод описанный в статье будет работать.

        То почему? Он работает. Даже скриншоты сделал.


        Второй момент. Окей. Мы руками залезли в ФС, подтюнили гит хуки. Где гарантия, что в какой-то момент времени они не пропадут (например, с обновлением гитлаба) или не перестанут срабатывать?

        Вот и проверим. Думаю что не пропадут.


        В третьих, выглядит так, что действительно проще гитлаб купить. Это всё-таки инструмент, который позволяет зарабатывать деньги, а, следовательно, стоит вложиться в него. На каком там уровне гит хуки появляются? 4 доллара за пользователя в месяц? А заодно и получаем кучу другого полезного функционала и спим спокойно.

        У кого Gitlab купленный, тому этот пост не нужен. Добавил опрос про редакцию Gitlab

          0
          Как не терпит? Где issue что gitaly не терпит изменений напрямую из ФС? Более того у Gitlab инструкция https://docs.gitlab.com/ee/administration/server_hooks.html по использованию серверных хуков.

          Л — Логика https://docs.gitlab.com/ee/administration/gitaly/praefect.html
          На самом деле я ошибся — за серверные хуки отвечает gitlab-shell (другой демон, не gitaly), но там в доке все равно все как-то запутанно описано. Как-то хитро мержатся хуки из репозитория и из конфига гитлаба:
          https://docs.gitlab.com/ee/administration/server_hooks.html


          Server-side Git hooks are typically placed in the repository’s hooks subdirectory. In GitLab, hook directories are symlinked to the GitLab Shell hooks directory for ease of maintenance between GitLab Shell upgrades. Server hooks are implemented differently, but the behavior is exactly the same once the hook is created.

          и


          https://gitlab.com/gitlab-org/gitlab-shell


          The gitlab-shell repository used to also contain the
          Git hooks that allow GitLab to validate Git pushes (e.g. "is this user
          allowed to push to this protected branch"). These hooks also trigger
          events in GitLab (e.g. to start a CI pipeline after a push).
          We are in the process of moving these hooks to Gitaly, because Git hooks
          require direct disk access to Git repositories, and that is only
          possible on Gitaly servers. It makes no sense to have to install
          gitlab-shell on Gitaly servers.

          p.s. вот еще две ссылки с блок-схемами, чтобы понимать как это выглядит "в натуре"


          https://about.gitlab.com/handbook/engineering/infrastructure/production/architecture/
          https://docs.gitlab.com/ee/development/architecture.html#simplified-component-overview

            +2
            Вы можете выдать чето удобоваримое, кроме размышлений? :D
              0

              Я размышляю, следовательно, я существую :-D

                0
                Это был намёк автору, что статье недостаёт жирного такого дисклеймера

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое