Иии, первый пост про 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 на вас будут тестировать всякие кенери и любые даунтаймовые нововведения, а также могут и отключить, при аномальных пиках трафика. Поэтому, халява халявой, но мозг и совесть нужно иметь выбирая на каком плане вы будете жить.