В конце концов, если мы верим, что apiserver + etcd - это надёжная связка, то замените apiserver на vault, и получится такая же надёжная vault + etcd
Не выдерживает критики. Хотя бы размер кодовой базы и функционал. Если в апи сервере там условно тупо клиент етсд + пара доп валидаций, кэш, то в вольт в полный рост куча разных модулей, алгоритмов шифрования и прочего.
Например etcd тоже надо бэкапить. Если не хочешь собирать исчезнувший по какой-то причине кластер из сотен и тысяч репозиториев, а хочешь собрать (хотя бы бОльшую часть) из одного места.
Это омерзительная идея. Бекап етсд не решает ничего, вот прям решительно. Зато есть проблемы бекапов всех распределенных систем. Я помню как мы на сссссерьезных щах на конференции редхат с представителями компаний вроде veeam обсуждали реальную необходимость бекапов Кафки, эластика и прочего. Ну, да, возможность восстановиться необходима, но она далеко не всегда реализуется именно тупым бекапом. Скажем, для Кафки вероятнее всего будет продуктивнее использование mirrormaker, для базы типа постгреса - механизма архивации WAL’ов и прочее. Касательно етсд - почему я не верю, потому что
Надежнее использовать GitOps подход, когда ты можешь налить кластер с нуля и получить рабочую систему (ну, мож кроме персистентных данных)
В таких решительно динамических системах как кубернетес, состояние етсд протухает буквально за минуту. Те же pvc. Заказали, оно подвязалось в етсд. Если восстановились - у нас появятся вольюмы, которые ничейные (не в кластере, а в облаке). Удачи разбираться. Или тот же серт менеджер - сертификаты получил, в етсд положил. А пять минут назад их там не было. Все это требует рационального подхода и точно не создания дополнительной ненужной работы.
Вы абсолютно правы, но я согласен и с оратором выше - практически никакого смысла в днс без возможности управлять записями нет. Пример с гостиницей отличный. Ну, слава богу, можно отдать ns на клаудфларь и не думать теперь
Самоподписные сертификаты это геморой с деплойментом root-сертификата на клиенты.
Будто пакет ca-certificates не надо обновлять. Или может попробуете зайти с ХР в интернет сейчас ? Или со старого андроида. Очень удивитесь. Просто в ОС массового назначения корни попадают через обновления, а жизненный цикл ОС - лет 5. Так что - шило на мыло, можно и со своими корнями поколдовать. С ними другая проблема - что у каждого вонючего приложения может быть свое хранилище, при чем обоснованность этого не очень высокая. Безопасность ? Ну, смешно.
Уточню, что испанцы такое пробили и их FNMT добавили в Корни. А чем минцифры хуже ? Ну, только честно, без этого, что рф коррумпированная страна, Путин ест детей и прочую чушь. Почему одним государствам позволен, а другим нет ? Я лично не вижу разницы.
К тому же сейчас получение сертификата зачастую связано не с какой-то защитой сайта, сколько с пессимизацией сайта без https со стороны поисковых систем.
Будем честны - нет, не только поэтому, а еще и потому что владелец сайта (ресурса) желает, чтобы пользователь ресурса видел его именно так, как владелец задумал. А еще чтобы никто не мог вмешаться в трафик по дороге.
Пока нет монополии на выпуск сертификатов - все ок, ну, уйдешь к cloudflare (он закрывает сайты своим сертификатом), или в Амазон (то же самое), или еще куда.
В залог твою жизнь, почку и ребенка. Оказался сквоттером - все обнуляется. Беспроигрышный бизнес для регистратора ) больше власти )
В целом это же все контролируется отчасти регистраторами доменов. Именно они отвечают, но учитывая, что регистраторы в разных странах, то и к доменам разные требования. Где-то паспорт требуют и верификацию, а где-то просто можно купить доменов пачку вообще без ничего. Вот УЦ отчасти должны были решить эту проблему верификации владельца ресурса, но как видим - нет. И судя по всему ничего в ближайшие 20 лет не поменяется на этом рынке…
Любимая тема про поваляшки волта. Я например не очень улавливаю, в чем разница в поваляшках, когда
а если все таки подумать, а не передергивать ?
Почему волт лежит какой-то по особенному, не как kubeapi или etcd? Etcd вообще максимально похожий на волт с точки зрения HA - работает только один узел.
Как минимум тем, что отказ етсд не ведет к немедленной недоступности приложений, хоть и критично. А еще тем, что етсд проще в разы. И, конечно, разработчики кубера подумали десять раз, когда проектировали систему. Отказ одной части не блокирует работы остальных - кроме отказа етсд/всех апи серверов. А волт - монолит, который еще и бекапить надо. Развивать тему можно долго. Но разница есть.
Если мы говорим, что волт это ещё одна дополнительная точка отказа, то тут соглашусь
Скучное передергивание без позитивного заряда (что делать-то?)
Ну и про /proc/pid/environment Так запретите доступ к этому интерфейсу ОС. Это же не настоящие файлы. Придется правда ядро немного патчнуть, но что нас остановит?
Итого: мы не хотели хранить секреты в secrets kubernetes, и вместо этого использовали 2 других инструмента, чтобы ... в итоге хранить секреты в secrets kubernetes
тут сознательно упускается момент, что
абсолютно безопасную систему не построить
следствие - надо идти на компромиссы
аудит вольта - уже явно лучше аудита секретов в кубере
и если секрет утечет - его можно будет, условно, поменять "одной кнопкой" везде, а не бегать по 100500 секретов в 100500 кластеров, лихорадочно пытаясь понять - а что надо менять-то!
ну, и я ниже писал - надо от статических секретов уходить. Те же сертификаты с коротким сроком жизни (а vault умеет быть pki) или секреты одноразки - уже сильно сокращают поверхность атаки для злоумышленника. И тут сильно могут помочь средства раннего обнаружения атак. Очевидно, что если кто-то лазит по ФС контейнера с запросами вида `cat /proc/<pid>/environ` - это уже аномалия и нас уже ломают. А если секрет лежит в файле - ну, пойди отличи - легитимная ли это деятельность или нет.
1) Vault здесь используется как единый источник хранения секретов, таким образом нам не нужны секреты хранить в репозиториях (пусть даже с шифрованием в виде инструментов SOPS, helm secrets, etc...) - ведь если мы говорим о подходе IaC, что для нас немаловажно, то хранить даже секреты где-то нужно и чтобы это "где-то" - было единственным источником правды.
а это проблема, потому что автоматически влетаем в следующие вопросы
как мы будем вольт бекапить? Если нет другого золотого источника правды - ну, вольт им становится, значит нам нужно подходить к нему как к питомцу. Лелеять, лечить.
Vault автоматом становится критическим узлом на пути всего - деплоя, запуска и прочего. Вольт играет в поваляшки - инфраструктура начинает напоминать дорогущий чемодан без ручки. Следовательно, автоматом требования к HA, возможности обслуживать Highload etc. При чем на ровном месте. Оно надо?
все процессы доставки секретов асинхронные. То есть это означает определенный порядок при релизе (сначала добавляем секрет, потом проверяем, что он доехал, потом уже обновляем приложение), что уже гемор. Как же просто было с sops! Тупо закидал манифестов и подождал. А еще означает, что нужно все покрывать мониторингом. А это уже веселее - потому что весь опенсурс, откровенно скажу, сделан из пофигизма, говна и палок. Даже в таких известных и давно используемых компонентах вроде cert-manager есть куча проблем, которые че-то авторы не торопятся исправлять. И шанс налететь на корнес кейсы тем увеличивается, чем больше разнородных компонентов в инфре. Вот - уже из статьи ясно - одним вольтом мы не обойдемся, нам еще ESO надо зашлифовать, потом kyverno какую-нибудь еще и так далее по перечню. Получается, как лего. Только в отличии от лего - тут кубики разномастные и не очень подходят друг к другу ))) Как там договорится - доработать напильником
Я практически уверен, что тезис
Не выдерживает критики. Хотя бы размер кодовой базы и функционал. Если в апи сервере там условно тупо клиент етсд + пара доп валидаций, кэш, то в вольт в полный рост куча разных модулей, алгоритмов шифрования и прочего.
Это омерзительная идея. Бекап етсд не решает ничего, вот прям решительно. Зато есть проблемы бекапов всех распределенных систем. Я помню как мы на сссссерьезных щах на конференции редхат с представителями компаний вроде veeam обсуждали реальную необходимость бекапов Кафки, эластика и прочего. Ну, да, возможность восстановиться необходима, но она далеко не всегда реализуется именно тупым бекапом. Скажем, для Кафки вероятнее всего будет продуктивнее использование mirrormaker, для базы типа постгреса - механизма архивации WAL’ов и прочее. Касательно етсд - почему я не верю, потому что
Надежнее использовать GitOps подход, когда ты можешь налить кластер с нуля и получить рабочую систему (ну, мож кроме персистентных данных)
В таких решительно динамических системах как кубернетес, состояние етсд протухает буквально за минуту. Те же pvc. Заказали, оно подвязалось в етсд. Если восстановились - у нас появятся вольюмы, которые ничейные (не в кластере, а в облаке). Удачи разбираться. Или тот же серт менеджер - сертификаты получил, в етсд положил. А пять минут назад их там не было. Все это требует рационального подхода и точно не создания дополнительной ненужной работы.
Вы абсолютно правы, но я согласен и с оратором выше - практически никакого смысла в днс без возможности управлять записями нет. Пример с гостиницей отличный. Ну, слава богу, можно отдать ns на клаудфларь и не думать теперь
Будто пакет ca-certificates не надо обновлять. Или может попробуете зайти с ХР в интернет сейчас ? Или со старого андроида. Очень удивитесь. Просто в ОС массового назначения корни попадают через обновления, а жизненный цикл ОС - лет 5. Так что - шило на мыло, можно и со своими корнями поколдовать. С ними другая проблема - что у каждого вонючего приложения может быть свое хранилище, при чем обоснованность этого не очень высокая. Безопасность ? Ну, смешно.
Не костыль ни разу.
Уточню, что испанцы такое пробили и их FNMT добавили в Корни. А чем минцифры хуже ? Ну, только честно, без этого, что рф коррумпированная страна, Путин ест детей и прочую чушь. Почему одним государствам позволен, а другим нет ? Я лично не вижу разницы.
Делайте сложные системы, которые рассчитаны на обслуживание без остановки. HA и HL - надеюсь, не пустой звук ?
Коммерческие УЦ будут только рады снизить этот интервал.
Будем честны - нет, не только поэтому, а еще и потому что владелец сайта (ресурса) желает, чтобы пользователь ресурса видел его именно так, как владелец задумал. А еще чтобы никто не мог вмешаться в трафик по дороге.
Че, серьезно ?
Пока нет монополии на выпуск сертификатов - все ок, ну, уйдешь к cloudflare (он закрывает сайты своим сертификатом), или в Амазон (то же самое), или еще куда.
Но не требование иметь дигисерт !
В залог твою жизнь, почку и ребенка. Оказался сквоттером - все обнуляется. Беспроигрышный бизнес для регистратора ) больше власти )
В целом это же все контролируется отчасти регистраторами доменов. Именно они отвечают, но учитывая, что регистраторы в разных странах, то и к доменам разные требования. Где-то паспорт требуют и верификацию, а где-то просто можно купить доменов пачку вообще без ничего. Вот УЦ отчасти должны были решить эту проблему верификации владельца ресурса, но как видим - нет. И судя по всему ничего в ближайшие 20 лет не поменяется на этом рынке…
а если все таки подумать, а не передергивать ?
Как минимум тем, что отказ етсд не ведет к немедленной недоступности приложений, хоть и критично. А еще тем, что етсд проще в разы. И, конечно, разработчики кубера подумали десять раз, когда проектировали систему. Отказ одной части не блокирует работы остальных - кроме отказа етсд/всех апи серверов. А волт - монолит, который еще и бекапить надо. Развивать тему можно долго. Но разница есть.
Скучное передергивание без позитивного заряда (что делать-то?)
Еще скучнее…
Я думаю, что это не платная пропаганда, а бесплатная. Зато эффективная )
Окстись, бро, в LE очень даже можно вайлдкард. Но… как я выше писал. Только через dns challenge.
это пока
не нашли фатальный недостаток в алгоритме генерации токенов (дело времени)
или пока не изобрели квантовые компьютеры, которые все шифры прошлого и современности, ломают на раз два
поначалу кажется, что есть, но на самом деле его нет )
тут сознательно упускается момент, что
абсолютно безопасную систему не построить
следствие - надо идти на компромиссы
аудит вольта - уже явно лучше аудита секретов в кубере
и если секрет утечет - его можно будет, условно, поменять "одной кнопкой" везде, а не бегать по 100500 секретов в 100500 кластеров, лихорадочно пытаясь понять - а что надо менять-то!
ну, и я ниже писал - надо от статических секретов уходить. Те же сертификаты с коротким сроком жизни (а vault умеет быть pki) или секреты одноразки - уже сильно сокращают поверхность атаки для злоумышленника. И тут сильно могут помочь средства раннего обнаружения атак. Очевидно, что если кто-то лазит по ФС контейнера с запросами вида `cat /proc/<pid>/environ` - это уже аномалия и нас уже ломают. А если секрет лежит в файле - ну, пойди отличи - легитимная ли это деятельность или нет.
а это проблема, потому что автоматически влетаем в следующие вопросы
как мы будем вольт бекапить? Если нет другого золотого источника правды - ну, вольт им становится, значит нам нужно подходить к нему как к питомцу. Лелеять, лечить.
Vault автоматом становится критическим узлом на пути всего - деплоя, запуска и прочего. Вольт играет в поваляшки - инфраструктура начинает напоминать дорогущий чемодан без ручки. Следовательно, автоматом требования к HA, возможности обслуживать Highload etc. При чем на ровном месте. Оно надо?
все процессы доставки секретов асинхронные. То есть это означает определенный порядок при релизе (сначала добавляем секрет, потом проверяем, что он доехал, потом уже обновляем приложение), что уже гемор. Как же просто было с sops! Тупо закидал манифестов и подождал. А еще означает, что нужно все покрывать мониторингом. А это уже веселее - потому что весь опенсурс, откровенно скажу, сделан из пофигизма, говна и палок. Даже в таких известных и давно используемых компонентах вроде cert-manager есть куча проблем, которые че-то авторы не торопятся исправлять. И шанс налететь на корнес кейсы тем увеличивается, чем больше разнородных компонентов в инфре. Вот - уже из статьи ясно - одним вольтом мы не обойдемся, нам еще ESO надо зашлифовать, потом kyverno какую-нибудь еще и так далее по перечню. Получается, как лего. Только в отличии от лего - тут кубики разномастные и не очень подходят друг к другу ))) Как там договорится - доработать напильником