Собрали бы cloud-init образ сами, это ведь намного интереснее, чем загрузить готовый. Возможностей автоматизации после старта там огромное количество и все это гибко настраивается под нужды среды или задачи образа.
Кстати, всю конфигурацию VM в PVE можно (и удобнее :) делать через этот же qm.
Несколько лет назад искали MFA решение и в т.ч. это смотрели.
Забавно было на встрече с сейлами слушать, почему они работают только как SaaS и в этот момент смотреть на их status page, где было несколько инцидентов недоступности за последние пару месяцев :)
Как клиент для обучения - почему бы и нет, новичкам может будет удобно интерпретировать ошибки и получать runbook, плюс справка под рукой. Но вот попытка защищать от опасных команд выглядит спорно, мне кажется. С root можно сломать все запустив чужой бинарник, собственный скрипт или просто cat - так отучите думать о том, что вообще вводится в терминал и к чему это приведет.
Да, established и правда забывается, я вот сам только что забыл :)
Скорость обновления должна сильно зависеть не только от размеров и топологии кластера. Как минимум, я вижу такие зоны влияния: конфиг (batch period, slice size и т.п.), нагрузка на api и controller (количество изменений, длина очереди).
Кстати, вам действительно нужно добиваться 0% ошибок при выкатке? Какой-то очень жестокий SLO получается.
А почему не используется хотя бы netflow для определения цели атаки?
И какой у вас будет алгоритм действий, если это будет не простой TCP/HTTP флуд в адрес, а какой-нибудь UDP volumetric/DNS amplification и прочие разновидности? А если уже не на одного клиента, а целенаправленно на вашу инфраструктуру?
Думаю, что на ваших масштабах минимальная автоматика для diversion/RTBH необходима. В конце-концов, есть gatekeeper.
На тему .arpa странно написано про доступность из паблика.
Владея ASN и адресами вполне можно делегировать на любой NS свои зоны in-addr.arpa и ip6.arpa (с помощью объектов типа domain в RIPE DB, например) и резолвить их публично, так и делают для PTR.
И так же можно держать их на внутренних NS, для любых адресов. Первое, что приходит в голову - зоны для RFC1918.
При более-менее серьезном DDoS conntrack на одном сервере вытечет очень быстро, отреагировать не успеете, т.к. там PPS - сотни тысяч.
И если у оператора нет инструментов митигации типа Arbor/gatekeeper и подобных - как-то значительно повлиять на атаку будет сложно.
В последнее несколько лет часто вижу целенаправленные атаки на саму инфраструктуру операторов и ЦОД, а не их клиентов прицельно Часто они к этому не готовы, т.к. привыкли решать проблему блэкхолингом проблемных адресов (а в этом случае - это все адреса).
А как вы предлагаете использовать PodDisruptionBudget для координации обновления хостов? Он не помешает вам отправить весь кластер в ребут одновременно.
Собрали бы cloud-init образ сами, это ведь намного интереснее, чем загрузить готовый. Возможностей автоматизации после старта там огромное количество и все это гибко настраивается под нужды среды или задачи образа.
Кстати, всю конфигурацию VM в PVE можно (и удобнее :) делать через этот же qm.
Синтаксис: https://chromeenterprise.google/policies/ca-certificates-with-constraints/
Конфигурация политик в Linux: https://support.google.com/chrome/a/answer/9027408?hl=en
Для Cursor может и не статистика. Только историй в таком духе про LLM все больше.
В статье непонятно в итоге, реализовали или нет.
Несколько лет назад искали MFA решение и в т.ч. это смотрели.
Забавно было на встрече с сейлами слушать, почему они работают только как SaaS и в этот момент смотреть на их status page, где было несколько инцидентов недоступности за последние пару месяцев :)
Так есть у вас on-premises вариант, полностью независимый от ваших ресурсов и доступа в интернет?
Тоже никак не понимаю, откуда желание использовать все эти менеджеры в принципе.
Имхо, продуманный нейминг и DNS в принципе закрывает эту проблему. В конце-концов, есть .ssh/config и known_hosts со всеми этими дополнениями.
IaC для VCD вспоминаю как кошмар. Раньше управляли правилами FW в NSX через terraform - пайплайны по часу были обычным явлением.
API у него тоже монструозный :)
Уже думали (и даже начинали) писать свою автоматизацию под это, но уехали с VCD раньше.
Как клиент для обучения - почему бы и нет, новичкам может будет удобно интерпретировать ошибки и получать runbook, плюс справка под рукой. Но вот попытка защищать от опасных команд выглядит спорно, мне кажется. С root можно сломать все запустив чужой бинарник, собственный скрипт или просто cat - так отучите думать о том, что вообще вводится в терминал и к чему это приведет.
Хорошая статья, спасибо.
Да, established и правда забывается, я вот сам только что забыл :)
Скорость обновления должна сильно зависеть не только от размеров и топологии кластера. Как минимум, я вижу такие зоны влияния: конфиг (batch period, slice size и т.п.), нагрузка на api и controller (количество изменений, длина очереди).
Кстати, вам действительно нужно добиваться 0% ошибок при выкатке? Какой-то очень жестокий SLO получается.
Интересно, почему? Эксплуатировал Nutanix и никогда не видел такой проблемы. Да и в обычном Linux KVM с OVS - тоже.
А обычный curl ваши сценарии тестов не покрывает?
Если платформа не совсем на коленке собрана, то в том или ином виде в ней будет какой-то SDN для организации сети VM.
BGP в таких системах используется для доставки трафика на VM.
Собирать сети на растянутых L2 доменах в масштабах хостинга/облака - это собирать огромный домен отказа, бороться со штормами и прочими приколами L2.
А почему не используется хотя бы netflow для определения цели атаки?
И какой у вас будет алгоритм действий, если это будет не простой TCP/HTTP флуд в адрес, а какой-нибудь UDP volumetric/DNS amplification и прочие разновидности? А если уже не на одного клиента, а целенаправленно на вашу инфраструктуру?
Думаю, что на ваших масштабах минимальная автоматика для diversion/RTBH необходима. В конце-концов, есть gatekeeper.
DNS - он такой, очень много особенностей и легаси, так что время от времени подкидывает головоломки и опять узнаешь что-то новое :)
В почте для этого есть SMTP Banner Check, для проверки PTR. Вероятно, речь об этом.
Спасибо, очень интересный материал.
Если честно, удивило, что в архитектуру сразу не заложили шардинг, хотя профиль нагрузки явно напрашивается на это. Почему так?
И интересны причины, почему выбрали Postgres, а не ваш же YDB под эти данные?
На тему .arpa странно написано про доступность из паблика.
Владея ASN и адресами вполне можно делегировать на любой NS свои зоны in-addr.arpa и ip6.arpa (с помощью объектов типа domain в RIPE DB, например) и резолвить их публично, так и делают для PTR.
И так же можно держать их на внутренних NS, для любых адресов. Первое, что приходит в голову - зоны для RFC1918.
А как же неискоренимый .local и mDNS? :)
При более-менее серьезном DDoS conntrack на одном сервере вытечет очень быстро, отреагировать не успеете, т.к. там PPS - сотни тысяч.
И если у оператора нет инструментов митигации типа Arbor/gatekeeper и подобных - как-то значительно повлиять на атаку будет сложно.
В последнее несколько лет часто вижу целенаправленные атаки на саму инфраструктуру операторов и ЦОД, а не их клиентов прицельно Часто они к этому не готовы, т.к. привыкли решать проблему блэкхолингом проблемных адресов (а в этом случае - это все адреса).
А как вы предлагаете использовать PodDisruptionBudget для координации обновления хостов? Он не помешает вам отправить весь кластер в ребут одновременно.