Иии, первый пост про Kubernetes операторы.
Что это?
Упрощая - это приложение, которое живет в отдельном поде, может нескольких, обычный Deployment с ReplicaSet. Отвечает за свой(как правило) неймспейс, общается с Kubernetes API, чтобы автоматизировать какие-то действия, которые нельзя заавтоматизировать стандартными средствами.
Зачем это?
Довольно просто представить себе Stateless приложение в кубере, a вот со StateFull все гораздо сложнее. Самый подходящий пример - это базы данных. Мы поместили в кубер MySQL, мастер-слейв реплика, все отлично. Как делать бекапы, менять конфигурацию? Как переподнять реплику, после того как нода с ней(репликой) отвалилась? Вот тут и приходят на помощь операторы, через которые можно автоматизировать разные флоу управления кластером MySQL, Elastic, Redis, etc.
Зачем это?
Делать какие-то запросы к внешним сервисам. Например, оператор, который следит за появлением новых ингресс ресурсов, и добавляет их URL/Hostname в Pingdom, UptimeRobot, 24x7, прочие системы, для внешних чеков.
Есть же хельм, зачем вот это вот все?
Helm - это просто пакетный менеджер, и удобный шаблонизатор, чтобы вы не клепали(хотя все равно клепаем) миллионы ямл файлов для деплоймента.
Где найти готовые операторы?
На https://operatorhub.io/, можно обнаружить, что автоматизируют через операторы не только кластеры баз данных. Но, имхо, это самый лучший и довольно сложный кейс, который вписывается во всю эту концепцию.

Certificate Transparency.
Что это?
Если упростить, то это система мониторинга выпущенных SSL сертификатов по любым доменам!
Зачем это?
Ничто в нашем мире не идеально, и тем более безопасно! Центры сертификации по ошибке выдавали сертификаты не настоящим владельцам домена. Или взлом шведского центра сертификации DigiNotar позволил мошенникам выпустить тонны сертификатов, в том числе facebook и google, позволив получить данные множества пользователей. Таких историй довольно много.
В конце концов гугл придумал каким образом можно хотя бы пост-фактум понять, что что-то пошло не так и принять меры. Они предложили центрам сертификации присылать информацию о выпущенных ими сертификатах. И мониторя такие логи, вы можете узнать, что кто-то выписал сертификат на ваш домен без вас.
Где логи, бегу смотреть?
Например тут https://crt.sh/?q=i.ua
а тут можно не только посмотреть, но и подписаться на обновления https://developers.facebook.com/tools/ct/search/

http://thesecretlivesofdata.com/raft/ а пока позалипайте в крутое объяснение рафт консенсуса

Всем привет. Похоже, длинный саббатикал не способствует часто писать в собственный канал 🙂 Как и обещал, про Hashicorp Boundary. А еще я добавил возможность комментариев, welcome!

Boundary by HashiCorp

Что это?
Относительно новая опен-сорс тула от Hashicorp для доступа к разным средам, типа Кубера, баз данных, ssh, и т.д.
Зачем, если есть опенвпн?
Основная мотивация в том, чтобы избавиться от минусов старых подходов. Делая впн внутрь периметра, вам часто нужно сильно заморачиваться с подобными сценариями:
⁃ Автоматизировать выдачу и ревоук сертификатов для каждого клиента опенвпна
⁃ Выдать клиенту IP опенвпн сервера, и выдать(не всегда) IP куда ему коннектиться
⁃ Выписать и выдать креды базы данных, или ssh, etc.

Понятно, что все автоматизируется в случае впнов, и волты прикручиваются к базам данных, и SSH к IdP, но баундари обещает всю(ну почти) эту магию брать на себя! Разве не круто?

Зачем, если можно сделать bastion/jump hosts?
Похожие проблемы, что и с впном, плюс:
⁃ Юзер оказывается внутри сети со всеми вытекающими. Дада, фаерволы, айпитейблс наше все, но вы же понимаете как они выглядят, если несколько групп должны иметь разные права внутри этой сети.
⁃ Сложность логирования подобных доступов.


Ну окок, убедил! Как выглядит типичный флоу?
⁃ С помощью предустановленного CLI, десктопного(есть Mac и Win), или веб клиента юзер аутентифицируется в самом баундари через IdP(можно просто логин-пароль). Несколько версий назад они зарелизили OpenID Connect, с помощью которого можно аутентифицироваться через Microsoft Azure Active Directory, AWS Identity, Okta, Auth0, прочих подобных провайдеров. Понятно, что если в случае каких-то причин у сотрудника отозван доступ к IdP, потенциальный злоумышленник остановится на этом первом же шаге.
⁃ Юзер теперь может посмотреть какие таргеты ему доступны: куда он может приконнектиться
⁃ Инициирует boundary connect к нужному таргету
⁃ Проходит RBAC, система проверяет, что у него есть и какие права на этот таргет
⁃ Устанавливается соединение, которое по-факту проксируется к желаемому таргету, через компонент баундари, который в их терминологии называется worker.

Это серебряная пуля, срочно в родмап инфра-тиме!
Я бы не спешил! Ключики для коннекта к ssh нужно все еще раскладывать самому, например! Но, если у вас уже те же RDS работают в связке с vault, то коннект для Postgres target будет сразу с максимальной дозой магии. А также, чтобы таргеты обновлялись динамически нужно иметь консул в инфраструктуре. В общем, зависит от того насколько плотно вы уже подсели на хаши-продукты. Также отмечу, что документация пока скудненькая

Какие таргеты поддерживаются?
Из коробки поддерживаются ssh, http, Postgres, rdp. Обещают добавлять коробочных. А пока с помощью враппера boundary connect -exec можно заюзать что угодно через TCP.

RBAC полиси руками что-ли править?
Так и было до совсем недавнего времени, но солнцеликие из хашикорпа выкатили нам терраформ провайдер для управления всем этим добром.
https://registry.terraform.io/providers/hashicorp/boundary/latest

Хашикорп изобрели что-то совсем новое?
Неа! До них это делали Teleport, StrongDM, Pritunl Zero, и другие
Нашел неплохую табличку сравнения

Продолжим тему Security и сертификатов! Поговорим про DNS CAA(Certification Authority Authorization) .

Что это такое? Зачем нужно?
Это отдельный тип записи, в котором содержится информация о том какие центры сертификации могут выпускать SSL сертификаты для определенного доменного имени или субдомена.

Как выглядит типичный flow?
- Вы(или не вы) просите у центра сертификации(СА) выписать вам новый сертификат.
- СА проверяет CAA запись вашего домена, смотрит есть ли разрешение конкретно этому центру выписывать сертификат на этот домен, либо wildcard.
- Если разрешение есть, то СА идет далее по стандартному процессу.
- Если же, такого разрешения нет, то СА отправит вам письмо на мейл, который вы указали в теге iodef в своей записи. Об этом чуть ниже.

Хочу добавить себе CAA в DNS, как бы не ошибиться?
Формат достаточно простой и выглядит вот так

CAA <flag> <tag> <value>

Где:

- flag это так называемое битовое поле. Этот флаг влияет на то, что будет делать СА, если он не смог распарсить ваши теги. А также задуман для расширения функционала этих записей через такие флаги в будущем. Например, что-то типа CAA 128 future "value"
* 0 обозначает, что если СА не смог распознать, что вы засунули в поле tag, то может действовать по своему усмотрению.
* 1 значит, что СА должен прекратить процесс, если запись в теге не распознаваемая, либо не поддерживается этим CA.
Честно говоря, текущие флаги мягко говоря странные, наверное поэтому, я не нашел у реальных доменов что-то отличное от 0.

- tag. Тут задаются самые главные правила. В тег issue записываем СА, которому можно выписывать сертификаты для этого домена. Если выписываете wildcard-сертификаты, то используем тег issuewild. Ну, и в теге iodef указываете мейл, на который будут отправлены уведомления, в случае нарушения кем-то правил, которые указаны в вашей CAA записи.
- В value может быть разное, зависит от тега, заключается в кавычки.

Рассмотрим на примере dig cloudflare.com CAA +short:

0 issue "comodoca.com"
0 issue "digicert.com"
0 issue "letsencrypt.org"
0 issuewild "comodoca.com"
0 issuewild "digicert.com"
0 issuewild "letsencrypt.org"
0 iodef "mailto:tls-abuse@cloudflare.com"

Они разрешают выписывать сертификаты comodoca, digicert, letsencrypt. И одновременно, они разрешают выписывать wildcard-сертификаты этим же центрам сертификации. С mailto понятно думаю.

Как вы могли заметить, чтобы разрешить несколько СА, нужно создать индивидуальную запись для каждого из них.

А еще можно запретить выписывать любые сертификаты на поддомен:

nocerts.example.com CAA 0 issue ";"

или wildcard

CAA 0 issuewild ";"

Стоит упомянуть, что варианты одиночных сертификатов или wildcard зависит от ваших нужд в инфраструктуре. Кто-то выписывает на каждый сабдомен отдельный сертификат, а кто-то *.example.com. В первом случае вам нужно issue, во втором - issuewild, в обоих - и то и то.

После того как вы поняли как это работает можно и генератором воспользоваться https://sslmate.com/caa/

Что произойдет с уже имеющимися сертификатами при добавлении CAA записи?
Ничего! Это относится только к выпуску, перевыпуску, либо продлению сертификатов. В общем, в тот момент, когда вы обращаетесь к центру сертификации.

А браузер проверяет?
Нет, браузер в этом механизме никак не учавствует.

Кто поддерживает эти записи?
Не уверен, что это прям полный список https://sslmate.com/caa/support, но основные центры(Let’s Encrypt, Izenpe, Comodo, GoDaddy, HARICA, GDCA, Trustwave, SwissSign, Symantec, SHECA, CFCA, SSC, GlobalSign, Cisco, Buypass, DigiCert, Disig) будут проверять! Где-то попадалась цифра, что это 94% рынка компаний, через которые можно выписать сертификаты.

Так как более мелкие СА это по-сути ресселеры крупных, то считай для большинства будет работать.

Работая в компании, софт которой стоит на каждом 5-м маке в мире, волей-неволей придется столкнуться с CI/CD для macOS. Недавно я разбирался с Anka: MacOS Container-like Virtualization. Было бы интересно почитать что это такое и чем может быть полезно, если у вас в компании есть необходимость в автоматизации macOS билдов?

macOS-около-CI-CD
Мы все давно привыкли к докеру и его экосистеме. Сделал docker image, а дальше его хоть run, хоть exec, хоть что хочешь делай, хоть в tar.gz заверни - красота! Пару лет назад я делал небольшой воркшоп по докеру внутри компании, и коллеги связанные с разработкой под мак сказали "стоп! мы также хотим с макосью". Увы, ответ их не порадовал, и ситуация забылась, все продолжили собирать свои икскоды по старинке. Однако, чем дальше, тем сложнее скейлить любые CI/CD, которые надо запускать на macOS/iOS.

В чем проблема то? Купил mac mini, настроил ось, xcode и билди себе, и коллегам за печеньки в аренду!

А проблем в общем-то много: такой миник можно зашарить максимум с парой коллег с вашей команды, никакого параллелизма, один кто-то сделал изменения пакетов, версий - все сломалось, сиди разбирайся. А теперь представьте, если команд у вас 5(с потолка), и людей них по 10-15 в каждой, и таких миников тоже десяток?

Как-то люди же выживали то до 2021?

Перечислю самые стандартные способы выживания, причем это также будет справедливо даже к таким компаниям-монстрам как Shopify или Uber:

- Куча mac mini/pro + Chef/Puppet, позже Ansible. Все более-менее работает, пока не прилетает апдейт, меняет поведение каких-то внутренних команд и все поламалось, иди найди и запили в кукбук, плейбук, может твой PR примут быстро, недели за 3-4! C мажорными апгрейдами все ломалось еще масштабнее. Версии руби, пайтона зависимостей, и вот этот вот адок вокруг этого.
- Вручную настраивать каждый билд-агент, мак мини. Это утопия, треш и содомия. Хотя, на старте и для мелких команд может быть вполне себе.
- macOS агенты на крупных CI/CD платформы. Тут многие выдохнули и быстро туда переехали когда они появились и начали освоение рынка. Конечно же, CI/CD saas'ы у себя страдали также как и остальные, только помножьте еще на количество клиентов и их хотелок. У CircleCI одно время статус-борд по macOS агентам был чаще красным, чем зеленым, Github Actions до сих пор не могут предоставить клиентам BigSur после почти года официального релиза это версии в GA. Еще есть Azure Pipelines, GitlabCI(используют чужую платформу), Semaphoreci, TraviCI. У каждого свои особенности, но не сомневайтесь, что все они снимут с вас прилично $$$, за то, что вам не приходится в это залазить по локоть!
- VMware ESXi - дорого-богато, медленно, заморочки с лицензиями! Вы можете запускать гипервизор только на Apple hardware, что накладывает немало ограничений. Существуют какие-то "серые" патчи от энтузиастов, на ваш страх и риск, но они работают, и как минимум в наших краях их активно используют! Apple для своих внутренних ферм использовало VMware до 2015, потом они не договорились и контракты не продлились, но сам факт.
- Orka by MacStadium (Orchestration with Kubernetes on Apple). Долго этот рынок оставаться пустым не мог, и крупный хостинг-провайдер выкатил Орку. Это такой себе дикий микс из докера, макоси, квм, и какого-то модифицированного Linux. Соотвественно, можно использовать только на их железе и в их датацентрах. Выглядит поверхностно и правда круто, т.к. вы получаете по-сути тот же кубер, только внутри подов у вас макось! Однако и доступа ко всем компонентам конечно не получите. Сильно глубоко я еще туда не погружался, т.к. ~кровавый энтерпрайз~ демо дают всего на пару часов, дальше общайся с сейлзами. Помните я писал про GitlabCI выше? Так вот они под капотом юзают эту самую Orka
- Все более прозрачно с Veertu Anka, который построен поверх нативного Apple hypervisor. Их явно вдохновлял докер, поэтому тут есть реджистри для имеджей, run команда для запуска команд в уже запущенной вмке и всякое подобное. Тоже не бесплатное решение, цены закрытые.
- Xcode Cloud. Выпустили недавно, выглядит пока еще сыровато, да и не похоже на решение для больших команд. Будем наблюдать.

Обещал вам рассказать про Veertu Anka, но вышло такое себе длинное интро в тему 🙂 В следующем посте точно про нее!

Пока компилится много текста про Anka MacOS Container-like Virtualization распишу почему вчера анонсированный сторедж от CloudFlare - это 💣! Речь пойдет исключительно про передачу исходящих данных из Amazon S3 в Интернет, или от CDN в Интернет.

Как работает ценообразование очень популярной связки S3+CloudFront?

Вы кладете на S3 свои объекты, сверху настраиваете CloudFront и платите только за трафик от CDN к юзеру, и не платите ничего за трафик между S3<->CloudFront. Далее, в зависимости от "PriceClass" и региона, в котором у вас юзеры, вы будете платить от 0,085USD до 0,114USD за Гб. Если вы раздаете десятками или сотнями гигабайт, цены будут в конечном счете падать, но все равно будут внушительными.

Да ну нафик ваш CloudFront, у CloudFlare за 20 баксов раздавай - гигабайты не считай!

Думаю у многих такая мысль хоть раз, да проскакивала! Ведь CloudFlare не снимает с вас дополнительных денег, если вы раздали случайно лишних 10-20 терабайт. Однако сюрприз - с вас начнет снимать деньги AWS S3(или AWS EC2)! Причем довольно стабильно будет вам насчитывать 0,09USD за Гигабайт, и чуть ниже, например 0,085USD, если ваши объемы раздачи от 40Тб. А так как CloudFlare в глазах Амазона и есть "Интернет", то у вас сразу возникнет вопрос как бы нам теперь почаще кешировать на CloudFlare, чтобы реже бегать в S3. И вроде бы не такая и большая проблема накрутить побольше TTL, но когда у вас миллионы+ статики, разные проекты, то под каждый надо подумать как будет удобно и юзерам, и чтобы не попасть на деньги по S3.

И что же, никто с этим ничего не делал, просто заносили 💰💰💰 Безосу?

Думаю ребятам из CloudFlare надоело обьяснять AWS кастомерам, что они ничего не могут с этим поделать, и они создали Bandwidth Alliance https://www.cloudflare.com/bandwidth-alliance. Такой себе кружок провайдеров и хостингов, где трафик в сторону CloudFlare будет бесплатным, либо с дискаунтом(Azure, GCP).

Ну, думаю вы понимаете теперь, что хранилище от CloudFlare было лишь вопросом времени! Платить нужно будет только за место в их Cloudflare R2 Storage, и ничего за трафик.

P.S. Не забывайте, что в тарифных планах у CloudFlare Free/Pro на вас будут тестировать всякие кенери и любые даунтаймовые нововведения, а также могут и отключить, при аномальных пиках трафика. Поэтому, халява халявой, но мозг и совесть нужно иметь выбирая на каком плане вы будете жить.

macOS виртуализация с криповым именем. Anka. Часть 1

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

Если вы вдруг пропустили пост выше https://news.1rj.ru/str/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"! Однако в докеры/куберы можно будет запихнуть только реджистри и контроллер, и хоть за это спасибо! Представьте как вам надо было бы извращаться с сетевыми хранилищами на мак-миниках, чтобы хранить всю эту кучу разных имеджей под все случаи жизни. Оно выглядит еще немного в зачаточном состоянии, в плане манифестов, но, мучаться с Кубером это ж как раз наше, правда?) Не так страшно в общем.

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.