🇺🇦 DevOps простыми словами

2022-05-04 14:52:02 Join DevOpsDays #StandWithUkraine on May 17-18!

During the conference, we would love to talk about DevOps during the crisis, incident, and business continuity management with our friends – Patrick Debois, Kris Nova, Kelsey Hightower, Lena Hall, Andrew Clay Shafer, and others.

18 talks from the world DevOps community are in the program and you’re welcome to Open Space Discussions as well, to share experience on complex cases with your peers.

When? May 17-18
Where? Online
Sign up for free & find out the agenda here: https://devopsdays.com.ua Открыть/Комментировать

2022-03-15 01:19:46 Channel name was changed to « DevOps простыми словами» Открыть/Комментировать

2022-03-01 00:50:34 Ban Russia from the Cloudflare

Repost + vote + comment

Давайте девопсовые войска, погнали

https://www.linkedin.com/posts/bukovskyi-kostiantyn_cloudflare-and-lets-encrypt-josh-aas-and-activity-6904022489488601088-eNDM Открыть/Комментировать

2022-02-24 17:33:09 Тримаємося разом, зберігаємо спокій, віримо в ЗСУ! Открыть/Комментировать

2022-02-13 20:07:31 Cache-Poisoned Denial-of-Service (CPDoS). Часть 2

Так, ну сейчас все используют CDNы! Мне бояться такого на продакшне или нет?
Хорошая новость тут в том, что атака известна с 2019 года, и многие крупные CDN научились с ней бороться.
Несмотря на то, что должно совпасть несколько условий со стороны ориджин сервера и CDN провайдера, наиболее уязвимым оказался AWS CloudFront, т.к. их настройки позволяли укладывать на лопатки в основном с помощью HHO и HMC огромную часть фреймворков и веб-серверов, включая S3 . В итоге, они просто запретили кешировать ошибочные ответы от ориджина. Впрочем, большинство провайдеров начали делать тоже самое, либо выставляют очень маленькое время кеширования ошибочных ответов. Также были уязвимы Cloudflare, Akamai, CDN77, Fastly, но только в связке с IIS, ASP.NET, Flask и Play 1.

Еще один способ бороться с этим самостоятельно - это выставлять на все свои ошибочные ответы/страницы хедер Cache-Control: no-store.

Третий способ - выставить WAF перед вашим бекендом.

Так, ну мы вообще не используем никаких кешей перед бекендом, мне эти ваши CPDoSы побоку!
А вот и нет! Например известная опенсорс CMS Drupal имеет внутренний кеш, который подвержен подобным атакам. Только там все игрища происходят вокруг X-Forwarded-Host и Host хедеров, в которые можно вставить как свой хост, так и JS скрипты. Ресерчеры также накопали всякие более извращенные отравления типа DOM, CORS и прочих. Открыть/Комментировать

2022-02-13 20:05:57 Cache-Poisoned Denial-of-Service (CPDoS). Часть 1

Что это за вид атаки и как работает?
Если атакующий нашел у вас такую уязвимость, то вы в какой-то момент заходя на свой сайт, вместо 200ОК увидите, что-то из 4xx-5xx. Пойдете проверить свой бекенд, и увидите, что с ним все в порядке. Однако проблема есть, рассмотрим разные варианты этой атаки ниже.

Стандартный способ использовать данную атаку против ваших сайтов предполагает, что перед вашим сайтом стоит какой-то кеширующий сервер: CDN, либо CDN+Varnish(или подобный). Например, у всех сайтов на популярном сайтбилдере WebFlow перед их серверами стоит Varnish.

curl -I https://somesite.webflow.com/
HTTP/2 200
server: openresty
via: 1.1 varnish, 1.1 varnish
x-served-by: cache-iad-kjyo7100124-IAD, cache-dub4350-DUB
...

Это значит, что клиент открывая их страницу обращается к Varnish, который в свою очередь идет на условный Origin бекенд somesite-backend.example.com и запрашивает у него страницу, отдает вам, и складывает себе в кеш. Далее все клиенты получают эту страницу из кеша.

Но что, если, Origin вернет не нормальную страницу, а скажем 400 Bad Request? Правильно - Varnish сохранит ее у себя в кеше, и будет отдавать дальше всем клиентам!

Ок, разобрались как работает. Правда мой сайт живет в Хецнере на огромном серваке всегда отдает 200ОК, у нас 99,9999% аптайм вообще-то, нам то что?
Как заставить ваш бекенд отдать НЕ 200ОК:

- HTTP Header Oversize (HHO)
Атака HHO заключается в том, что вы посылаете GET запрос с заведомо большим HTTP header. И тут важный момент: промежуточный кеш должен пропускать такие хедеры по размеру больше, чем может принять ваш бекенд. Как это выглядит на пальцах:

Client: HTTP GET with X-Bad-Header: "Very-Big Value-01123581321345589144233377610987"
↓↓↓
Cache: Looks good to my internal headers limits
↓↓↓
Origin: Oh, too big header for me. 400 Bad Request
↓↓↓
Cache: 400 Bad Request saved into Cache

Дело сделано, все следующие после этого трюка клиенты получают от кеша 400-й ответ.

- HTTP Meta Character (HMC)
Подобный к HHO вид, только в хедере вы добавляете мета символ, вроде \n, \r, \a. Кеш пропускает этот хедер на бекенд, который не может это обработать, и отвечает что-то типа Character not allowed и 400 Bad Request, все, кеш отравлен!

- HTTP Method Override Attack (HMO)
Этот метод как вы могли догадаться направлен на переопределение заголовка X-HTTP-Method. Далеко не все фреймворки/бекенды поддерживают X-HTTP-Method-Override, однако для тех кто поддерживают вы можете переопределить HTTP метод, проскочив кеш, например так:

curl -H "X-HTTP-Method-Override: POST" https://somesite.example.com/index.html получив в ответ "404 Not Found, POST on /index.html not found". Кеш опять отравлен, все остальные клиенты как и в примерах выше будут получать 404, вместо вашей стандартной страницы.

Будет справедливым вопрос: но, ведь на всех PoP(Point of Presence) наверняка уже лежат правильные ответы с 200ОК?
Все верно! Поэтому, злоумышленнику нужно проскочить со своим вредоносным реквестом в тот момент, когда на PoP закончился TTL обьекта, и PoP пойдет за ним на Origin сервер. Здесь просто пишется довольно незадачливый код, который в условном loop пытается отслылать свои реквесты на точку, в надежде на то, что вредоносный реквест будет первым после окончания TTL и отравит таким образом кеш. Это может занять не так много времени, как могло бы показаться.

Что происходит, если отравить одну точку CDN такими методами?
В зависимости от того как работает система внутреннего распространения кеша у того или иного провайдера, такой отравленный кеш как минимум расползется по ближайшим точкам присутствия в регионе, как максимум по всем PoP в мире. Но, теоретически, атакеру не сложно будет обнаружить все PoP провайдера и пройтись по каждой, чтобы отравить наибольшее количество точек. Открыть/Комментировать

2021-12-26 19:24:17 RUM DNS Traffic Steering. Часть 2

Ха, да я такое на nginx+GeoIP построю, и надо мне вот это заморачиваться?
Построите, вопросов нет. Но, будут вопросы к аккуратности определения геолокации вашего юзера по этим базам.
В общем, это слабенько будет коррелировать с самым коротким путем к вашем контенту.

А что делают когда из одной точки два CDN провайдера отдают приблизительно одинаковые результаты?
Такое вполне реально учитывая распространенность точек крупных CDN. В таком случае на клиент ставят cookies, которые говорят о том, что для него есть какой-то primary CDN, secondary и т.д. Это в том числе позволяет не нагружать только одну ближайшую точку присутствия всеми клиентами сразу.

Ок, мои сайты не такие крупные, но завтра мы получим миллиард $ инвестиций и нужно срочно сделать всем хорошо, куда бежать?
Есть несколько топ-компаний, которые на этом строят свой бизнес:
NS1, Constellix, Dyn, Cedexis. Ну, если и без чужих SaaS круты, то можно и самому, например на базе https://github.com/akamai/boomerang Открыть/Комментировать

2021-12-26 19:18:38 RUM DNS Traffic Steering. Часть 1

Что такое RUM?
Думаю многие знакомы с RUM, он же Real User Monitoring. Но, если нет, то существует два типа замеров производительности вашего сайта:
• Synthetic. Этот функционал делают миллион разных “пингалок”: Pingdom, site24x7, StatusCake, Pingdom, Uptimerobot, etc. Они C разных локаций заходят к вам на сайт, и условно через
curl -H 'Cache-Control: no-cache' -Lw "DNS Lookup: %{time_namelookup} seconds \nRedirects: %{time_redirect} seconds with %{num_redirects} redirects \nFirst Byte: %{time_starttransfer} seconds \nConnect Time: %{time_connect} seconds \nTotal Time: %{time_total} seconds\n" -so /dev/null http://apple.com/
рисуют вам эти же значения в красивый UI. Все ок, но локации как правило статические, так же они находятся в датацентрах, что совсем не тоже самое, что юзерский интернет.
• RUM. Это подключаемая к вам на сайт js-библиотека, которая при каждой загрузке страницы отправляет кучу перфоманс данных в сторону коллектора, и вам рисуют красивые данные в UI. Только точность тут гораздо выше, т.к. собирается все это прямо в браузере клиента, со всеми его особенностями той самой Last mile.

Вроде понятно. Причем тут DNS?
Зайдем издалека, и поговорим с желтой о вот какой проблеме.

- Уточка, хочу стать поближе и побыстрее к своим клиентам? Что посоветуешь?
- Уточка: конечно же подключить CDN!
- А какой CDN подключаем? Akamai, CloudFront, Google, CloudFlare? Кто из них будет лучше для всех регионов сразу и даже стран?
- Уточка: а давай подключим все сразу?
- А давай! Правда все еще непонятно какой CDN для какой страны использовать! Кто там у нас лучше всех перформит в Индии?
- Уточка: но CDN же крутые, они используют Anycast, он все сам разрулит!
- Хм, но меньшее количество хопов ≠ лучшее latency!
- Уточка: ....ладно, что же делать?

И вот тут в игру вступает DNS Traffic Steering based on RUM. В свой(не обязательно) сайт ставляем js-ку, но, очень обрезанную по-сравнению с классическим RUM. Меряем мы только latency и какие-то еще performance штуки до ближайших точек PoP ваших CDN в этом регионе, берем эти цифры и отправляем в сторону вашего коллектора, условного хадупа. Обрабатываем данные, и постоянно перестраиваем “таблицу маршрутизации” на основании того, кто лучше перформит конкретно в этой локации, соотвественно, кого и в какую точку отправлять с помощью наших днсов. Как пример, для Ирландии мы выставили использовать Akamai и CloudFlare, и вот флара взяла и отправила точку на обслуживание, и весь трафик у них начал ходить через Лондон, latency увеличилась, и все органически перетечет в Akamai. Причем настолько быстро насколько низкие у вас TTL. Тоже самое сработает при полном отказе одного из CDN, да такое тоже бывает

Самые внимательные спросят: так ведь мы уже зашли на сайт, резолвы где-то там позади?
По-факту замер RUM и клиентские резолвы не обязательно связаны. В целом, есть всего два сценария:

- Клиент использует EDNS, и присылает вместе с днс реквестом свою сабнет сеть, а значит и Autonomous System (AS). В базе резолвера за счет других клиентов уже есть перфоманс информация о вашей AS, и вам сразу же отдают правильные ip адреса PoP, CDN и прочее, используя т.н. “таблицу маршрутизации”, которая обновляется постоянно, практически реал-тайм.
- Клиент не использует EDNS, тогда берется IP резолвера например и отдается лучший вариант из агрегированной статистики для клиентов, которые находятся за этим резолвером и уже присылали какую-то статистику. Не редко крупные провайдеры могут шарить между собой обезличенные базы, чтобы лучше покрывать такие кейсы. А также вы можете принести свои данные, или community-sourced, чтобы лучше управлять своим трафиком.

Пруфов не предоставлю, т.к. давно было, но тот же AWS CloudFront на заре своего запуска использовал данные RUM, которые они собирали с Amazon.com, и таким образом сильно повысили качество своего CDN. Открыть/Комментировать

2021-11-27 18:02:32 macOS виртуализация с криповым именем. Anka. Часть 2

CI/CD integration

Как и писал выше, есть плагины под разные системы CI/CD, посмотреть и попробовать поиграться можно тут https://docs.veertu.com/anka/intel/ci-plugins-and-integrations/. Триал на 30 дней можно получить просто зарегавшись, на этапе скачивания! Поэтому я сразу побежал посмотреть пример с Github Actions. И вот как это поверхностно работает:

GHA Agent + Anka on Host:

- Ставим Anka на self-hosted мак-мини
- Туда же ставим GHA агента
- Добавлям .github/workflows/{whatever}.yml с их action, туда же внутрь команды, которые хотите отправить в виртуалку, и через GHA агента, они прилетят через anka run дальше. Живой пример https://github.com/veertuinc/github-actions-examples/actions

Выглядит вполне неплохо, однако, есть очевидные минусы! Чтобы делать параллельные запуски на одной железке вам надо будет плодить несколько GHA агентов, что выглядит так себе в плане автоматизации, если честно.

Anka on Host + GHA Agent inside VM:

Берем виртуалки, ставим туда GHA агента, и когда виртуалка поднимается, то у вас джобы автоматически подхватывают такого агента из пула. Здесь нет никакого anka run, сам GHA агент ранит команды так, как-будто бы он просто стоит на self-hosted чем угодно. Удобнее? Да, но также имеет свой минус: кто-то должен снаружи на хосте уметь тушить и поднимать ваши виртуалки. Но, это попроще первого варианта, имхо, и уже больше похоже на cloud что-ли.

Damn it API:

Самый жирный, но придуманный не Anka девелоперами, а моим коллегой! Вся эта связка умеет работать через API контроллера, кроме anka run на произвольную машину. Эту фичу они обещают в ближ месяцы запилить, и тогда управление всем процессом можно производить на контроллере, через API и забыть про агенты на стороне макоси.

Performance

Начитавшись разного в интернетах, я побаивался, что несмотря на кучу плюшек виртуализации, реджистри и прочего, производительность будет сильно проседать. Я провел Geebench тесты, которые показали что страдает в основном Multi-Core. За результатами сходите в комменты к посту.

Синтетические тесты хорошо, но я пошел проверять на наших реальных билдах, с юнит-тестами и сборкой разных пакетов. Итог меня честно говоря удивил, т.к. результат на Bare-Metal и в внутри одиночной виртуалки практически не отличались между собой. И даже больше - если запускать 2 виртуалки в параллель поделив пополам CPU и RAM на них, то они будут быстрее на 33% по скорости билда, по сравнению с последовательными шагами на Bare-Metal.

VM Templates automation
Следуюшим вызовом будет тема автоматизации самих виртуалок и базовых темплейтов/имеджей. Но, думаю, это врядли будет так интересно, т.к. packer+ansible известен всем, и мне кажется, многим понятно как это будет выглядеть, учитывая, что у Anka есть плагин под Packer. Открыть/Комментировать

2021-11-27 18:02:02 macOS виртуализация с криповым именем. Anka. Часть 1

Что это еще за Анка такая?

Если вы вдруг пропустили пост выше https://t.me/devops_easy/18, то там предыстория, почитайте. Сам продукт называет себя "macOS Container-like Virtualization" или "macOS cloud for iOS CI and DevOps". И первый и второй слоган правдивы, но как всегда, со своей спецификой. Построено все это поверх Apple hypervisor, что большой плюс, т.к. это нативный гипервизор macOS, и там всякий scheduling, прочий низкоуровневый management ложится на плечи блекбокса от Apple.

Это как VirtualBox что-ли?
Скорее нет, чем да, ну, т.е. это тоже ПО для виртуализации, но работает только с macOS и заточено на CI/CD. А также у Anka есть свои киллер-фичи! Давайте пройдемся по компонентам, чтобы понять, что оно из себя представляет:

• Anka Develop. Ограниченная, но бесплатная тула для разработчиков, используется на своем макбучке или iMac. Это похоже как раз на виртуалбокс, где вы раните свои виртуалки. В данном случае, на бесплатной версии вам доступна только одна VM at a time, и вы не можете взаимодействовать с Image Registry(об этом позже). Т.е. что вы можете сделать - создать виртуалку с нужной macos, попробовать что-то туда поставить, поэкспериментировать. Выглядит будет примерно так:

$ anka create --ram-size 8G --cpu-count 4 --disk-size 80G --app ~/Install\ macOS\ Mojave.app Mojave

$ anka run Mojave sw_vers
ProductName: Mac OS X
ProductVersion: 10.14.5


Ну, или запустить в графическом интерфейсе как обычную виртуалку, получив что-то типа vnc.

• Anka Flow. Все тоже самое, что и Anka Develop, только платная, плюс такие фичи: Run Multiple VMs, State Snapshot/Suspend VM, USB Device Support, Ability to communicate with Anka Build Cloud (Controller & Registry). За Flow нужно заплатить $360 в год за каждый девелоперский макбук, независимо от его железа.

• Anka Build Cloud. Самый интересный для нас компонент, за который и придется платить от $600 per core per year за Basic tier. Разбивку по планам можете посмотреть тут https://docs.veertu.com/anka/intel/licensing/#anka-build-cloud.
Если проводить аналогии, то Build Cloud - эдакий микс Docker Hub(Registry), и Docker Engine API(Cloud Controller with REST APIs).

1) Registry в который можно пушить темплейты(имеджи) с макосью, и тегами, и соответственно пуллить их со стороны ваших макмиников. Тут все плюс-минус просто и понятно, кроме странной работы тегирования, т.к. это сделано не так удобно, как с докером.

2) Cloud Controller with REST APIs. Центральная точка для управления: нодами макоси, с предварительно установленной Anka и джоином их в кластер, самими виртуалками(start/stop/delete) на разных нодах, предварительного раскатывания имеджей на ноды, а также имеджами в реджистри, и много чего еще. Все это можно делать через наколеночно выглядящий интерфейс, либо понятно через API. CLI или sdk пока не имеется, поэтому писать обвязку нужно будет самостоятельно. Однако, у них достаточно разных плагинов под известные CI, возможно для вас все заработает и без танцев вокруг. Также там есть разные интересные плюшки в планах Enterprise и выше, типа Priority scheduling of VMs through controller или Clustering (Grouping) of Nodes, но туда еще не добрался, рассказывать нечего.

Ну, и кому это интересно, если это нельзя съесть, тр...или засунуть в Кубер?

Их доки немного вводят в заблуждение пунктами "High Availability With Kubernetes"! Однако в докеры/куберы можно будет запихнуть только реджистри и контроллер, и хоть за это спасибо! Представьте как вам надо было бы извращаться с сетевыми хранилищами на мак-миниках, чтобы хранить всю эту кучу разных имеджей под все случаи жизни. Оно выглядит еще немного в зачаточном состоянии, в плане манифестов, но, мучаться с Кубером это ж как раз наше, правда?) Не так страшно в общем. Открыть/Комментировать