Без перехода к декларативному управлению DNS и автоматизации толку от такого аудита с пометками будет мало, через год или два опять придется начинать заново.
Кажется, сейчас почти у всех регистраторов есть API, под который либо есть провайдер для octodns/lexicon, либо его легко будет реализовать (BTW, на хабре есть моя статья про DNS IaC).
А приземлять записи напрямую на конечные ресурсы в целом плохая практика, имхо, особенно - если сервисов много. Перенесите этот слой на прокси/балансировщики, так и ответственность размываться не будет, и управлять трафиком/конфигом/сертами/etc будет намного проще.
Я не говорил ничего про обоснованность выбора архитектуры и количества компонентов разработчиками Sentry.
Адекватно или нет - у них есть определенный набор сервисов и зависимостей, необходимый для работы под их же нужды, в их сценарии, как они считают нужным. Добавлять сюда вариативность ради упрощения деплоя и поддержки бесплатной версии - это трата ресурсов команды, а бизнес ценность этого процесса сомнительна, на мой взгляд.
Ну а на тему чрезмерной декомпозиции и нерациональности и прочего - наверное не очень корректно рассуждать в таком ключе, не видя их инфраструктуру, метрики и требования.
Я думаю, что причина монструозности деплоя Sentry - не в хитром способе заставить вас купить SaaS, но в банальной экономии.
Экономии времени и трудозатрат на адаптацию их SaaS специфики (в виде огромных RPS, количества пользователей, SLO) под небольшие on-prem инсталляции. Можно сделать проще, конечно, но это будет фактически поддержка двух продуктов, один из которых - бесплатный и не накладывает ограничений (насколько я помню).
Я не предлагал протестное увольнение делать. У руководителя, конечно, есть своя жизнь, обязательства и прочее. Далеко не каждый может себе позволить демонстративно уйти в никуда.
Но это все еще не повод просто принимать участие в нарушении прав работника, как и не прилагать усилий для помощи, сваливая все на него одного.
Большинство облаков/хостеров делают override через /etc/ssh/sshd_config.d, ваш конфиг может просто не работать.
Но есть же ssh-copy-id
Перезапуск sshd не разрывает активные сессии, чтобы при ошибке вы себе доступ не сломали.
В LE уже разрешили получать сертификаты с IP SAN.
Ну нет же, здесь нет ничего сложного и это легко автоматизируется через тот же Ansible, делали бы плейбук что ли и про него хоть рассказали.
Странная статья.
Вы при обновлении учитывали cephx upgrade?
А где сейчас модели эти работают? Это ваши мощности или какой-то API внешний?
Никому не нужные и неизвестные ресурсы постоянно долбят боты, в т.ч. кучей запросов, обычно - с каким-то попытками эксплуатации известных уязвимостей.
Поставьте пустой nginx с доступом из интернета и посмотрите лог через сутки.
Без перехода к декларативному управлению DNS и автоматизации толку от такого аудита с пометками будет мало, через год или два опять придется начинать заново.
Кажется, сейчас почти у всех регистраторов есть API, под который либо есть провайдер для octodns/lexicon, либо его легко будет реализовать (BTW, на хабре есть моя статья про DNS IaC).
А приземлять записи напрямую на конечные ресурсы в целом плохая практика, имхо, особенно - если сервисов много. Перенесите этот слой на прокси/балансировщики, так и ответственность размываться не будет, и управлять трафиком/конфигом/сертами/etc будет намного проще.
Слушайте, ну это же прошлый век уже, нужно использовать скиллы. /s
Я не говорил ничего про обоснованность выбора архитектуры и количества компонентов разработчиками Sentry.
Адекватно или нет - у них есть определенный набор сервисов и зависимостей, необходимый для работы под их же нужды, в их сценарии, как они считают нужным. Добавлять сюда вариативность ради упрощения деплоя и поддержки бесплатной версии - это трата ресурсов команды, а бизнес ценность этого процесса сомнительна, на мой взгляд.
Ну а на тему чрезмерной декомпозиции и нерациональности и прочего - наверное не очень корректно рассуждать в таком ключе, не видя их инфраструктуру, метрики и требования.
Я думаю, что причина монструозности деплоя Sentry - не в хитром способе заставить вас купить SaaS, но в банальной экономии.
Экономии времени и трудозатрат на адаптацию их SaaS специфики (в виде огромных RPS, количества пользователей, SLO) под небольшие on-prem инсталляции. Можно сделать проще, конечно, но это будет фактически поддержка двух продуктов, один из которых - бесплатный и не накладывает ограничений (насколько я помню).
Можно не знать о нем. Просто адреса нужно разбирать по версии протокола в коде (библиотека это умеет), а не считать все как v4.
Новые приложения вообще лучше писать так, чтобы они понимали v6, а v4 хранить как mapped.
Работу над ошибками никто не отменял.
Тем более, у автора внешний бэкап был, хоть и случайно, вместе с локальным бэкапом и репликой.
Весьма поучительная история. Хорошо, что все обошлось.
Если проект для вас важен - сейчас самое время провести аудит, вероятно, техдолг у вас накопился приличный.
Для секретов в репозитории есть sops, например, и vault как KMS/PKI.
Для ssh есть системы типа Teleport, но вам, наверное, проще просто перейти на ключи и настроить fw (либо вообще разрешать ssh только через VPN).
Это обычная практика, но нужно ли это вам? И не забудьте, что мониторинг тоже может сломаться или быть на той же инфре, что и все остальное.
BTW, для простых внешних проверок и алертинга есть uptime-kuma.
Выглядит интересно, спасибо.
Собирал аналогичный инструмент, только не для kubernetes, а вообще для мониторинга intra/inter DC трафика.
Как идея вам - добавьте возможность подключать внешние агенты (без kubernetes).
И вопросы напрашиваются:
Вы всегда полный mesh собираете, или все же как-то оптимизируете набор пиров для проверки?
На каком количестве нод это сейчас работает?
Как поведет себя на 100/1000/5000?
IPv6 по-умолчанию сейчас включен во всех современных ОС.
По этой причине, отсутствие конфигураций того же ND snooping и RA snooping на сети (где вроде бы не используется IPv6) - хороший вектор для атак.
Понимаю.
Простых решений без негатива тут все равно не будет, это факт.
Я не предлагал протестное увольнение делать. У руководителя, конечно, есть своя жизнь, обязательства и прочее. Далеко не каждый может себе позволить демонстративно уйти в никуда.
Но это все еще не повод просто принимать участие в нарушении прав работника, как и не прилагать усилий для помощи, сваливая все на него одного.
Понимаю, видимо я слишком буквально воспринял эту часть :)
Я согласен с многими пунктами вашего материала, но вот это просто режет глаз:
Важно понимать, что в таком случае менеджмент поступает с руководителем таким же образом, как и с увольняемым.
И я считаю (и сам так делаю), что задача руководителя, помимо прочих - защищать интересы сотрудника, даже если его вскоре уволят.
Намного интереснее смотреть, как от атак на ARP защищаются пятью разными способами, пока где-нибудь рядом летят IPv6 RA от злоумышленника.
Ну, классика, в целом, в самом начале статьи:
Проблемы от недооценки рисков, отсутствия DR стратегии и, видимо, экономии на специалистах.
Хорошо ещё, если после таких инцидентов выводы действительно делаются.
Интересно будет, когда модель отправит что-нибудь типа:
Не говоря о том, что пайп - это валидная конструкция для bash.