Пылесос строит карту, чтобы по ней в дальнейшем двигаться, и чтобы в приложении по управлению пылесосом ее можно было использовать. Например дать команду "уборка этой зоны" - и ткнуть в комнату на карте.
Как этот функционал должен работать без передачи карты на сервер? Делать канал p2p между пылесосом и приложением в телефоне? Это не будет работать асинхронно, что приведет к негативному клиентскому опыту.
Например Xiaomi эти карты не только создаёт и отправляет на сервер, но ещё и бэкапит. Если вы двигаете мебель и пылесос что-то там не то найдет, то можно откатить карту на предыдущую. А можно загрузить ее в другой пылесос, и тот не будет долбиться об стены, а сразу будет следовать заданным на карте правилам.
Такое себе расследование, исследователь обнаружил очевидное.
Все любят волт и тераформ. Но в описанной схеме не очень удачно то, что имея возможность что-то сделать в гите - получаешь возможность вскрыть волт. Или можешь внедриться на раннер - можешь вскрыть волт.
Во-первых, соглашусь, что вариант, когда политики волта хранятся в гите - абсолютно правильный. Но подгружать их волт должен самостоятельно, проверяя подписи коммитов. Несколько подписей поставить на один коммит гит не дает, но есть обходные решения. Это можно реализовать например через плагин. И в этот момент понимаешь, что затащить в плагин opentofu с провайдером волта - это оверкилл. Мы в итоге храним в git обычные json волтовые или hcl, без всякого терраформа.
Крайний случай - это когда политики в волт пушит какой-то конкретный человек, который и так имеет доступ изменять политики. Но не раннер, не джоба CI и т.д. Это сильно сужает поверхность потенциальной атаки.
Во-вторых, не совсем понятно зачем хранить сами секреты в гите, если они у вас хранятся в волте. Да еще sops свеху прикручен. Волт вообще-то для того, чтобы секреты НЕ хранить нигде кроме волта, да еще извлекать их точечно и именно в тот момент, когда это необходимо. Версионирование секретов волт поддерживает, историю изменений тоже видно. Бэкапы делать - да проще некуда, можно их потом хоть распечатывать в base64, или в паблик выкладывать, это безопасно. В вашем же случае волт - это не система хранения секретов с политиками доступа, а перевалочный пункт по доставке секретов в кубер. И если это действительно то, для чего используется волт, то тут можно было остановиться например на helm-secrets. Получилось бы примерно тоже самое, но без дополнительной машинерии.
Разработчики рассчитывают на зарплату здесь и сейчас. Может быть и стыдно за продукт, но не за саму работу. Это честная работа, не хуже чем работа судьи, который понимает бредовость какой-то конкретной ситуации, но должен руководствоваться не здравым смыслом, а законом.
Менеджеры рассчитывают на лоббирование со стороны государства - заблокируют (или сильно усложнят использование) телеграмм, ватсап и т.д., и критическая масса людей перетечет в Макс просто потому что он работает. И в итоге Макс будет у всех, но может быть кто-то заведет для него отдельный телефон с выломанной камерой, микрофоном и антенной gps.
Если не передёргивать, то никакого веселья. Я думаю, мы тут все немного передёргиваем, чтобы не было скучнее, а было веселее.
А по сути:
отказ етсд не ведет к немедленной недоступности приложений
Все верно. И отказ волта тоже не ведёт
Отказ одной части не блокирует работы остальных
Отказ волта не блокирует работы csi cni dns kubeapi
который еще и бекапить надо
Это же не проблема. Так или иначе все бэкапить надо, в каком-то виде. Ну кроме наверное аппенд-онли блокчейна, который одновременно неизменяемый и распределенный. Например etcd тоже надо бэкапить. Если не хочешь собирать исчезнувший по какой-то причине кластер из сотен и тысяч репозиториев, а хочешь собрать (хотя бы бОльшую часть) из одного места.
а если все таки подумать
Я не считаю что волт сложный и ненадежный, и это повод от него отказаться, или опасаться использовать. С моей точки зрения волт и etcd - идентичныес точки зрения HA по архитектуре штуки. И может быть даже лучше (если вспомнить энтерпрайзные фичи вроде perfomance replica / dr replica). Только в волте больше возможностей по управлению доступом к ключам, больше способов аутентификации , и шифрованная хранила по умолчанию. По производительности конечно волт в сравнении с etcd проигрывает, но это и понятно - там на порядок больше логики накручено по валилации запроса. Но 10к rps на чтение - вполне держит. И для секретов этого как правило более чем достаточно.
В конце концов, если мы верим, что apiserver + etcd - это надёжная связка, то замените apiserver на vault, и получится такая же надёжная vault + etcd. Просто с другим функционалом. Если кому-то этот функционал не нужен, ну чтож, так бывает. Это как пользоваться postgresql и говорить, что kafka сложная и ещё она ломается, поэтому никаких кафок в проекте быть не должно, и для можно/нужно использовать надёжный проверенный Postgres, он простой и не ломается (хаха, нет)
Любимая тема про поваляшки волта. Я например не очень улавливаю, в чем разница в поваляшках, когда
CSI не может подключить диск и приложение не стартует
Секрет из волта не может извлечься
Кубконтроллер лежит и не создаёт поды
Кубапи лежит и кубконтроллер не знает, что нужно создавать поды
Etcd лежит и непонятно, апиха не работает, поды не создаются
Ингресс лежит, и внешний трафик никуда не роутится
CNI лежит и кубосервисы не работают
Кубднс лежит сервисы не резолвятся
Почему волт лежит какой-то по особенному, не как kubeapi или etcd? Etcd вообще максимально похожий на волт с точки зрения HA - работает только один узел.
Если мы говорим про неправильную конфигурацию vault, так давайте тогда делать неправильную конфигурацию etcd. Что? Не конфигурите etcd по 5 раз на дню? А волт конфигурите? А почему?
Если мы говорим, что волт это ещё одна дополнительная точка отказа, то тут соглашусь. Но тогда давайте будем последовательны в наших опасениях и не будем ходить в сервисы по именам (вдруг днс лежит), не подключать диски (вдруг csi лежит), и хранить конфигурации в oci образе (вдруг кубапи лежит и конфигмапу не забрать). И лучше создавать статик поды через файлы, а то вдруг заклинит API и поды из деплоймента не создадутся. Это максимально надёжно.
Кстати, у инжектора есть режим "не смог извлечь секрет - все равно запусти под". Довольно спорный вариант, но закрывает вопрос "пусть приложение хоть как-то запустится без секрета и может быть оно будет работать"
Ну и про /proc/pid/environment Так запретите доступ к этому интерфейсу ОС. Это же не настоящие файлы. Придется правда ядро немного патчнуть, но что нас остановит?
Добавлю, что сертификат LE ничего толком не удостоверяет.
Только то, что в какой-то момент времени доменное имя указывало на IP адрес, при обращении к которому со стороны сервера LE кто-то отдал верный код.
То есть вы можете даже владеть доменом, но где-то по дороге трафик могут отвернуть (осознанно, или из-за ошибки в bgp) и кто-то другой получит сертификат на ваш домен.
Сертификат LE конечно лучше, чем ничего, но это не очень серьезная гарантия.
Стоимость должна быть такая, чтобы у условного владельца (или владельцев) центра сертификации не появлялось желание сделать фейковый сертификат банка, за раз поднять несколько сотен миллионов баксов и свалить в закат в страну без экстрадиции. И чтобы денег хватало обеспечить безопасность процессов и инфраструктуры так, чтобы рандомные сотрудники не могли такое провернуть. И тут стоимость сертификата получится наверное уже не 1$ за штуку.
А как примерно мультипликациируется потребление памяти в зависимости от размера уже сгенерированного текста?
Например, один том "Войны и мир" около 700 тысяч символов, или 700 килобайт. Так что сама книга в памяти уложится без проблем, если это не i8086 с 640кб памяти.
Можно посмотреть в сторону sops, или helm-secrets. Или werf secrets.
Основная задача - пространственно разделить зашифрованные данные и ключ расшифровывания. И производить расшифровывание максимально близко к моменту использования секрета.
В случае с werf или helm-secrets "использование" секрета - это установка helm-чарта в кластер kubernetes.
Если пользователь напрямую не имеет доступ в kubernetes и не выполняет развертывание, а оно выполняется в системе CI
Сам kubernetes мы можем считать "черным ящиком", доступ к которому есть только из системы CI
То в этом случае хранение зашифрованных секретов в git условно можно считать безопасным. Потому что ключ расшифровывания не находится вместе с зашифрованными данными.
Но в этом случае атаку с целью угона секретов можно проводить где-то на уровне CI системы. А в самом Kubernetes секреты вообще не будут зашифрованные
А что насчет аудита? При доставке секретов их обычно не меняют конечно, а читают. Но в принципе аудит этих действий выглядит похожим образом, только операции разные - update или read. В докладе затрагивались вопросы аудита. И рассматривались методы доставки, при которых аудит будет "нормальный", а при которых - не очень. Не знаю как тут ссылку на раздел вставить, но можно найти в статье, нажав Control+F и набрав "аудит"
Информация "кто-когда.." в аудит-логах - есть. И в Vault, и в Stronghold. Время-дата, информация об субъекте и об объекте. Состав запроса в API, состав ответа API.
С "зачем" тут конечно сложнее. Система не знает "зачем" меняют секрет, можно только в метадате это указывать. Но насколько тут можно доверять user-input вопрос открытый.
Если коротко, то нет операции "ищем человека и запускаем пайп"
Если длинно, то давайте рассмотрим пример:
У вас 10 (100) приложений с какими-то своим циклом разработки.
Для смены условного пароля через гит нужно:
Сгенерировать пароль или пароли
Для каждого из десятка приложений внести изменения в гит. Если пароль в гит шифрованный, то перед этим зашифровать. Если шифрованный разными ключами, то зашифровать разными.
Для каждого из приложений определиться, какую версию приложения можно выкатывать. Для этого определить какая версия выкачена сейчас.
Конечно нужно иметь доступы во все эти гит репы, и иметь права на запуск релизных пайплайнов
В случае с секретом в волте нужно ротейтнуть необходимый секрет или секреты. Предполагается, что если приложение при неподходящем/истекшем секрете не может работать, то оно или само завершится с ошибкой, или по лайвнес-пробе. Поэтому приложение так или иначе автоматически перезапустится и на старте получит уже новый секрет. Конечно, если мы эти секреты не деплоим пайплайном, а, как рассказано в докладе, доставляем в контейнер на старте приложения.
То есть права нужны только на запуск ротации секрета, а не в 10-100 репозиториев и после этого запуск 10-100 развертываний. Причем ротация сама по себе процедура безболезненная и безопасная, запустивший ее в процессе сам не получает доступ к секретам. Поэтому доступ к запуску ротации можно дать бОльшему кругу лиц, или вообще проводить авторотации. Или использовать динамические секреты.
И немаловажно, что не нужно выяснять, какую версию приложения надо деплоить. Она останется та же, что и была, изменится только env с секретом.
Правильно ли я понимаю, что дедупликация данных происходит на уровне хранилки? Плюс к этому ещё какой-то аналог copy-on-write.
Например, в случае с упомянутой базой Postgres на 27ТБ, можно "накликать в консоли" 10 реплик, при этом реплики появятся практически мгновенно, так как физического копирования данных 9 раз по 27ТБ не происходит. И при этом места на хранилке все это будет занимать все ещё около 27ТБ, а не 270ТБ?
Сбер вообще интересный. Он действительно продлил срок действия Visa/MasterCard, но только для физических карт. То есть виртуальная карта Visa Digital работать перестала. И что-то сделать с этим было невозможно, ну кроме перевыпуска, на других условиях, ну и конечно само собой новая карта была бы не Visa, а Мир.
Но примерно через 2 года эта карта с истекшим сроком действия вдруг продлилась и платежи по ней стали проходить, без каких либо действий с моей стороны.
Второе интересное замечание. Хотя срок действия карты был истекший и платежи по ней через интернет не проходили, но подключенный автоплатеж работал безотказно все это время. То есть новые автоплатежи не подключались, но подключенные ранее - списывались.
В общем я не очень доверяю Сберу. Даже простые вещи работают крайне нелогично, необъяснимо, и ещё условия меняются в одностороннем порядке. На карте у меня 1000р и подключен автоплатеж на 60р. Поэтому рассматриваю ее просто как полигон, посмотреть что ещё Сбер учудит.
Получилась практически новая база данных с поддержкой репликации. Данные можно безопасно и надёжно хранить прямо в буфере обмена. Сам буфер обмена поддерживает тёмную тему, что является одним из его основных преимуществ.
Я бы добавил: а вот если бы начали использовать эрланг, то до сих пор бы были в процессе попыток начать использовать эрланг. А бухгалтерию вели на бумажке.
Плюс "убогих go и Kubernetes" наверное в том, что можно взять и уже завтра получить что-то более менее работающее и расширяемое. Не такое может красивое, зато завтра. Потому что послезавтра у это будет уже не нужно, а нужно будет что-то другое.
Новосибирский Новотелеком (куплен ДОМ ру лет 7 назад) поднимает стоимость тарифа ежегодно. Для некоторых тарифов за 7 лет стоимости выросла раза в 2, для некоторых в 6 раз.
Был такой тариф "для пенсионеров", назывался Социальный. 512кбит за 30р в месяц. Появился он когда сотовые операторы повально безлимиты предлагали.
Так вот, этот тариф сначала стоил 30р, потом 40р, далее 60р, 100р. Сейчас уже 190р. Цену не забывают индексировать. Но скорость так и осталась 512кбит, как 10-15 лет назад.
Да, 190р/мес сейчас - это не деньги. И почему происходит индексация - тоже понятно. Но и полмегабита - это не связь. Ребята наверное не знают, что на такой скорости даже госуслуги (то, для чего якобы позиционируется тариф) сейчас не работают. Проще иметь мобильную связь рублей за 500, которая работает везде, а не только дома, и не со скоростью черепахи.
Итого, проводные операторы повышают цены, которые за 10 лет в среднем выросли раза в 2. Мобильные - тоже. Так что гайки может быть и крутит ФАС, но не намертво.
Хороший пример. Вот мне не даёт покоя вопрос - когда и где гипотетический хороший джун из первого примера должен все это узнать и всему этому научиться. Ну не так, чтобы "знать эти слова", а ещё и понимать немножко глубже. В школе на продленке этому сейчас учат? Ну нет. В ВУЗе? Ну от части что-то затрагивают, но зависит даже не от ВУЗа или специальности, а от программы конкретного преподавателя. В итоге это какое-то самообразование. То есть кандидат сначала должен сделать для себя один-два проекта уровня, как вы описали выше, набить все шишки, столкнуться со всеми нюансами. И только потом может искать работу уровня джуна.
Если взять джуна, то он будет писать код с помощью LLM. Худо-бедно будет закрывать задачи, и через год-полтора сможет делать что-то более сложное. И гораздо быстрее. Но только с LLM. Предложи написать все самому без LLM - процесс затормозится значительно, а скорее всего даже встанет. Пограммируя с помощью LLM джун не научился кодить без него. Но ещё через год может все получится.
Вчера
Если взять джуна, то используя хороший фреймворк и IDE он сможет делать типовые задачки, а через год-полтора - что-то более сложное, и гораздо быстрее. Но дай ему текстовый редактор и компилятор, и скажи, что библиотеками пользоваться нельзя - процесс затормозится значительно, а скорее всего даже встанет. Пограммируя с помощью ide и фреймворков джун не научился кодить без них. Но ещё через год может все получится.
Позавчера
Взять джуна, через год он сможет писать на C сетевые клиент-серверверные приложения под ОС Linux. Но предложи ему реализовать работу ТСР на контроллере, под который есть только asm и нет библиотек tcp - процесс создания таких приложений под контроллер резко затормозится. И даже встанет. Программируя под ОС джун не научился кодить для систем без ОС. Но ещё через год может все получится.
Пылесос строит карту, чтобы по ней в дальнейшем двигаться, и чтобы в приложении по управлению пылесосом ее можно было использовать. Например дать команду "уборка этой зоны" - и ткнуть в комнату на карте.
Как этот функционал должен работать без передачи карты на сервер? Делать канал p2p между пылесосом и приложением в телефоне? Это не будет работать асинхронно, что приведет к негативному клиентскому опыту.
Например Xiaomi эти карты не только создаёт и отправляет на сервер, но ещё и бэкапит. Если вы двигаете мебель и пылесос что-то там не то найдет, то можно откатить карту на предыдущую. А можно загрузить ее в другой пылесос, и тот не будет долбиться об стены, а сразу будет следовать заданным на карте правилам.
Такое себе расследование, исследователь обнаружил очевидное.
Все любят волт и тераформ. Но в описанной схеме не очень удачно то, что имея возможность что-то сделать в гите - получаешь возможность вскрыть волт. Или можешь внедриться на раннер - можешь вскрыть волт.
Во-первых, соглашусь, что вариант, когда политики волта хранятся в гите - абсолютно правильный. Но подгружать их волт должен самостоятельно, проверяя подписи коммитов. Несколько подписей поставить на один коммит гит не дает, но есть обходные решения.
Это можно реализовать например через плагин. И в этот момент понимаешь, что затащить в плагин opentofu с провайдером волта - это оверкилл. Мы в итоге храним в git обычные json волтовые или hcl, без всякого терраформа.
Крайний случай - это когда политики в волт пушит какой-то конкретный человек, который и так имеет доступ изменять политики. Но не раннер, не джоба CI и т.д. Это сильно сужает поверхность потенциальной атаки.
Во-вторых, не совсем понятно зачем хранить сами секреты в гите, если они у вас хранятся в волте. Да еще sops свеху прикручен. Волт вообще-то для того, чтобы секреты НЕ хранить нигде кроме волта, да еще извлекать их точечно и именно в тот момент, когда это необходимо. Версионирование секретов волт поддерживает, историю изменений тоже видно. Бэкапы делать - да проще некуда, можно их потом хоть распечатывать в base64, или в паблик выкладывать, это безопасно. В вашем же случае волт - это не система хранения секретов с политиками доступа, а перевалочный пункт по доставке секретов в кубер. И если это действительно то, для чего используется волт, то тут можно было остановиться например на helm-secrets. Получилось бы примерно тоже самое, но без дополнительной машинерии.
Разработчики рассчитывают на зарплату здесь и сейчас. Может быть и стыдно за продукт, но не за саму работу. Это честная работа, не хуже чем работа судьи, который понимает бредовость какой-то конкретной ситуации, но должен руководствоваться не здравым смыслом, а законом.
Менеджеры рассчитывают на лоббирование со стороны государства - заблокируют (или сильно усложнят использование) телеграмм, ватсап и т.д., и критическая масса людей перетечет в Макс просто потому что он работает. И в итоге Макс будет у всех, но может быть кто-то заведет для него отдельный телефон с выломанной камерой, микрофоном и антенной gps.
Если не передёргивать, то никакого веселья. Я думаю, мы тут все немного передёргиваем, чтобы не было скучнее, а было веселее.
А по сути:
Все верно. И отказ волта тоже не ведёт
Отказ волта не блокирует работы csi cni dns kubeapi
Это же не проблема. Так или иначе все бэкапить надо, в каком-то виде. Ну кроме наверное аппенд-онли блокчейна, который одновременно неизменяемый и распределенный. Например etcd тоже надо бэкапить. Если не хочешь собирать исчезнувший по какой-то причине кластер из сотен и тысяч репозиториев, а хочешь собрать (хотя бы бОльшую часть) из одного места.
Я не считаю что волт сложный и ненадежный, и это повод от него отказаться, или опасаться использовать. С моей точки зрения волт и etcd - идентичныес точки зрения HA по архитектуре штуки. И может быть даже лучше (если вспомнить энтерпрайзные фичи вроде perfomance replica / dr replica). Только в волте больше возможностей по управлению доступом к ключам, больше способов аутентификации , и шифрованная хранила по умолчанию. По производительности конечно волт в сравнении с etcd проигрывает, но это и понятно - там на порядок больше логики накручено по валилации запроса. Но 10к rps на чтение - вполне держит. И для секретов этого как правило более чем достаточно.
В конце концов, если мы верим, что apiserver + etcd - это надёжная связка, то замените apiserver на vault, и получится такая же надёжная vault + etcd. Просто с другим функционалом. Если кому-то этот функционал не нужен, ну чтож, так бывает. Это как пользоваться postgresql и говорить, что kafka сложная и ещё она ломается, поэтому никаких кафок в проекте быть не должно, и для можно/нужно использовать надёжный проверенный Postgres, он простой и не ломается (хаха, нет)
Любимая тема про поваляшки волта. Я например не очень улавливаю, в чем разница в поваляшках, когда
CSI не может подключить диск и приложение не стартует
Секрет из волта не может извлечься
Кубконтроллер лежит и не создаёт поды
Кубапи лежит и кубконтроллер не знает, что нужно создавать поды
Etcd лежит и непонятно, апиха не работает, поды не создаются
Ингресс лежит, и внешний трафик никуда не роутится
CNI лежит и кубосервисы не работают
Кубднс лежит сервисы не резолвятся
Почему волт лежит какой-то по особенному, не как kubeapi или etcd? Etcd вообще максимально похожий на волт с точки зрения HA - работает только один узел.
Если мы говорим про неправильную конфигурацию vault, так давайте тогда делать неправильную конфигурацию etcd. Что? Не конфигурите etcd по 5 раз на дню? А волт конфигурите? А почему?
Если мы говорим, что волт это ещё одна дополнительная точка отказа, то тут соглашусь. Но тогда давайте будем последовательны в наших опасениях и не будем ходить в сервисы по именам (вдруг днс лежит), не подключать диски (вдруг csi лежит), и хранить конфигурации в oci образе (вдруг кубапи лежит и конфигмапу не забрать). И лучше создавать статик поды через файлы, а то вдруг заклинит API и поды из деплоймента не создадутся. Это максимально надёжно.
Кстати, у инжектора есть режим "не смог извлечь секрет - все равно запусти под". Довольно спорный вариант, но закрывает вопрос "пусть приложение хоть как-то запустится без секрета и может быть оно будет работать"
Ну и про /proc/pid/environment Так запретите доступ к этому интерфейсу ОС. Это же не настоящие файлы. Придется правда ядро немного патчнуть, но что нас остановит?
Добавлю, что сертификат LE ничего толком не удостоверяет.
Только то, что в какой-то момент времени доменное имя указывало на IP адрес, при обращении к которому со стороны сервера LE кто-то отдал верный код.
То есть вы можете даже владеть доменом, но где-то по дороге трафик могут отвернуть (осознанно, или из-за ошибки в bgp) и кто-то другой получит сертификат на ваш домен.
Сертификат LE конечно лучше, чем ничего, но это не очень серьезная гарантия.
По поводу стоимости серта в 200$
Стоимость должна быть такая, чтобы у условного владельца (или владельцев) центра сертификации не появлялось желание сделать фейковый сертификат банка, за раз поднять несколько сотен миллионов баксов и свалить в закат в страну без экстрадиции. И чтобы денег хватало обеспечить безопасность процессов и инфраструктуры так, чтобы рандомные сотрудники не могли такое провернуть. И тут стоимость сертификата получится наверное уже не 1$ за штуку.
А как примерно мультипликациируется потребление памяти в зависимости от размера уже сгенерированного текста?
Например, один том "Войны и мир" около 700 тысяч символов, или 700 килобайт. Так что сама книга в памяти уложится без проблем, если это не i8086 с 640кб памяти.
Можно посмотреть в сторону sops, или helm-secrets. Или werf secrets.
Основная задача - пространственно разделить зашифрованные данные и ключ расшифровывания. И производить расшифровывание максимально близко к моменту использования секрета.
В случае с werf или helm-secrets "использование" секрета - это установка helm-чарта в кластер kubernetes.
Если пользователь напрямую не имеет доступ в kubernetes и не выполняет развертывание, а оно выполняется в системе CI
Сам kubernetes мы можем считать "черным ящиком", доступ к которому есть только из системы CI
То в этом случае хранение зашифрованных секретов в git условно можно считать безопасным. Потому что ключ расшифровывания не находится вместе с зашифрованными данными.
Но в этом случае атаку с целью угона секретов можно проводить где-то на уровне CI системы. А в самом Kubernetes секреты вообще не будут зашифрованные
Мне казалось тут довольно развернутый ответ, понятный даже людям, которые не в теме.
А что насчет аудита? При доставке секретов их обычно не меняют конечно, а читают. Но в принципе аудит этих действий выглядит похожим образом, только операции разные - update или read.
В докладе затрагивались вопросы аудита. И рассматривались методы доставки, при которых аудит будет "нормальный", а при которых - не очень. Не знаю как тут ссылку на раздел вставить, но можно найти в статье, нажав Control+F и набрав "аудит"
Информация "кто-когда.." в аудит-логах - есть. И в Vault, и в Stronghold. Время-дата, информация об субъекте и об объекте. Состав запроса в API, состав ответа API.
С "зачем" тут конечно сложнее. Система не знает "зачем" меняют секрет, можно только в метадате это указывать. Но насколько тут можно доверять user-input вопрос открытый.
Чуть-чуть разверну, где разница.
Если коротко, то нет операции "ищем человека и запускаем пайп"
Если длинно, то давайте рассмотрим пример:
У вас 10 (100) приложений с какими-то своим циклом разработки.
Для смены условного пароля через гит нужно:
Сгенерировать пароль или пароли
Для каждого из десятка приложений внести изменения в гит. Если пароль в гит шифрованный, то перед этим зашифровать. Если шифрованный разными ключами, то зашифровать разными.
Для каждого из приложений определиться, какую версию приложения можно выкатывать. Для этого определить какая версия выкачена сейчас.
Конечно нужно иметь доступы во все эти гит репы, и иметь права на запуск релизных пайплайнов
В случае с секретом в волте нужно ротейтнуть необходимый секрет или секреты. Предполагается, что если приложение при неподходящем/истекшем секрете не может работать, то оно или само завершится с ошибкой, или по лайвнес-пробе. Поэтому приложение так или иначе автоматически перезапустится и на старте получит уже новый секрет. Конечно, если мы эти секреты не деплоим пайплайном, а, как рассказано в докладе, доставляем в контейнер на старте приложения.
То есть права нужны только на запуск ротации секрета, а не в 10-100 репозиториев и после этого запуск 10-100 развертываний. Причем ротация сама по себе процедура безболезненная и безопасная, запустивший ее в процессе сам не получает доступ к секретам. Поэтому доступ к запуску ротации можно дать бОльшему кругу лиц, или вообще проводить авторотации. Или использовать динамические секреты.
И немаловажно, что не нужно выяснять, какую версию приложения надо деплоить. Она останется та же, что и была, изменится только env с секретом.
Правильно ли я понимаю, что дедупликация данных происходит на уровне хранилки? Плюс к этому ещё какой-то аналог copy-on-write.
Например, в случае с упомянутой базой Postgres на 27ТБ, можно "накликать в консоли" 10 реплик, при этом реплики появятся практически мгновенно, так как физического копирования данных 9 раз по 27ТБ не происходит. И при этом места на хранилке все это будет занимать все ещё около 27ТБ, а не 270ТБ?
Ну или лайфхак, как потратить деньги с просроченной карты
Сбер вообще интересный. Он действительно продлил срок действия Visa/MasterCard, но только для физических карт. То есть виртуальная карта Visa Digital работать перестала. И что-то сделать с этим было невозможно, ну кроме перевыпуска, на других условиях, ну и конечно само собой новая карта была бы не Visa, а Мир.
Но примерно через 2 года эта карта с истекшим сроком действия вдруг продлилась и платежи по ней стали проходить, без каких либо действий с моей стороны.
Второе интересное замечание. Хотя срок действия карты был истекший и платежи по ней через интернет не проходили, но подключенный автоплатеж работал безотказно все это время. То есть новые автоплатежи не подключались, но подключенные ранее - списывались.
В общем я не очень доверяю Сберу. Даже простые вещи работают крайне нелогично, необъяснимо, и ещё условия меняются в одностороннем порядке. На карте у меня 1000р и подключен автоплатеж на 60р. Поэтому рассматриваю ее просто как полигон, посмотреть что ещё Сбер учудит.
Получилась практически новая база данных с поддержкой репликации. Данные можно безопасно и надёжно хранить прямо в буфере обмена. Сам буфер обмена поддерживает тёмную тему, что является одним из его основных преимуществ.
Я бы добавил: а вот если бы начали использовать эрланг, то до сих пор бы были в процессе попыток начать использовать эрланг. А бухгалтерию вели на бумажке.
Плюс "убогих go и Kubernetes" наверное в том, что можно взять и уже завтра получить что-то более менее работающее и расширяемое. Не такое может красивое, зато завтра. Потому что послезавтра у это будет уже не нужно, а нужно будет что-то другое.
Новосибирский Новотелеком (куплен ДОМ ру лет 7 назад) поднимает стоимость тарифа ежегодно. Для некоторых тарифов за 7 лет стоимости выросла раза в 2, для некоторых в 6 раз.
Был такой тариф "для пенсионеров", назывался Социальный. 512кбит за 30р в месяц. Появился он когда сотовые операторы повально безлимиты предлагали.
Так вот, этот тариф сначала стоил 30р, потом 40р, далее 60р, 100р. Сейчас уже 190р. Цену не забывают индексировать. Но скорость так и осталась 512кбит, как 10-15 лет назад.
Да, 190р/мес сейчас - это не деньги. И почему происходит индексация - тоже понятно. Но и полмегабита - это не связь. Ребята наверное не знают, что на такой скорости даже госуслуги (то, для чего якобы позиционируется тариф) сейчас не работают. Проще иметь мобильную связь рублей за 500, которая работает везде, а не только дома, и не со скоростью черепахи.
Итого, проводные операторы повышают цены, которые за 10 лет в среднем выросли раза в 2. Мобильные - тоже. Так что гайки может быть и крутит ФАС, но не намертво.
Хороший пример. Вот мне не даёт покоя вопрос - когда и где гипотетический хороший джун из первого примера должен все это узнать и всему этому научиться. Ну не так, чтобы "знать эти слова", а ещё и понимать немножко глубже. В школе на продленке этому сейчас учат? Ну нет. В ВУЗе? Ну от части что-то затрагивают, но зависит даже не от ВУЗа или специальности, а от программы конкретного преподавателя. В итоге это какое-то самообразование. То есть кандидат сначала должен сделать для себя один-два проекта уровня, как вы описали выше, набить все шишки, столкнуться со всеми нюансами. И только потом может искать работу уровня джуна.
Сегодня
Если взять джуна, то он будет писать код с помощью LLM. Худо-бедно будет закрывать задачи, и через год-полтора сможет делать что-то более сложное. И гораздо быстрее. Но только с LLM. Предложи написать все самому без LLM - процесс затормозится значительно, а скорее всего даже встанет. Пограммируя с помощью LLM джун не научился кодить без него. Но ещё через год может все получится.
Вчера
Если взять джуна, то используя хороший фреймворк и IDE он сможет делать типовые задачки, а через год-полтора - что-то более сложное, и гораздо быстрее. Но дай ему текстовый редактор и компилятор, и скажи, что библиотеками пользоваться нельзя - процесс затормозится значительно, а скорее всего даже встанет. Пограммируя с помощью ide и фреймворков джун не научился кодить без них. Но ещё через год может все получится.
Позавчера
Взять джуна, через год он сможет писать на C сетевые клиент-серверверные приложения под ОС Linux. Но предложи ему реализовать работу ТСР на контроллере, под который есть только asm и нет библиотек tcp - процесс создания таких приложений под контроллер резко затормозится. И даже встанет. Программируя под ОС джун не научился кодить для систем без ОС. Но ещё через год может все получится.