🚀 DevOps: Скрипт "CI/CD-раннер за 60 секунд" (Docker)

Боль: Ваш docker build в общем CI/CD GitLab/GitHub "висит" в очереди 20 минут. Вы не можете работать, потому что все "раннеры" заняты.

Реакция админа: "Пойду попью кофе, подожду".
Реакция архитектора: "Я запущу свой runner на своей Home Lab (или VDS) за 60 секунд".

Эти "однострочники" — это не просто docker run, это мгновенное масштабирование вашего CI/CD.

Скрипт для GitLab Runner:

# 1. Получите ваш Registration Token из GitLab (Settings -> CI/CD -> Runners)
GITLAB_TOKEN="ВАШ_ТОКЕН"

# 2. Запускаем "вечный" раннер в Docker
docker run -d --name gitlab-runner --restart always \
    -v /srv/gitlab-runner/config:/etc/gitlab-runner \
    -v /var/run/docker.sock:/var/run/docker.sock \
    gitlab/gitlab-runner:latest

# 3. Регистрируем раннер
docker exec -it gitlab-runner \
    gitlab-runner register \
    --non-interactive \
    --url "https://gitlab.com/" \
    --registration-token "$GITLAB_TOKEN" \
    --executor "docker" \
    --docker-image "docker:20.10" \
    --description "My-Docker-Runner"

Скрипт для GitHub Actions Runner: (Процесс похож, но требует docker-compose для авто-регистрации)

Взгляд архитектора: Это "Infrastructure on-demand" (Инфраструктура по требованию). Вы не ждете ресурсы, вы создаете их. Вы строите распределенную CI/CD-систему, используя Docker как "строительный блок".

#devops #docker #cicd #gitlab #github #automation #скрипты #гайд

🛡 ЧЕКЛИСТ ПО ЗАЩИТЕ CI/CD И КЛАСТЕРА
Защита веток (Branch Protection): жесткий запрет прямых пушей в main / master / release. Слияние — строго через Pull Request / Merge Request минимум с одним аппрувом.

Контроль CI-манифестов: любые правки в .gitlab-ci.yml, azure-pipelines.yml, Jenkinsfile требуют обязательного согласования (Code Owners) со стороны DevSecOps / инфраструктурной команды.

Отказ от статичных токенов: миграция на динамическую федерацию удостоверений через OpenID Connect (OIDC) с выдачей короткоживущих токенов. Никаких постоянных kubeconfig на файловой системе!

Принцип наименьших привилегий в K8s: гранулярные роли RBAC на каждый отдельный namespace. Запретить CI/CD-пайплайнам использовать глобальный cluster-admin.

Харденинг сборочных хостов: категорический запрет на запуск контейнеров с флагом --privileged и проброс /var/run/docker.sock. Ограничение исходящего трафика (Egress Firewall) только доверенными реестрами и репозиториями.

Алертинг на аномалии IAM: настройка триггеров на сброс паролей привилегированных пользователей, добавление новых устройств MFA и нетипичные изменения геопозиции входа.

#devops #cicd #kubernetes #gitlab #security #sysadmin #admin_future

🦊 GitLab: снова уязвимость максимальной критичности — выполнение кода без аутентификации. Второй раз за две недели
Коллеги, пятница. Self-hosted GitLab в России стоит у многих команд — обновляем до выходных.
📌 ФАКТЫ
CVE-2026-110264 — переполнение целого числа в компиляторе регулярных выражений GitLab, CE и EE
По словам GitLab, при определённых условиях позволяет неаутентифицированному пользователю выполнить код на сервере
Исправлено в 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13. GitLab.com уже обновлён
Сведений об эксплуатации пока нет. Shadowserver видит в интернете более 2 700 открытых GitLab CE
Контекст: ~10 дней назад — CVE-2026-97229 (CVSS 10) в том же компоненте CI/CD, в прошлом месяце — path traversal, который позже попал в KEV
🛠 ПРОВЕРКА И ОБНОВЛЕНИЕ (Omnibus)

head -1 /opt/gitlab/version-manifest.txt          # текущая версия
sudo gitlab-backup create SKIP=artifacts           # бэкап перед обновлением
sudo cp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab-secrets.json /root/
sudo apt update && sudo apt install --only-upgrade gitlab-ce   # или gitlab-ee
sudo gitlab-rake gitlab:check SANITIZE=true

💡 В ЧЁМ СУТЬ

Три критичных уязвимости за полтора месяца — темп, при котором «обновлю на следующей неделе» перестаёт работать. GitLab держит токены деплоя, ключи и секреты CI. Если он смотрит в интернет — либо за VPN, либо автообновление патч-версий.

#gitlab #devops #security #cve #selfhosted #sysadmin #admin_future