Полное руководство по Docker Secrets

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

https://earthly.dev/blog/docker-secrets/

#devops #девопс

Подпишись 👉@i_DevOps

Оповещение об аномалиях в Prometheus

Изучаем, как настраивать оповещения об аномалиях для сезонных данных в Prometheus.

В Auto Trader мы стремимся создавать оповещения, которые большинство сможет использовать «из коробки», а не жестко прописывать их под конкретные сценарии. Мы хотим, чтобы вы могли развернуть сервис и сразу получить отдачу от платформы — особенно когда речь идет об отслеживании и оповещениях по вашим «Golden Signals» или управлении затратами.

https://bookflow.ru/opoveshhenie-ob-anomaliyah-v-prometheus/

#devops #девопс

Подпишись 👉@i_DevOps

Жизненный цикл управления уязвимостями в DevSecOps

Это первый пост из серии, которая будет глубоко погружаться в архитектуру программы DevSecOps. Цель этой серии — представить целостный обзор DevSecOps как совокупности технологически управляемых, автоматизированных процессов. Какие инструменты и технологии играют роль в DevSecOps? Как мы можем использовать технологии, чтобы настроить команды разработчиков на успех? Как мы выстраиваем роли и зоны ответственности для обеспечения слаженности, безопасности и скорости? На эти и другие вопросы мы ответим по мере развития серии.

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

«Моя задача — внедрить процесс разработки программного обеспечения по принципу secure-by-design, который предоставляет командам разработчиков возможность самостоятельно отвечать за безопасность своих цифровых продуктов. Мы добьёмся успеха за счёт контроля и обучения, а благодаря технологически ориентированной и автоматизированной архитектуре DevSecOps снизим трение и сохраним высокую скорость работы.»

https://blog.gitguardian.com/vulnerability-management-lifecycle-in-devsecops/


#devops #девопс

Подпишись 👉@i_DevOps

Безопасность по умолчанию: программное обеспечение в DevSecOps

Это второй пост в серии, посвящённой архитектуре программ DevSecOps. Цель этой серии — дать целостный обзор DevSecOps как набора технологически управляемых автоматизированных процессов. Если вы не читали первый пост, обязательно ознакомьтесь с ним!

В этой статье речь пойдёт скорее не о принятии решений, а об опыте разработчиков. Мы узнаем, как снабдить наших инженеров программного обеспечения инструментами, которые позволят им самостоятельно обеспечивать безопасность своего кода, и как поддержать их с помощью автоматизации. Прежде чем приступать, хочу ещё раз озвучить своё основное утверждение по DevSecOps:

«Моя задача — внедрить процесс разработки программного обеспечения с безопасностью по умолчанию, который даст командам инженерии возможность самостоятельно отвечать за безопасность своих цифровых продуктов. Мы добьёмся успеха с помощью контролей и обучения, а также снизим трение и сохраним скорость разработки благодаря технологически управляемой автоматизированной архитектуре DevSecOps.»

https://blog.gitguardian.com/secure-by-design-software-in-devsecops/

#devops #девопс

Подпишись 👉@i_DevOps

Целостность и безопасность конвейера в DevSecOps

Это третий пост из серии глубокого погружения в архитектуру программ DevSecOps. Цель этой серии — дать целостный обзор DevSecOps как совокупности ориентированных на технологии и автоматизированных процессов. Обязательно ознакомься также с первой и второй частью!

На данном этапе мы разобрали, как управлять уже существующими уязвимостями и как предотвращать появление новых. Теперь у нас есть жизненный цикл разработки ПО (SDLC), который обеспечивает создание программного обеспечения, безопасного «с самого начала». Осталось лишь разобраться, как обеспечить исполнение и защиту созданной нами архитектуры.

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


https://blog.gitguardian.com/pipeline-integrity-and-security-in-devsecops/

#devops #девопс

Подпишись 👉@i_DevOps

Стили взаимодействия микросервисов: 5 секретов, которые изменят ваш подход к backend-разработке

Взаимодействие между микросервисами — это больше, чем просто REST или RPC. Это фундамент архитектуры, от которого зависит масштабируемость, надёжность и производительность всей системы.

📌 Что будет на вебинаре:

— 5 ключевых стилей взаимодействия микросервисов: REST, gRPC, event-driven, messaging, CQRS;
— Сравнение: синхронное vs. асинхронное взаимодействие — плюсы, минусы, типичные ошибки;
— Когда использовать брокеры сообщений и какую роль играют очереди;
— Советы по построению отказоустойчивых коммуникаций между сервисами;
— Как логировать и отслеживать взаимодействия между микросервисами;

👉 Регистрация и подробности о курсе Highload Architect: https://vk.cc/cMHfWt

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

Bash-совет: анализ неудачных SSH-логинов и бан «горячих» IP 🔒🐚

Хотите быстро узнать, какие IP вызывают максимум неудачных попыток входа в SSH, и оперативно заблокировать самых настырных? Ниже скрипт:

#!/usr/bin/env bash
# ssh_fail_analyzer.sh
# Анализ неудачных SSH-попыток и вывод TOP-10 IP

LOG_FILE="/var/log/auth.log"       # путь к логам (для CentOS: /var/log/secure)
TOPN=10                            # сколько IP показывать

echo "Топ $TOPN IP с неудачными SSH-входами:"
grep -E "Failed password for" "$LOG_FILE" \
  | grep -oP '(?<=from )[\d\.]+' \
  | sort \
  | uniq -c \
  | sort -rn \
  | head -n "$TOPN"

Как это работает

1. grep -E "Failed password for"
Ищем все строки с неудачными попытками.
2. grep -oP '(?<=from )\[\d.]+'
С помощью PCRE-регулярки достаём только IP-адреса после слова "from".
3. sort | uniq -c | sort -rn
Сортируем, считаем вхождения и выводим в порядке убывания.
4. head -n "\$TOPN"
Ограничиваем результат топ-10.


🛠 Можно добавить в crontab ежедневный запуск и автоматическую отправку отчёта на почту или сразу бан «горячих» IP через iptables:

# в crontab: каждый день в 00:10
10 0 * * * /path/to/ssh_fail_analyzer.sh | mail -s "SSH Fail Report" admin@example.com

Или сразу блокировать подозрительные IP, если они превысили порог:

THRESHOLD=50
for ip in $(grep -E "Failed password for" "$LOG_FILE" \
              | grep -oP '(?<=from )[\d\.]+' \
              | sort | uniq -c \
              | awk -v t="$THRESHOLD" '$1 > t {print $2}'); do
  iptables -I INPUT -s "$ip" -j DROP
  echo "$(date): Заблокирован $ip за превышение $THRESHOLD неудачных попыток" >> /var/log/ssh_ban.log
done

👉@bash_srv

Почему нельзя парсить вывод ls(1)

Команда ls(1) достаточно хорошо справляется с отображением атрибутов одного файла (по крайней мере, в некоторых случаях), но когда просишь у неё список файлов, возникает огромная проблема: Unix позволяет использовать в имени файла почти любой символ, в том числе пробелы, переносы строк, точки, символы вертикальной черты, да и практически всё остальное, что вы можете использовать как разделитель, за исключением NUL.
Существуют предложения по «исправлению» этой ситуации внутри POSIX, но они не помогут в решении текущей ситуации (см. также, как правильно работать с именами файлов). Если в качестве стандартного вывода не используется терминал, в режиме по умолчанию ls разделяет имена файлов переносами строк. И никаких проблем не возникает, пока не встретится файл, в имени которого есть перенос строки. Так как очень немногие реализации ls позволяют завершать имена файлов символаи NUL, а не переносами строк, это не позволяет получить безопасным образом список имён файлов при помощи ls (по крайней мере, портируемым способом).

https://habr.com/ru/articles/823298/

#devops #девопс

Подпишись 👉@i_DevOps

systemd: как писать юниты с элегантной перезагрузкой

Разработка системы с элегантным завершением работы может оказаться той ещё пляской с бубном. В идеальном мире каждый сервис управлялся бы юнитом systemd. ExecStart запускала бы процесс, обрабатывающий SIGTERM, а ExecStop оповещало бы процесс и осуществляло блокировку, которая бы корректно завершала процесс и его ресурсы.

Однако многие программы завершаются некорректно, а то и вовсе сбивают все настройки при закрытии. В этой статье мы рассмотрим поведение systemd при завершении работы и методы написания юнитов systemd для выборочной очистки (custom cleanup) перед закрытием.

https://www.psdn.io/posts/systemd-shutdown-unit/


#devops #девопс

Подпишись 👉@i_DevOps