Иии, первый пост про Kubernetes операторы.
Что это?
Упрощая - это приложение, которое живет в отдельном поде, может нескольких, обычный Deployment с ReplicaSet. Отвечает за свой(как правило) неймспейс, общается с Kubernetes API, чтобы автоматизировать какие-то действия, которые нельзя заавтоматизировать стандартными средствами.
Зачем это?
Довольно просто представить себе Stateless приложение в кубере, a вот со StateFull все гораздо сложнее. Самый подходящий пример - это базы данных. Мы поместили в кубер MySQL, мастер-слейв реплика, все отлично. Как делать бекапы, менять конфигурацию? Как переподнять реплику, после того как нода с ней(репликой) отвалилась? Вот тут и приходят на помощь операторы, через которые можно автоматизировать разные флоу управления кластером MySQL, Elastic, Redis, etc.
Зачем это?
Делать какие-то запросы к внешним сервисам. Например, оператор, который следит за появлением новых ингресс ресурсов, и добавляет их URL/Hostname в Pingdom, UptimeRobot, 24x7, прочие системы, для внешних чеков.
Есть же хельм, зачем вот это вот все?
Helm - это просто пакетный менеджер, и удобный шаблонизатор, чтобы вы не клепали(хотя все равно клепаем) миллионы ямл файлов для деплоймента.
Где найти готовые операторы?
На https://operatorhub.io/, можно обнаружить, что автоматизируют через операторы не только кластеры баз данных. Но, имхо, это самый лучший и довольно сложный кейс, который вписывается во всю эту концепцию.
Что это?
Упрощая - это приложение, которое живет в отдельном поде, может нескольких, обычный Deployment с ReplicaSet. Отвечает за свой(как правило) неймспейс, общается с Kubernetes API, чтобы автоматизировать какие-то действия, которые нельзя заавтоматизировать стандартными средствами.
Зачем это?
Довольно просто представить себе Stateless приложение в кубере, a вот со StateFull все гораздо сложнее. Самый подходящий пример - это базы данных. Мы поместили в кубер MySQL, мастер-слейв реплика, все отлично. Как делать бекапы, менять конфигурацию? Как переподнять реплику, после того как нода с ней(репликой) отвалилась? Вот тут и приходят на помощь операторы, через которые можно автоматизировать разные флоу управления кластером MySQL, Elastic, Redis, etc.
Зачем это?
Делать какие-то запросы к внешним сервисам. Например, оператор, который следит за появлением новых ингресс ресурсов, и добавляет их URL/Hostname в Pingdom, UptimeRobot, 24x7, прочие системы, для внешних чеков.
Есть же хельм, зачем вот это вот все?
Helm - это просто пакетный менеджер, и удобный шаблонизатор, чтобы вы не клепали(хотя все равно клепаем) миллионы ямл файлов для деплоймента.
Где найти готовые операторы?
На https://operatorhub.io/, можно обнаружить, что автоматизируют через операторы не только кластеры баз данных. Но, имхо, это самый лучший и довольно сложный кейс, который вписывается во всю эту концепцию.
👍1
Certificate Transparency.
Что это?
Если упростить, то это система мониторинга выпущенных SSL сертификатов по любым доменам!
Зачем это?
Ничто в нашем мире не идеально, и тем более безопасно! Центры сертификации по ошибке выдавали сертификаты не настоящим владельцам домена. Или взлом шведского центра сертификации DigiNotar позволил мошенникам выпустить тонны сертификатов, в том числе facebook и google, позволив получить данные множества пользователей. Таких историй довольно много.
В конце концов гугл придумал каким образом можно хотя бы пост-фактум понять, что что-то пошло не так и принять меры. Они предложили центрам сертификации присылать информацию о выпущенных ими сертификатах. И мониторя такие логи, вы можете узнать, что кто-то выписал сертификат на ваш домен без вас.
Где логи, бегу смотреть?
Например тут https://crt.sh/?q=i.ua
а тут можно не только посмотреть, но и подписаться на обновления https://developers.facebook.com/tools/ct/search/
Что это?
Если упростить, то это система мониторинга выпущенных SSL сертификатов по любым доменам!
Зачем это?
Ничто в нашем мире не идеально, и тем более безопасно! Центры сертификации по ошибке выдавали сертификаты не настоящим владельцам домена. Или взлом шведского центра сертификации DigiNotar позволил мошенникам выпустить тонны сертификатов, в том числе facebook и google, позволив получить данные множества пользователей. Таких историй довольно много.
В конце концов гугл придумал каким образом можно хотя бы пост-фактум понять, что что-то пошло не так и принять меры. Они предложили центрам сертификации присылать информацию о выпущенных ими сертификатах. И мониторя такие логи, вы можете узнать, что кто-то выписал сертификат на ваш домен без вас.
Где логи, бегу смотреть?
Например тут https://crt.sh/?q=i.ua
а тут можно не только посмотреть, но и подписаться на обновления https://developers.facebook.com/tools/ct/search/
crt.sh
crt.sh | i.ua
Free CT Log Certificate Search Tool from Sectigo (formerly Comodo CA)
В следующем посте разберемся что такое Boundary от Hashicorp, и где его применить.
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, потенциальный злоумышленник остановится на этом первом же шаге.
⁃ Юзер теперь может посмотреть какие таргеты ему доступны: куда он может приконнектиться
⁃ Инициирует
⁃ Проходит RBAC, система проверяет, что у него есть и какие права на этот таргет
⁃ Устанавливается соединение, которое по-факту проксируется к желаемому таргету, через компонент баундари, который в их терминологии называется worker.
Это серебряная пуля, срочно в родмап инфра-тиме!
Я бы не спешил! Ключики для коннекта к ssh нужно все еще раскладывать самому, например! Но, если у вас уже те же RDS работают в связке с vault, то коннект для Postgres target будет сразу с максимальной дозой магии. А также, чтобы таргеты обновлялись динамически нужно иметь консул в инфраструктуре. В общем, зависит от того насколько плотно вы уже подсели на хаши-продукты. Также отмечу, что документация пока скудненькая
Какие таргеты поддерживаются?
Из коробки поддерживаются ssh, http, Postgres, rdp. Обещают добавлять коробочных. А пока с помощью враппера
RBAC полиси руками что-ли править?
Так и было до совсем недавнего времени, но солнцеликие из хашикорпа выкатили нам терраформ провайдер для управления всем этим добром.
https://registry.terraform.io/providers/hashicorp/boundary/latest
Хашикорп изобрели что-то совсем новое?
Неа! До них это делали Teleport, StrongDM, Pritunl Zero, и другие
Нашел неплохую табличку сравнения
Что это?
Относительно новая опен-сорс тула от 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, и другие
Нашел неплохую табличку сравнения
👍1
Продолжим тему 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 может быть разное, зависит от тега, заключается в кавычки.
Рассмотрим на примере
Они разрешают выписывать сертификаты comodoca, digicert, letsencrypt. И одновременно, они разрешают выписывать wildcard-сертификаты этим же центрам сертификации. С mailto понятно думаю.
Как вы могли заметить, чтобы разрешить несколько СА, нужно создать индивидуальную запись для каждого из них.
А еще можно запретить выписывать любые сертификаты на поддомен:
или wildcard
Стоит упомянуть, что варианты одиночных сертификатов или 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% рынка компаний, через которые можно выписать сертификаты.
Так как более мелкие СА это по-сути ресселеры крупных, то считай для большинства будет работать.
Что это такое? Зачем нужно?
Это отдельный тип записи, в котором содержится информация о том какие центры сертификации могут выпускать 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% рынка компаний, через которые можно выписать сертификаты.
Так как более мелкие СА это по-сути ресселеры крупных, то считай для большинства будет работать.
👍1
DevOps from 🇺🇦 via @like
Работая в компании, софт которой стоит на каждом 5-м маке в мире, волей-неволей придется столкнуться с CI/CD для macOS. Недавно я разбирался с Anka: MacOS Container-like Virtualization. Было бы интересно почитать что это такое и чем может быть полезно, если у вас в компании есть необходимость в автоматизации macOS билдов?