CatOps
5.08K subscribers
94 photos
5 videos
19 files
2.57K links
DevOps and other issues by Yurii Rochniak (@grem1in) - SRE @ Preply && Maksym Vlasov (@MaxymVlasov) - Engineer @ Star. Opinions on our own.

We do not post ads including event announcements. Please, do not bother us with such requests!
Download Telegram
​​Кстати, писал уже, что GitHub будет предупреждать пользователей про known vulnerabilities для ваших проектов

Вот так это выглядит вживую:
Segment рассказывают о пяти способах тестирования Go приложений
Милый комикс о Kubernetes от Google Cloud Platform

https://cloud.google.com/kubernetes-engine/kubernetes-comic/

Зайдёт, кстати, и людям, которые с Kubernetes знакомы так себе, но просто любят комиксы 🙃

#kubernetes
Yevgeniy Brikman — сооснователь компании Gruntwork и автор книг "Hello, Startup" и "Terraform: Up & Running" — написал колонку о том, что людей надо учить не кодить, а компьютерным наукам вообще. На фоне повального увлечения курсов по "кодингу" звучит интересно.

Основной тезис в том, что есть наука (комплекс наук) про решение задач и мышление. А есть её инструмент — написание кода. Точно так же, как астрономия не про телескопы, но безусловно с ними связана.

И бонусом в самой статье есть куча ссылок на различные образовательные ресурсы.

#culture #education
В рассыдке HangOps рассылке прилетела интересная статья от DataDog со статистикой по использованию контейнерной оркестрации. Некоторые моменты:

- В AWS чаще использют ECS, Kubernetes чаще используют во всех других средах
- Оркестарция сокращает продолжительность жизни контейнеров на 40%
- В Кубернетес контейнеры в среднем живут в 8 раз меньше, чем в ECS, возможно потому что их запускают под опеределенные вычислительные нужды, а в ECS больше аналогов "обычных приложений". "Флот" под управлением Кубера тоже в среднем больше
- В ECS меньше запускают стандартные образы, чем в Kubernetes
- Многие организации смешивают версии контейнеров latest с определенными версиями
Хотя наша профессия техническая, очень часто приходится присутствовать на каких-то переговорах по всяческим поводам: будь то внедрение новой технологии, выбор оптимального пути решения задач или банальное несовпадение мнений во время стендапа.

Гарвардская школа юриспурденции подготовила список из 32 вопросов, которые помогут подготовиться к переговорам. Вопросы общие, так что будут полезны не только юристам, но и технарям.

И поскольку DevOps — это ещё и культура, я считаю вполне логичным этим списком поделиться

#culture
Цикл о построении системы распределенных логов. Где под логом понимается упорядоченная структура данных, состоящая из immutable events с возможностью только добавления

В первой части рассказаны основы того, как делать лог по частям

Вторая часть про репликацию
CloudFlare объясняют, почему TLS 1.3 до сих пор не используется в браузерах по умолчанию.

Если очень кратко, потому что процесс установления соединения... "заржавел".

Если чуть менее кратко: потому что процесс поломан на огромном количестве серверов, поэтому они дропают соединение вместо того, чтобы ответить, какая максимальная версия поддерживается. Костыль, который был призван это "починить" -- insecure downgrade -- выпилили производители браузеров потому что он insecure (irony). И казалось бы вот он новый костыль -- замаскировать TLS 1.3 по максимуму под TLS 1.2, чтобы хотя бы не дропать коннекшн, а там уже походу разбираться, на чем ехать. Но не тут то было. Ибо между браузером и сервером существует нехилая такая прослойка из шут пойми чего, включая машинки анализа трафика. Чтобы не приведи Ганеш законопослушный гражданин не открыл какой-нибудь крамольный сайт из блэклиста. И вот оказалась, что одному Ктулху известно, как эти самые коробочки будут реагировать даже на малейшие изменения в опциональных полях.

И выхода из этого пике в дальносрочной перспективе не видно. Больше боли в блоге CloudFlare

Не болейте!
Пора бы уже из новогоднего угара вливаться в рабочий поток

Кстати, ещё раз о списках и итогах года:

OpenNET подвёл итоги 2017 поважным событиям мира открытого ПО и смежных тем

https://www.opennet.ru/opennews/art.shtml?num=47827

Статья, конечно, прошлогодняя уже, но что поделать ¯\_(ツ)_/¯
Год начинается бодро!

Найдена уязвимость в процессорах Intel, которая позволяет пользовательским приложениям залезть в память ядра

Краткое содержание на русском

Больше текста на английском

Все детали не раскрываются до выпуска соответствующих патчей. Патчи ориентировочно будут готовы в середине Января. Ходят слухи, что в linux kernel 4.14.11 уже починили, но это не точно

#security
Насколько глубока кроличья нора?

Вчерашний hole с процессорма обростает новыми подробностями. Во-первых, это серьезный аппаратный косяк, это значит, что затронуты вообще все вычислительные устройства (https://techcrunch.com/2018/01/03/kernel-panic-what-are-meltdown-and-spectre-the-bugs-affecting-nearly-every-computer-and-device/): будь то сервера или смартфоны. Да, ARM тоже, но тут начинаются нюансы:

На самом деле существует 2 проблемы с кодовыми именами Meltdown (Intel) и Spectre (Intel, AMD, ARM), которые, не вдаваясь в подробности, позволяют сделать одно и то же: пользовательскому процессу попасть в системную память. Возможные варианты атаки рассмотрели в этой статье от Google:
https://googleprojectzero.blogspot.com.tr/2018/01/reading-privileged-memory-with-side.html?m=1

Если нет времени читать большую статью от Google или whitepapers по каждой из уязвимостей, вот очень краткая выжимка по каждой из них:
https://danielmiessler.com/blog/simple-explanation-difference-meltdown-spectre/

Кроме того, тезисно проблема описана в этом Твиттер треде:
https://twitter.com/nicoleperlroth/status/948684376249962496

Теперь о близком нам: AWS и Azure уже приняли меры, что для пользователей вылилось в forced reboots. Amazon говорит что почти весь их парк уже пропатчен. В Google Cloud заявляют что со своей стороны они пропатчились и ребуты не нужны.
Однако, пользователям всё равно придётся патчить гостевые ОС самостоятельно вне зависимости от провайдера.

- AWS: https://aws.amazon.com/security/security-bulletins/AWS-2018-013/
- GCloud: https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html
- Azure: https://azure.microsoft.com/en-us/blog/securing-azure-customers-from-cpu-vulnerability/

Фикс: фикс уже готов, пользовательские обновления, как и говорилось, стоит ждать к середине Января. Плохая новость тут в том, что фикс ухудшит производительность CPU. Конкретные цифры очень зависят от задач, но цифры существенные: от 5% до 30% (возможно и больше)

И если вы уже собирались выдохнуть, то ещё рано. Mozilla подтвердили, что атака с использованием вышеупомянутых уязвимостей возможна через вэб контент:
https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/

Счастливого Рождества!

UPD: забыл, собственно, whitepapers добавить: https://spectreattack.com/

P.S.: думаю, для упрощения подведения итогов в конце года, надо ввести какой-то хэштег. И эти новости definitely #2018

#security #2k18
*UPD*
Статья от Microsoft о том, что в Azure уже всё пропатчили (но люди жаловались, что сервера без суда и следствия бутнули вчера): https://azure.microsoft.com/en-us/blog/securing-azure-customers-from-cpu-vulnerability/ (via https://t.iss.one/azure_ua)

Бенчмарки от Phoronix по поводу ожидаемой просадки производительности (via @yaroslavpats):
1: https://www.phoronix.com/scan.php?page=article&item=linux-415-x86pti&num=1
2: https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-Initial-Gaming-Tests
3: https://www.phoronix.com/scan.php?page=article&item=linux-more-x86pti&num=1

Если вам есть, что добавить по теме, стучитесь мне в @grem1in
Я наконец-то выспался с начала года! Негативная сторона в том, что сейчас очень лениво разбирать какие-то крупные статьи, потому ловите shell скриптик, который позволяет загнать в Terraform GitHub организацию, включая:
- публичные репы
- приватные репы
- репы команд
- сами команды
- членство в командах
- собсно юзеров

Если вы используете GitHub в работе, может быть очень даже интересно:

https://github.com/chrisanthropic/terraform-import-github-organization
Возвращаясь к нашим баранам: две статьи на русском языке, где на пальцах объясняют Meltdown и Spectre

Meltdown: https://geektimes.ru/post/297029/
Spectre: https://geektimes.ru/post/297031/

"Зоркий Глаз лишь спустя 20 лет заметил, что в крепости не хватает четвёртой стены " (с)

#security
​​Docker для Mac с поддержкой Kubernetes из коробки стал общедоступным!

Хотя, пока что в ветке Edge:
https://docs.docker.com/docker-for-mac/#kubernetes
В свете последних событий все углубятся в сферу безопасности, что, конечно, хорошо.

Вот, что примечательно в проблемах aka Meltdown & Spectre: это такая эталонная дыра. Во-первых, процессор всегда считался чем-то 100% надёжным, а все баги, мол, на уровне кода. Оказалось — нет. Во-вторых, атака зависти от навыков атакуемого, а не человеческой глупости. Это уже что-то кардинально отличающиеся от того же WannaCry. Это интересней с чисто исследовательской точки зрения: исследователь не будет гордиться тем, что отправил бабушке похаченный doc-файл. Всё прямо как в шпионских фильмах

Однако, не надо забывать, что большинство прикладных атак не витает так высоко. Если вы прёте чужие кредитки, ваш критерий успеха - колличество угнанных кредиток и, наверное, вероятность обнаружения. Но совсем не "угнать кредитку самым красивым способом".

И я вам сейчас форвардну пост, где как раз описано, почему это страшно и как мы сами открываем двери для не самых приятных людей

#security