У меня в прошлом была серия заметок про проверку Docker образов на уязвимости с помощью Trivy и их исправление с помощью Copacetic. Я всё это оформил в статью на сайте:
⇨ Проверка безопасности Docker образов с помощью Trivy
Данную связку хорошо дополняет Dockle. Предлагаю к ним компанию добавить ещё один популярный, удобный и бесплатный инструмент – TruffleHog. С его помощью можно проверять код, логи и конфигурации на наличие в них забытых секретов в виде паролей, токенов и приватных ключей. Причём TruffleHog может как найти секреты, так и проверить их. Для каждого сервиса написаны детекторы. Полный их список можно посмотреть в репозитории.
TruffleHog поддерживает следующие источники информации:
◽️Git репозитории, в том числе с отдельной интеграцией с github и gitlab
◽️Обычная файловая система
◽️Elasticsearch
◽️Логи в формате Syslog
◽️Docker образы и контейнеры
И некоторые другие источники. Не стал их все перечислять.
Программа представляет из себя одиночный бинарник, написанный на Go. Имеет как интерактивный режим работы для ручной проверки, так и передачу параметров через ключи. Соответственно, всё это легко интегрируется в ваши пайплайны для проверки кода и образов. Результаты работы можно получить сразу в формате json для последующего анализа.
Работает примерно так:
Это пример проверки тестового репозитория самих разработчиков. Установить trufflehog можно любым удобным способом. Самому скачать бинарник, либо использовать скрипт, который скачает сам нужную версию из репозитория:
Можно просто в Docker запустить:
Если запустить trufflehog без параметров, то откроется интерактивный режим настроек, где можно по шагам задать параметры проверки.
Программа универсальная и поддерживает свои проверки. Вот пример конфигурации, где заданы некоторые из них. Проверил, добавив в один из логов попадающую под шаблон из примера строку:
Trufflehog успешно её обнаружил. В данный момент разрабатывается в том числе и универсальный механизм проверок для своих внутренних сервисов, а не только публичных, которые уже реализованы в самой программе. Данная функциональность пока в режиме альфа. Посмотреть, как будет работать, можно на примерах. Там вариант конфигурации с так называемым Custom Detector.
Описанный софт, в том числе то, что я перечислил в начале заметки, обычно присутствует в списке продуктов, которые рекомендуют к изучению и использованию, если вы хотите работать в качестве DevOps инженера. Так что если двигаетесь в этом направлении, изучайте его. TruffleHog одно из самых популярных решений в области проверки секретов.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#docker #devops #cicd #security
⇨ Проверка безопасности Docker образов с помощью Trivy
Данную связку хорошо дополняет Dockle. Предлагаю к ним компанию добавить ещё один популярный, удобный и бесплатный инструмент – TruffleHog. С его помощью можно проверять код, логи и конфигурации на наличие в них забытых секретов в виде паролей, токенов и приватных ключей. Причём TruffleHog может как найти секреты, так и проверить их. Для каждого сервиса написаны детекторы. Полный их список можно посмотреть в репозитории.
TruffleHog поддерживает следующие источники информации:
◽️Git репозитории, в том числе с отдельной интеграцией с github и gitlab
◽️Обычная файловая система
◽️Elasticsearch
◽️Логи в формате Syslog
◽️Docker образы и контейнеры
И некоторые другие источники. Не стал их все перечислять.
Программа представляет из себя одиночный бинарник, написанный на Go. Имеет как интерактивный режим работы для ручной проверки, так и передачу параметров через ключи. Соответственно, всё это легко интегрируется в ваши пайплайны для проверки кода и образов. Результаты работы можно получить сразу в формате json для последующего анализа.
Работает примерно так:
# trufflehog git https://github.com/trufflesecurity/test_keysЭто пример проверки тестового репозитория самих разработчиков. Установить trufflehog можно любым удобным способом. Самому скачать бинарник, либо использовать скрипт, который скачает сам нужную версию из репозитория:
# curl -sSfL https://raw.githubusercontent.com/trufflesecurity/trufflehog/main/scripts/install.sh | sh -s -- -b /usr/local/binМожно просто в Docker запустить:
# docker run --rm -it -v "$PWD:/pwd" trufflesecurity/trufflehog:latest github --repo https://github.com/trufflesecurity/test_keysЕсли запустить trufflehog без параметров, то откроется интерактивный режим настроек, где можно по шагам задать параметры проверки.
Программа универсальная и поддерживает свои проверки. Вот пример конфигурации, где заданы некоторые из них. Проверил, добавив в один из логов попадающую под шаблон из примера строку:
# trufflehog filesystem --config=$PWD/generic.yml /var/logTrufflehog успешно её обнаружил. В данный момент разрабатывается в том числе и универсальный механизм проверок для своих внутренних сервисов, а не только публичных, которые уже реализованы в самой программе. Данная функциональность пока в режиме альфа. Посмотреть, как будет работать, можно на примерах. Там вариант конфигурации с так называемым Custom Detector.
Описанный софт, в том числе то, что я перечислил в начале заметки, обычно присутствует в списке продуктов, которые рекомендуют к изучению и использованию, если вы хотите работать в качестве DevOps инженера. Так что если двигаетесь в этом направлении, изучайте его. TruffleHog одно из самых популярных решений в области проверки секретов.
⇨ 🌐 Сайт / Исходники
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
#docker #devops #cicd #security
1👍80👎3
Расскажу про одну интересную утилиту, которая поможет в строительстве своих велосипедов и костылей как на одиночных серверах, так и в пайплайнах. Речь пойдёт про сервер для вебхуков, который так и называется - webhook. С его помощью можно инициировать запуск локальных команд или скриптов через HTTP запросы.
Рассказываю, как это работает. Пишите какой-нибудь скрипт. Запускаете вебхук сервер, который слушает определённый TCP порт на сервере. При обращении к настроенному урлу на этом веб сервере, выполняется заданный скрипт. Покажу сразу на конкретном примере, чтобы было понятно.
Сервер живёт в базовом репозитории, поэтому просто ставим:
Пишем простенький скрипт
Пишем конфиг в формате yaml для webhook в файл
Запускаем сервер с этим вебхуком:
По умолчанию сервер запускается на порту 9000. Его можно переопределить в конфигурации. Теперь при переходе на урл http://192.168.137.42:9000/hooks/proclog-webhook будет выполняться с крипт
Подобный вебхук можно использовать в какой-то системе мониторинга на триггер по нагрузке на CPU. Это максимально простой способ получить аналитику по процессам, которые выполнялись в момент срабатывания триггеров. Я нечто подобное реализовывал полностью в Zabbix. Для него такие костыли не нужны, потому что у него есть свой агент для выполнения скриптов на хосте. Но с webhook настройка намного проще.
На базе этого сервера удобно настроить выполнение каких-то команд после коммита в репозитории или сообщений в мессенджерах. Можно исходники обновлять и контейнеры перезапускать. У автора есть примеры настроек для популярных сервисов.
У хуков есть множество настроек и ограничивающих правил. Например, можно разрешить только один тип запросов - GET или POST. Можно настроить возвращаемый ответ, добавить в него заголовки, ограничить список запросов только с конкретных IP. Всё это описано отдельным списком. Отдельно есть список правил, с помощью которых можно ограничить доступ к хукам. Как я уже сказал, это можно сделать с помощью списков IP или секретов в заголовках.
Подобного рода программ существует немало. Из тех, что обозревал я это:
▪️Updater
▪️Labean
Последний изначально был придуман, чтобы добавлять разрешающие правила на файрволе при посещении определённых урлов. Но в целом принцип работы тот же. Можно выполнять любые хуки по такому же принципу.
Из всех подобных программ webhook наиболее целостная и функциональная. Много настроек, возможностей, готовых примеров. В репозитории в самом конце есть список статей от пользователей, которые использовали этот сервер. Я свой тестовый хук настроил буквально за 15 минут. Всё очень просто и интуитивно понятно.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:📱 Telegram | 🌐 Сайт | 📲 MAX
#cicd #devops
Рассказываю, как это работает. Пишите какой-нибудь скрипт. Запускаете вебхук сервер, который слушает определённый TCP порт на сервере. При обращении к настроенному урлу на этом веб сервере, выполняется заданный скрипт. Покажу сразу на конкретном примере, чтобы было понятно.
Сервер живёт в базовом репозитории, поэтому просто ставим:
# apt install webhookПишем простенький скрипт
top-proc.sh, который будет записывать в текстовый файл отсортированный по нагрузке список процессов в системе:#!/usr/bin/env bash/usr/bin/mkdir -p /var/log/proclog/usr/bin/ps aux --sort=-pcpu,+pmem > /var/log/proclog/ps-$(date +%F_%H%M%S)Пишем конфиг в формате yaml для webhook в файл
hooks.json:- id: proclog-webhook execute-command: "/var/webhooks/top-proc.sh" command-working-directory: "/var/webhooks/"Запускаем сервер с этим вебхуком:
# /usr/bin/webhook -hooks /var/webhooks/hooks.json -verboseПо умолчанию сервер запускается на порту 9000. Его можно переопределить в конфигурации. Теперь при переходе на урл http://192.168.137.42:9000/hooks/proclog-webhook будет выполняться с крипт
/var/webhooks/top-proc.sh, который создаёт логи в директории /var/log/proclog. Подобный вебхук можно использовать в какой-то системе мониторинга на триггер по нагрузке на CPU. Это максимально простой способ получить аналитику по процессам, которые выполнялись в момент срабатывания триггеров. Я нечто подобное реализовывал полностью в Zabbix. Для него такие костыли не нужны, потому что у него есть свой агент для выполнения скриптов на хосте. Но с webhook настройка намного проще.
На базе этого сервера удобно настроить выполнение каких-то команд после коммита в репозитории или сообщений в мессенджерах. Можно исходники обновлять и контейнеры перезапускать. У автора есть примеры настроек для популярных сервисов.
У хуков есть множество настроек и ограничивающих правил. Например, можно разрешить только один тип запросов - GET или POST. Можно настроить возвращаемый ответ, добавить в него заголовки, ограничить список запросов только с конкретных IP. Всё это описано отдельным списком. Отдельно есть список правил, с помощью которых можно ограничить доступ к хукам. Как я уже сказал, это можно сделать с помощью списков IP или секретов в заголовках.
Подобного рода программ существует немало. Из тех, что обозревал я это:
▪️Updater
▪️Labean
Последний изначально был придуман, чтобы добавлять разрешающие правила на файрволе при посещении определённых урлов. Но в целом принцип работы тот же. Можно выполнять любые хуки по такому же принципу.
Из всех подобных программ webhook наиболее целостная и функциональная. Много настроек, возможностей, готовых примеров. В репозитории в самом конце есть список статей от пользователей, которые использовали этот сервер. Я свой тестовый хук настроил буквально за 15 минут. Всё очень просто и интуитивно понятно.
❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.
———
ServerAdmin:
#cicd #devops
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍121👎3