SSH

Как сделать второй фактор при аутификации по ссш?
Самый простой способ это использовать гугл аутенфикатор. После настройки при аутенфикации нужно будет ввести и пароль и второй фактор из приложения (но с ключами полноценно пока не работает, все равно придется вводить пароль).
Как реализовать:
1. Ставим пакет

apt install libpam-google-authenticator 

2. Для нужно пользака, под которым будем ходить, генерим код командой

google-authenticator

дальше добавляем этот код в приложение гугл аутификатора

3. В файле /etc/pam.d/sshd добляем строку

auth required pam_google_authenticator.so

4. В /etc/ssh/sshd_config добавим

ChallengeResponseAuthentication yes

5. Рестарутем ssh

service ssh restart

На этом все, при следующем логине система попросит нас ввести пароль и код)

K8S

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

Все это работает на масштабе сотен подов и хоть какой то нагрузки, понятно что если у нас штук 10 подов и 20 rps к ним то можно взять хоть одну ноду)
Важно еще упомянуть, если мы возьмем 10 и 20 нод, с одинаковым общим ресурсом то 20 чаще будет дороже.

Заметка:
Когда обновляешь версию убунты на сервере гитлаба то нужно обновить гитлабовские deb репозитории до актуальной версии)

IDENPODENT

Часто в iac системах мы делаем все иденпотентно.
Это значит что мы не выполняем то что уже выполнено. Например:
- Не перезаписываем файлы
- Не пытаемся установить пакеты заново
- Не перезапускам без необходимости
Это позволяет нам делать все максимально быстро и безшовно, и уменьшить риск сломать то что уже работает)
Часто это делается с помощью какого либо стейта, либо с помощью хеширования операций.

INCLIDE

Сейчас пишим общие пйплайны для микросервисов. Флоу такой:
- На МР запускаются линтер и юнит тесты
- С develop ветки катится дев стенд, с main ветки тест стенд
- С тегов в прод
На дев и тест пайлпанй выглядит так:
1. Билд jar файла
2. Оборачивание в докер образ
3. Sca сканирование образа
4. Деплой на дев/тест
Для прода плинируем тегировать тест образ продовым тегом и катить уже.

Архитектурно это выглядит так:
Отдельная ci/cd репа, каждый шаг описан в отдельном файле, для того что бы в конкретную репу мы могли инклюдить только то что нужно. В самом репозитории сервиса делаем правки для деплоя, что бы можно было кастомизировать переменки, просто через extend общего шага из ci/cd репы.

TEAM

Иногда нужно отдавать часть задач на откуп самим разработчикам. Потому что если зацикливать все на себе то ты и сам все не успеешь и сама команда будет страдать.
Что бы можно разрешить им делать:
- Обновлять переменки
- Создавать базы данных на дев/тест стендах
- Смотреть отчеты сканов
- Пушить артифакты (например либы в нексус)

Если весь DevOps процесс выстроен хорошо то это будет очень просто делать, каждый разработчик сможет делать то что ему нужно и не ждать девопса)

Что бы я не давал:
- Все что касается изменения на прод инфре
- Сетевые политики
- Докручивать правила квалити гейтов
- Добавление/расширение ресурсов

Если кратко то все что касается разработки и не заафектит безопасность и не сломает прод можно давать разрабам, что бы не блочит их и не заваливать себя)

FAIL

Бывает случаи когда у нас падают тест и линтеры, тогда нам надо посмотреть отчет который сформировался. Как это сделать в гитлабе?
Допустим при падении артифакт с отчетом клаедтся в файл:

tests/result.html

Тогда в гитлабе в джобе с тестом нам надо указать:

  artifacts:
    when: on_failure
    paths:
      - "tests/result.html"
    expire_in: 1 week

Тогда этот артифакт сохранится при падении джобы и мы сможем скачать и посмотреть его)

REVIEW

Один из вариантов код ревью это ревью через LLM модели.
Это делается довольно просто, чрез какой ни будь n8n пайплайн, который считывает диффы из МР и отправляет их в модель. После чего отправляет результат в комент.
Но важно понимать цель и ограничения.
Таким подходом мы не сможем проанлизировать бизнес логику и проект в целом, на большом проекте проявится затухание контекста и дороговизна токенов. Но идеально подойдет для поиска прям явных проблем в конкретных участках кода которые мы изменили, например потенцеальные проблемы с безой, сложность и подобное.
И можно играться с моделями, например для сеснсетив кода использовать локальные модели, а для детального сложного анализа клаудные)
Ну и главное, это не замена ревью от человека, просто дополнительное мнение)

SHIFT LEFT

И снова в тему AppSec. Иногда стоит напоминать, в первую очередь себе, очевидные истины по типу:
Чем раньше мы узнаем о проблеме тем лучше.
Если мы берем весь SDLC в контексте безопасности то "раньше" тут это этап аналитики, до этого этапа очень сложно оценить безопасность. На этапе аналитики скорее поможет кросс ревью и консультации с инженерами, тут сложно придумать что то бОльшее.
Если на этапе аналитики все ок то уже на этапе разработки мы можем смотреть реализацию. Если совсем упарываться то можно поставить сканеры как плагин в IDE разработчиков, и не разрешать пушить пока код не пройдет по всем правилам. Но это долго и дорого. Поэтому лучшим выбором будет это сканирование в CI пайплане сразу после пуша, которое может блокировать дальнейшие мержи на стенды.

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

N8N

На днях вернулся к n8n.
Пофиксил пару проблем с старыми воркфлоу и начал дорабатывать один из них.
Вообще, все эти воркфлоу как правило не очень большие, и в принципе их можно просто навайбкодить как скрипты и запускать где угодно.
Но n8n дает централизованное место с понятной визуализацией всего процесса. Ну и запускать там нужные процессы куда проще чем как то собирать скрипты и запускать на сервере, что требует навыки администрирования)
Думаю для серьезных автоматихаций n8n слабо подойдет, у него есть ограничения и не всегда очевидная логика, но собрать какого ни будь простого бота прям изи)

LLM

Про использование языковых моделей для анализа кода.
Как по мне основной кейс использования это анализ дифференца в МР, так как что бы на каждый чих анализировал весь код нужно много токенов.
Что стоит ожидать в этом случае?
1. Анализ синтаксиса
2. Явные баги
3. Опечатки
4. Код стайл
5. Потенциальные проблемы

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

Не мог не поделится)

SUPPORT

Когда вся инфра и сам проект уже развернуты то для девопса настоет период поддержки.
Что обычно сюда входит:
1. Реакция на алерты
2. Реагирование на запросы разработки (чаще мелочи)
3. Зависит от проекта, но еще могут быть доступы
4. Мастшабирование
5. Иногда затаскивание новых сервисов и релизы старых

Чаще все это занимает не более часа в день, так как после первых релизов команда разработки может почти все сделать сама)

Уже кидал этот клип года 2 назад, но пожалуй повторюсь)
https://www.youtube.com/watch?v=lPlkGFDZn4I

VM

Сегодня столкнулся с кейсом: полетели настройки ссш ключей на виртуалке в яндексе.
Какое тут решение:
1. Делаем снимок диска нужно машины
2. Стопаем или удаляем машину
3. Конфигурим новую машину из снимка
4. Указыаем там нужный ключ и ip
5. Поднимаем машину

Все, после того как машина поднимется то там снова будут актуальные ключи, яндекс добавит их через cloud-init)

RELEASE

Как ускорить релизы фичей в прод.
Есть несколько базовых, именно технических, приемов которые могут сильно помочь:
1. Флоу разработки. Если фиче нужно пройти через несколько веток и стендов то это замедляет. Чем меньше промежутков от фича ветки до мастера тем лучше. (Смотрим на TBD)
2. Паралельность. Все мы запускаем проверки в пайплайнах, многие из них можно запускать паралельно а не последовательно.
3. Повторение. Если, допустим, юнит тесты прошли на тестовом стенде то после создания прод тега нет смысла запумкать их еще раз. (зависит от качества тестов)
4. Базовые сборки. Можно сразу собрать нужные образ и при релизах обновлять в них только артифакты.
5. Переиспользование. В идеале нам не нужно собирать прод сборку, можно просто сделать новый тег для препрод сборки.

По опыту, внедрение этих простых првил может ускорить выкатку фичей в разы)

TBD

Важно понимать один момент про транк.
Это методология разработки в контексте гита, которая описывает как мы должны сливать свои фичи в мастер. Но она не говорит о том что сразу после слива в мастер нам нужно релизится. В транке мы просто накапливаем изменения в мастере, а решение о релизе в прод принимается уже людьми)
То есть транк это больше CI процесс, а не CD.

PENTEST

Сейчас прохожу обучение по пентесту.
Это позволяет посмотреть на свою работу с другой стороны. То где могут быть ошибки в конфигурирование систем которые могут привести к эксплуатации.
Вот примеры:
- Использование простых паролей
- Одинаковые учетные данные в разных подсистемах
- Открытие лишних портов
- Разрешение входа по пароль по ссш
- Избыточные привелегии
- Сетевая связанность там где она не необходима

Это самые базовые вещи которые могут сильно облегчить проникновение. Дальше уже стоит думать про уязвимости в софте)

HEALTHCHECK

Каким в идеале должен быть хелсчек? Думаю из названия очевидно, он должен проверять состояние всей системы.
То есть не как обычно это делается - эндпоинт которые просто отвечает 200. Ведь состояние одного конкретного эндпоинта ничего не говорит нам о состоянии системы в целом.
Хелсчек должен проверять критичные для нас вещи. Как пример:
- Доступность бд
- Доступность критичных эндпоинтов
- Время ответа
И ответ должен быть бинарным, системы либо работает как нужно либо нет.
Ну и идеально было бы делать ответ на уровне http кода, а не в теле ответа. По необходимости в теле можно отдать детали)

CONF

Как может выглядить иденпотентное применение конфигурации. На примере nginx:
1. Пуш конфигурации в гит
2. Запуск джобы с ansible манифестом
3. Переписывание конф файла на серверах только при наличии диффа
4. После изменения конфигурации проводится тест самого nginx
5. Если конфигурация валидна то запускается reload
6. Если не валидна то откат до прошлой версии

Таким образом мы можем надежно заменить конфигурацию и делать это только там где есть необходимость)

SSDLC

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