Согласны! Это сильно бы упростило использование Salt'a в случае с одним репозиторием, но у нас их два. Они имеют одинаковую структуру и должны правильно мержиться (пиллары и стейты).
Мы написали стейты, которые выполняют плейбуки. Это позволило нам отложить написание новых стейтов — полноценной замены плейбуков.
Так как Ansible у нас не был внедрен повсеместно (всего было около 50 плейбуков), скорее, это была проба инструмента, постепенно мы переделали плейбуки на стейты.
Пока не используем. Указанный Вами alcali смотрели, и он нам очень понравился! В нём только необходимо сделать авторизацию в freeipa.
Salt master в HA режиме? Или одна нода?
HA-режима нет, одна нода. Сейчас Salt используется для применения конфигурации. Деплой, оркестрацию еще не используем, поэтому можем себе позволить некоторый простой в работе мастера.
К тому же, сам мастер управляет собой, и вся его актуальная конфигурация есть в Git'е, поэтому создание нового мастера не проблема.
На самом деле, у нас два мастера: один — в проде, второй — для тестовых веток. У них общие ключи миньонов, поэтому для перехода на мультимастер нужен будет только общий ключ мастера, но один пока хорошо справляется.
Вероятно, автор оригинала статьи указал параметры к директиве proxy_cache_valid просто для примера. Можно изменить время обновления кеша самостоятельно согласно вашим требованиям, хоть до 1 секунды, например: proxy_cache_valid 200 1s;
При высоком RPS это позволит снизить нагрузку на бэкенд.
Я забыл отметить момент с 0-day уязвимостями. Для них точно не может быть ни issue, ни security advisory, т.е. даже вендор может не знать о том, что проблема у него есть. Навскидку два примера, когда проблема была обнаружена только потому, что о ней было сообщено в стороннюю программу – раз и два.
Спасибо, это сильные примеры и отличная практика! Нашей Bug Bounty программе всего год, и мы пока успеваем концентрироваться только на сервисах собственной разработки. Уверены, всё впереди! Wait and see :)
И не только этого. Можно этот список продолжить, например, падением сервиса, которое произойдёт в процессе исследования ресёрчером и закончить банальным rm -rf /. Но это ни в какое сравнение не идёт с тем, что данные пользователей будут доступны третьим лицам. Я не думаю, что пользователи вашего сервиса будут рады тому, что какой-то ресёрчер из Уганды сдампил у вас базу с их данными, даже при условии, что ресёрчер принял условия оферты.
Вопроc, конечно, непростой. Ваше мнение мы понимаем, переубедить ни в коем случае не хотим, просто попробуем объяснить нашу точку зрения. Мы работаем с приватной Bug Bounty программой. Вся информация о продуктах и технологиях, наш скоуп закрыты, а количество багхантеров ограничено. Все багхантеры подписали NDA и отвечают за свои действия перед законом. В данном случае можно считать, что багхантеры входят в команду Timeweb. Ведь наши сотрудники, например, тоже имеют доступ к данным клиентов.
Также стоит отметить, что при реальном инциденте вы не сможете отличить ресёрчера от нересёрчера, или нересёрчер, даже если вы его заметите, смело сошлётся на ваши правила программы и будет настаивать на том, что он просто пытался раскрутить уязвимость до максимального импакта. Скорее всего вы не пойдёте в суд с этим, а если и пойдёте, то, скорее всего, проиграете его.
К сожалению, так называемые не-ресерчеры уже пытались атаковать нас и ссылались на гипотетическую программу Bug Bounty. Нам кажется, что нельзя быть на 100% застрахованным и защищенным от таких ситуаций в любом случае. Этому миру нужно больше белых и этичных багхантеров!
Большое спасибо за развернутый комментарий и взгляд со стороны на наши процессы и опыт работы с Bug Bounty.
Данное решение в дальнейшем может сыграть с вами злую шутку. Например, в одном из таких сервисов найдут критичную уязвимость, которую вендор либо вовсе откажется исправлять, либо будет затягивать выпуск исправления, и, пока нет исправления, эту уязвимость будут эксплуатировать in the wild, в том числе, возможно, и в ваших сервисах, но вы просто об этом не узнаете, или узнаете, но поздно, потому что вам просто никто не принесёт репорт в вашу программу, т.к. он не входит в рамки программы. Если цель вашей программы не сэкономить денег, а именно получить уязвимость, которая есть в ваших сервисах, как можно скорее, то платить за уязвимость в стороннем софте, который у вас используется, необходимо.
Конечно мы понимаем, что в используемых нами opеn source решениях могут быть уже сейчас или находиться в дальнейшем проблемы безопасности. Мы стараемся решать эту проблему без использования программы Bug Bounty. Например, мониторить issue у проектов, исследовать их своими силами и т. д.
У нас нет цели сэкономить деньги, но в условиях ограниченности ресурсов нам важно эффективно распределить внимание багхантеров между нашими различными сервисами и получить информацию о проблемах безопасности.
Эта система определения критичности непрозрачна для ресёрчера и выглядит как явное одобрение с вашей стороны пост-эксплуатации найденной уязвимости. Например, если ресёрчер найдёт у вас SQLi, то он будет пытаться её раскрутить до RCE в надежде продемонстрировать максимально возможную критичность. В процессе этого он может случайно получить доступ к данным ваших пользователей, защита которых, как мне кажется, должна быть на первом месте;
Мы будем только благодарны, если багхантер предоставит информацию о максимально возможном векторе атаке :)
Если мы Вас правильно поняли, то Вы опасаетесь, что в процессе исследования ресерчер сможет получить данные клиента. В рамках Bug Bounty программы это не является проблемой, так как между нами, Bug Bounty платформой и ресерчерами заключено соглашение о неразглашении данных (NDA).
В перспективе, когда количество репортов у вас будет не 72 в год, а 72 в неделю, вы столкнётесь с тем, что вы будете тратить непростительно много времени на определение критичности по этой методике. И как вы указали, субъективность будет только усугублять это – если критичность репорта и размер вознаграждения у вас определяется командой, а не одним человеком, то они (члены команды) будут очень часто и много спорить о критичности, а следовательно, и о размере вознаграждения;
Вероятно, данное событие заставит нас пересмотреть подход и изменить данный процесс к более эффективному и быстрому варианту. Сейчас же мы работаем с тем, что имеем. На данный момент у нас есть возможность тщательно оценивать каждый репорт, так что мы стараемся использовать эту возможность.
В любом случае, если у вас в результате запуска программы вознаграждения за найденные уязвимости начались изменения в процессах с в лучшую сторону, то, смею вас заверить, вы двигаетесь в нужном направлении, и средства потраченные на выплату вознаграждений потрачены не зря.
Мы с Вами полностью согласны и видим в построении Bug Bounty процессов только положительные моменты. Спасибо!
Состояние каждого сервера отслеживается через систему мониторинга: когда нагрузка начинает превышать нормальное значение, некоторые пользователи переносятся на менее загруженные сервера через автоматизированные скрипты, но с ручным контролем.
Система балансировки регистраций отслеживает нагрузку на сервера, занятую память, свободное пространство. Исходя из этих данных, выбирается наиболее подходящий сервер.
Схема переноса пользователей работает очень просто, она автоматизирована скриптами. Файловые данные синхронизируются через rsync, базы данных дампятся и разворачиваются на конечном сервере. На начальном сервере, откуда шел перенос, устанавливается проксирование через Nginx на конечный сервер (проксирование работает около недели, на всякий случай). Меняются DNS записи или переносятся дополнительные IP-адреса, в случае если клиент использует наши NS; если нет, служба технической поддержки связывается с клиентом и решает вопрос. Так же меняются и данные клиента в служебных базах данных.
Да, выходит именно так, как Вы сказали. Если клиент задействует 1 версию PHP, то получит 1 ресурс; если две версии, то в 2 раза больше ресурсов. Например, пользователь хочет перевести свой сайт на другую версию PHP. В таком случае для пользователя это пройдет без проблем с нехваткой ресурсов. Когда клиенту мало ресурсов одной версии PHP под сайт (например, клиент хочет разместить много сайтов с большой нагрузкой), то чаще всего ему нужен отдельный сервер.
У нас есть тарифы с выделенными серверами, где у пользователя ограничены системные права (так же, как и на предыдущих тарифах), но работает админка в панели со всеми функциями управления сайтами, которые доступны и на других тарифах. Есть и тариф, где пользователю дается Dedicated с root правами и ipmi, но уже без админки.
А у user 1 как? Apache 7.1 и 7.2 делят пополам макс. предел по процессам и памяти? Или не пополам, что один из сайтов может перетянуть все одеяло на себя и клиент не будет понимать почему второй сайт хуже работает? Т.е. теоретически если человек добавит 8 сайтов и все под разными версиями php, то каждый из них будет по сути в 8 раз более ограничен, чем если бы все сайты были под какой-то одной версией php. В общем не понятно как у вас реализована дележка числа процессов и памяти между разными апачами в пределах одного аккаунта.
Здравствуйте!
Один мастер-процесс Apache2 с воркерами обслуживает все сайты одной версии PHP одного клиента. Каждый мастер-процесс имеет одинаковое количество ресурсов (ресурсы не режутся на количество сайтов). Получается, у user 1: сайт на Apache 7.1 имеет свой мастер-процесс, Apache 7.2 — свой. Таким образом, один сайт на PHP 7.1 будет иметь столько же ресурсов, сколько и два сайта на PHP 7.2 для одного клиента.
Согласны, пофантазировать с inotify epoll — любопытно!
.htaccess можно разместить в любом каталоге любого сайта. Сложно представить стабильную рекурсивную работу inotify с несколькими терабайтами данных при 80 млн занятых inode. А если демон умрет и какие-то события будут пропущены? В конечном итоге, нас интересует не столько красивое, сколько стабильное решение, которое не создаст неудобств и подойдет большинству пользователей.
По логике схемы, мы видим, что требуется делать Nginx reload при каждом изменении любого файла, с перечитыванием всех файлов .htaccess на всем сервере или где должны храниться временные данные.
Здравствуйте!
Спасибо за Ваш комментарий и вопрос.
Попробуем ответить так:
Какой смысл использования контейнеров, если нет контроля за ресурсами? В свободе настройки конфигурации и гарантированного предоставления ресурсов? Кажется, в таком случае лучше подходит схема dedicated, она менее избыточна.
Сравним контейнерную реализацию с shared-схемой. Например, у нас есть 10 клиентов и 10 Гб оперативной памяти на сервере. Мы гарантированно дали каждому по 1 Гб памяти. Вроде всё честно! Но в какой-то момент у одного клиента появилась нагрузка на 2 Гб памяти, и часть пользователей не смогла добраться до его сайта. А в shared-схеме у каждого из 10 пользователей есть доступ к 3 Гб памяти из 10 Гб памяти, но в режиме конкуренции. То есть каждый сайт может использовать много ресурсов в один момент времени. Когда конкуренция начинает негативно влиять на работу сайтов клиента или работу других пользователей, то сервер разгружается и пользователь получает столько ресурсов, сколько ему нужно, при этом имея разумные ограничения для обеспечения работы сайтов.
Действительно вставили задержку в py-код. Решили, что так будет нагляднее, иначе слишком много вывода и он очень быстро идет.
И на второй Ваш вопрос: да, съедается всё ядро.
Согласны с Вами на 100%.
А есть ли какие-то ограничения или особенности при использовании GitPython?
Мы пока API мало используем, CherryPy устраивает. Только после перезапуска salt-api бывает, что первый запрос фейлится.
Мы написали стейты, которые выполняют плейбуки. Это позволило нам отложить написание новых стейтов — полноценной замены плейбуков.
Так как Ansible у нас не был внедрен повсеместно (всего было около 50 плейбуков), скорее, это была проба инструмента, постепенно мы переделали плейбуки на стейты.
Пока не используем. Указанный Вами alcali смотрели, и он нам очень понравился! В нём только необходимо сделать авторизацию в freeipa.
HA-режима нет, одна нода. Сейчас Salt используется для применения конфигурации. Деплой, оркестрацию еще не используем, поэтому можем себе позволить некоторый простой в работе мастера.
К тому же, сам мастер управляет собой, и вся его актуальная конфигурация есть в Git'е, поэтому создание нового мастера не проблема.
На самом деле, у нас два мастера: один — в проде, второй — для тестовых веток. У них общие ключи миньонов, поэтому для перехода на мультимастер нужен будет только общий ключ мастера, но один пока хорошо справляется.
Да, мы тоже думали о таком варианте, но проблему удалось решить.
Вероятно, автор оригинала статьи указал параметры к директиве proxy_cache_valid просто для примера. Можно изменить время обновления кеша самостоятельно согласно вашим требованиям, хоть до 1 секунды, например: proxy_cache_valid 200 1s;
При высоком RPS это позволит снизить нагрузку на бэкенд.
Мы живем по правилу: видишь полезную статью — переведи, чтобы о ней узнало еще больше людей! :)
Будем благодарны, если вы посоветуете ресурсы с качественными статьями или актуальные для вас направления тем.
Спасибо, это сильные примеры и отличная практика! Нашей Bug Bounty программе всего год, и мы пока успеваем концентрироваться только на сервисах собственной разработки. Уверены, всё впереди! Wait and see :)
Вопроc, конечно, непростой. Ваше мнение мы понимаем, переубедить ни в коем случае не хотим, просто попробуем объяснить нашу точку зрения. Мы работаем с приватной Bug Bounty программой. Вся информация о продуктах и технологиях, наш скоуп закрыты, а количество багхантеров ограничено. Все багхантеры подписали NDA и отвечают за свои действия перед законом. В данном случае можно считать, что багхантеры входят в команду Timeweb. Ведь наши сотрудники, например, тоже имеют доступ к данным клиентов.
К сожалению, так называемые не-ресерчеры уже пытались атаковать нас и ссылались на гипотетическую программу Bug Bounty. Нам кажется, что нельзя быть на 100% застрахованным и защищенным от таких ситуаций в любом случае. Этому миру нужно больше белых и этичных багхантеров!
Конечно мы понимаем, что в используемых нами opеn source решениях могут быть уже сейчас или находиться в дальнейшем проблемы безопасности. Мы стараемся решать эту проблему без использования программы Bug Bounty. Например, мониторить issue у проектов, исследовать их своими силами и т. д.
У нас нет цели сэкономить деньги, но в условиях ограниченности ресурсов нам важно эффективно распределить внимание багхантеров между нашими различными сервисами и получить информацию о проблемах безопасности.
Мы будем только благодарны, если багхантер предоставит информацию о максимально возможном векторе атаке :)
Если мы Вас правильно поняли, то Вы опасаетесь, что в процессе исследования ресерчер сможет получить данные клиента. В рамках Bug Bounty программы это не является проблемой, так как между нами, Bug Bounty платформой и ресерчерами заключено соглашение о неразглашении данных (NDA).
Вероятно, данное событие заставит нас пересмотреть подход и изменить данный процесс к более эффективному и быстрому варианту. Сейчас же мы работаем с тем, что имеем. На данный момент у нас есть возможность тщательно оценивать каждый репорт, так что мы стараемся использовать эту возможность.
Мы с Вами полностью согласны и видим в построении Bug Bounty процессов только положительные моменты. Спасибо!
Попробуем ответить на ваш вопрос так.
Состояние каждого сервера отслеживается через систему мониторинга: когда нагрузка начинает превышать нормальное значение, некоторые пользователи переносятся на менее загруженные сервера через автоматизированные скрипты, но с ручным контролем.
Система балансировки регистраций отслеживает нагрузку на сервера, занятую память, свободное пространство. Исходя из этих данных, выбирается наиболее подходящий сервер.
Схема переноса пользователей работает очень просто, она автоматизирована скриптами. Файловые данные синхронизируются через rsync, базы данных дампятся и разворачиваются на конечном сервере. На начальном сервере, откуда шел перенос, устанавливается проксирование через Nginx на конечный сервер (проксирование работает около недели, на всякий случай). Меняются DNS записи или переносятся дополнительные IP-адреса, в случае если клиент использует наши NS; если нет, служба технической поддержки связывается с клиентом и решает вопрос. Так же меняются и данные клиента в служебных базах данных.
У нас есть тарифы с выделенными серверами, где у пользователя ограничены системные права (так же, как и на предыдущих тарифах), но работает админка в панели со всеми функциями управления сайтами, которые доступны и на других тарифах. Есть и тариф, где пользователю дается Dedicated с root правами и ipmi, но уже без админки.
Здравствуйте!
Один мастер-процесс Apache2 с воркерами обслуживает все сайты одной версии PHP одного клиента. Каждый мастер-процесс имеет одинаковое количество ресурсов (ресурсы не режутся на количество сайтов). Получается, у user 1: сайт на Apache 7.1 имеет свой мастер-процесс, Apache 7.2 — свой. Таким образом, один сайт на PHP 7.1 будет иметь столько же ресурсов, сколько и два сайта на PHP 7.2 для одного клиента.
Ответили ли мы на Ваш вопрос?
.htaccess можно разместить в любом каталоге любого сайта. Сложно представить стабильную рекурсивную работу inotify с несколькими терабайтами данных при 80 млн занятых inode. А если демон умрет и какие-то события будут пропущены? В конечном итоге, нас интересует не столько красивое, сколько стабильное решение, которое не создаст неудобств и подойдет большинству пользователей.
По логике схемы, мы видим, что требуется делать Nginx reload при каждом изменении любого файла, с перечитыванием всех файлов .htaccess на всем сервере или где должны храниться временные данные.
Спасибо за Ваш комментарий и вопрос.
Попробуем ответить так:
Какой смысл использования контейнеров, если нет контроля за ресурсами? В свободе настройки конфигурации и гарантированного предоставления ресурсов? Кажется, в таком случае лучше подходит схема dedicated, она менее избыточна.
Сравним контейнерную реализацию с shared-схемой. Например, у нас есть 10 клиентов и 10 Гб оперативной памяти на сервере. Мы гарантированно дали каждому по 1 Гб памяти. Вроде всё честно! Но в какой-то момент у одного клиента появилась нагрузка на 2 Гб памяти, и часть пользователей не смогла добраться до его сайта. А в shared-схеме у каждого из 10 пользователей есть доступ к 3 Гб памяти из 10 Гб памяти, но в режиме конкуренции. То есть каждый сайт может использовать много ресурсов в один момент времени. Когда конкуренция начинает негативно влиять на работу сайтов клиента или работу других пользователей, то сервер разгружается и пользователь получает столько ресурсов, сколько ему нужно, при этом имея разумные ограничения для обеспечения работы сайтов.
Apache используется, чтобы была возможность редактировать .htaccess. Это позволяет клиентам самостоятельно настраивать поведение веб-сервера.
Спасибо за вопрос. Да, всё верно: чтобы редактировать .htaccess. Так как это важно для наших клиентов.