All streams
Search
Write a publication
Pull to refresh
Sergey Derevyago @dersoverflowread⁠-⁠only

User

Send message

мы разобрались с традиционным противостоянием std::map против std::unordered_map, есть смысл посмотреть на альтернативные реализации

еще посмотрите ders::blob_map - в 14 раз быстрее unordered_map<string, string> на 64 потоках.

здесь: https://ders.by/cpp/memdb/memdb.html#5.1

Видно, что tcmalloc быстрее стандартного аллокатора в пять раз

попробуйте ders::mem_pool.

по результатам тестирования list<int, mp_allocator<int>> получается ускорение в 5-8 раз. здесь результаты: https://ders.by/cpp/norefs/norefs.html#4.2

а sh_ptr с mp_allocator в 6-12 раз!

но самое смешное - это ввод/вывод! ders::buf_rd дает ускорение в 10-33 раза.

в некотором роде логично

нет, НЕ логично! цена взлома Супер-Пупер Защищенного Хранилища == цена взлома Васиного ПК.

хотя Васе конечно приятно.

на гитхабе место пароля просит уже Passkey вести, но я вожу пароль от ПК, и если у меня войдут в ПК, то благодаря Passkey смогу зайти и украсть данные

отлично! мы здесь https://habr.com/en/companies/ru_mts/articles/861822/ обсуждали именно этот вопрос:

у вас есть пароль для самого Vault?

  1. Если нет, то злоумышленник прочитает Vault и получит пароль БД...

  2. Если да, то вам нужен Vault2 чтобы хранить пароль Vault...

есть еще интересный случай: на старых монструозных проектах прямая сборка бинарей из исходников (без промежуточных библиотек) может оказаться в несколько раз быстрее (напр. 40 секунд вместо 15 минут).

а именно. вместо старого "логичного метода":

  1. компилируем и собираем в библиотеку общие файлы бинарей

  2. компилируем уникальные файлы бинаря

  3. линкуем их с библиотекой

сразу вызываем:

  1. g++ mysrc1/*.cpp mylib/*.cpp -o mybin1

ЗЫ конечно не все *.cpp а только лишь нужные файлы. пробуй.

Разработчики кубернетес придумали хранить конфигурации в объектах ConfigMaps, а секретные/не публичные значения в объектах Secrets

я вам даже больше скажу, разработчики кубернетес такие забавники:

Kubernetes 1.7 introduced encryption of Secrets but doesn’t enable it by default. Even when this becomes default, the data encryption key (DEK) is stored on the same node as the Secret! This means gaining access to a node lets you to bypass encryption. This is especially worrying on nodes that host the cluster store (etcd nodes).

вам не дают соединиться с Vault без какого-либо типа авторизации, она все равно есть

именно это и хотелось бы уточнить. давайте рассмотрим сферический Vault в вакууме:

  1. мы ставим на Linux сервер нативное Приложение.

  2. у Приложения есть конфиг и ему нужно работать с Базой.

а дальше уже интересно:

  1. все дети знают, что пароль к Базе нельзя хранить в конфиге!

  2. все дети знают, что пароль к Базе нужно хранить в Vault.

вы, как представитель частного капитала, не можете остаться глухи к стонам родины! одни лишь маленькие дети, беспризорные, находятся без призора. и мы, господа присяжные заседатели, им поможем :)

объясните pls детям как В ЭТОМ СЛУЧАЕ безопасно добыть пароль из Vault.

а Kubernetes мы разберем потом, т.к. детям не нужно buzzwords и obscurity, окай? :)

У меня встречный вопрос к вам: вы я так понимаю кроме метода авторизации по паролю, других не пробовали?

вообще-то я Lead Solutions Architect и задаю этот вопрос на собеседованиях :) и как правило, 80% "архитектров" в ответ сыпят buzzword-ами не понимая СУТИ.

так давайте мы здесь сейчас разберемся и тем самым им всем поможем. итак, еще раз.

дано:

  1. нам не дают соединиться с БД без пароля, т.к. это небезопасно.

  2. но! нам дают без пароля соединиться с Vault и взять там пароль БД.

вопрос: нет ли здесь противоречия? :)

Для того, чтобы микросервисы могли авторизоваться и забирать нужные секреты Vault настроена kubernetes авторизация на основе SA токенов по определенным политикам исключительно на чтение нужных секретов сервиса.

это называется Security through obscurity. а мы смотрим по сути! и видим два утверждения:

  1. с БД небезопасно соединяться без пароля.

  2. но с Vault безопасно соединяться без пароля.

гмм... тогда:

  1. если в Vault реализован "волшебный способ" соединения, то тот же самый способ мы можем СРАЗУ же использовать и для БД => Vault не нужен!

  2. а если сказок не существует, то Vault мы используем небезопасно => Vault нам не нужен тем более!!

как-то так :)

Наконец-то отличная тема! Вы уверены, что правильно понимаете зачем нужен Vault?

  1. Допустим, мы используем Базу Данных.

  2. Для соединения с БД нам нужен пароль. Т.к. без пароля злоумышленник получит все наши данные.

  3. Мы не кладем пароль в конфиги, т.к. злоумышленник прочитает конфиги и получит пароль БД...

  4. Мы храним пароль в Vault.

Отлично! Теперь вопрос: у вас есть пароль для самого Vault?

  1. Если нет, то злоумышленник прочитает Vault и получит пароль БД...

  2. Если да, то вам нужен Vault2 чтобы хранить пароль Vault...

Итак: вы уверены, что правильно понимаете зачем нужен Vault?

Уже давно существуют широко известные в узких кругах ders::sh_ptr и ders::un_ptr.

По тестам производительности https://ders.by/cpp/norefs/norefs.html#4.1

  1. ders::sh_ptr быстрее std::shared_ptr в 4-6 раз.

  2. а sh_ptr с mp_allocator аж в 6-12!

ЗЫ Исходный код там же.

12 ...
8

Information

Rating
Does not participate
Registered
Activity

Specialization

Software Architect