Да, полностью согласен с вами. В статье акцент делался не на безопасность, а на удобство, скорость и оптимизацию. Чтобы отвечать требованиям бизнеса с точки зрения скорости разработки.
Но тем менее НЕбезопасная сторона вопроса также рассмотрена в последнем разделе статьи и сделан акцент на решения и доработки. В нашем случае это скорее всего будет Bank-Vaults Mutating Webhook.
"а их невозможно хранить иначе" - здесь также солидарен, в статье также акцент сделан на это в контексте OpaqueSecert. Но будем честны, если у злоумышленника оказался доступ к Kuberntes кластеру, то говорить о чем-то более конкретном ИМХО не имеет уже никакого смысла...
Дополню, если речь про токены для распечатывания кластера и изначальный root токен, который в принципе не используется для доступов к секретам, то они хранятся в Opaque Secret также в ns vault. Что с точки зрения OpaqueSecert не безопасно, как об этом собственно подчёркнуто в статье. Но пояснения и комментарии по этому также даны в статье)
Как раз я не дождался ответа от вас про аллегории. Так как ответил вам в первой части статьи).
Доступ к провайдеруСекретов осуществляется на основании ServiceAcounts, к которым привязаны роли и политики, созданные в Vault заранее благодаря методу авторизации Kuberntes.
6. Раз все дети знают, что пароль к Базе нужно хранить в Vault, то делаем вывод, что все дети знают что такое Vault, хотя бы просто знают =), таким образом: все дети, зная что такое Vault, могут пойти и узнать или мы им можем поведать, что у чудного, неведомого Vault, есть инструмент (Database Secret Engine - не вдаваясь в тех. подробности сейчас). 7. все дети ТЕПЕРЬ знают, что есть инструмент для безопасной добычи пароля из Vault (абстрагируясь от абстракций Kubernetes, VM и т.д. будь то железка) 8. все дети, ТЕПЕРЬ знают, что в принципе есть различные инструменты безопасного извлечения секретов из Vault.
P.S: дети же когда-то, от кого-то узнали, что такое База и почему нельзя хранить пароль в конфиге, дети же когда-то узнали, от кого-то узнали, что пароль к Базе нужно хранить в Vault - соответственно именно дети задались вопросом: "А как соединить эти две сущности, чтобы безопасно получить пароль?" и пришли с ним ко взрослым =)
Да, увы. Складывается ощущение, что безопасность из коробки до сегодняшних версий Kubernetes (вплоть до 1.30/1.31) совсем НЕ является приоритетом ни в каком виде.
Да, с вашими тезисами соглашусь отчасти. Но конечная цель была в удобстве, отсутствии лишних рабочих нагрузок (в отличие от того же Vault Agent Injector, где у нас есть sidecar и init контейнеры) и в быстрой доставке:
"поэтому нам нужно было ускорить и оптимизировать доставку секретов в контейнеры с микросервисом, избежать дополнительных рабочих нагрузок в kubernetes, гарантировать безопасность при доставке секретов и исключить внешние зависимости" - вот главные причины, по которым мы пришли к инструментам, о которым говориться в самом конце. И тут сделан акцент на "гарантировать безопасность при доставке секретов" - доставка секретов безопасная, а вот ее итоговое хранение в Opaque Secrets почти в открытом виде (так как все мы знаем, на сколько безопасен base64 энкодинг =) ) - действительно нет.
Что же касается безопасности хранения секретов: 1) Vault здесь используется как единый источник хранения секретов, таким образом нам не нужны секреты хранить в репозиториях (пусть даже с шифрованием в виде инструментов SOPS, helm secrets, etc...) - ведь если мы говорим о подходе IaC, что для нас немаловажно, то хранить даже секреты где-то нужно и чтобы это "где-то" - было единственным источником правды.
2) Что касается secrets и rbac - тут вы правы про гранулярность и аудит доступов к Opaque Secrets. Поэтому вторая часть статьи будет именно про то, какие решения есть для шифрования этих Opaque Secrets уже непосредственно в etcd или обхода Opaque Secrets в процессе доставки секретов в микросервисы
3) Ну и третье (из разряда "паранойи" =)) - если у злоумышленника есть доступ к Kubernetes кластеру, где он может даже с учетом настроенных rbac просмотреть Opaque Secrets, то он уже может "веселиться" с кластером, как он хочет. И говорить тут о чем-то более важном не имеет уже особого смысла.
Безусловно с точки зрения ИБ стоит вопрос о том, что есть также проблема, что в конечном счете секреты хранятся в переменных окружения, а не где-нибудь в RAM, shared memory и т.д. Собственно во второй части статьи будут предложены решения в том числе и по данной проблеме.
"нам дают без пароля соединиться с Vault и взять там пароль БД" - вам не дают соединиться с Vault без какого-либо типа авторизации, она все равно есть. Будь то UI для обычного пользователя. Будь то токены, пароли, LDAP и т.д для админов, либо сервисов =)
Я не могу ответить на поставленный вами вопрос, так как природа возникновения вашего утверждения "но! нам дают без пароля соединиться с Vault и взять там пароль БД" - мне не ясна.
И я в очередной раз буду утверждать, что беспарольная авторизация != отсутствие авторизации. Так как в Vault есть авторизация (из коробки по токену) из типов и методов в том числе, можно создать локальную УЗ с паролем.
Позтому, если это возможно, изложите свой тезис немного иначе. Так как со вторым пунктом я в корне не согласен, так как это не корелируется с Vault по ранее указанным мною пунктам :)
"но с Vault безопасно соединяться без пароля" - данным своим утверждением, вы полностью подтверждаете, что даже не вчитывались в весь мой ответ вам, в котором я не раз подчеркнул про root-токен и другие типы авторизаций в Vault
У меня встречный вопрос к вам: вы я так понимаю кроме метода авторизации по паролю, других не пробовали?
1) по JWT
2) по SSL
3) по access токенам
Ну и тогда лее (то что сразу в голову пришло)
Пароль, точно также, как и токен, точно также, как сертификаты для авторизации, может быть скомпрометирован. Мы с вами говорим о совершенно разных вещах, вы скажем так, прицепились к тому, что в Vault авторизация без парольная, это действительно из коробки так. Но там авторизация идёт по токену, который точно также может быть утерян, скомпрометирован. Но в отличие от пароля никаким брутфорсом или иным методом НЕ подобран.
Как итог: мнение в том числе и разработчиков Vault( раз уж они из коробки авторизацию по root токену вшили) что аутентификация и авторизация по паролю менее безопасная, чем по токену, который, вновь повторюсь, в отличие от пароля НЕ может быть подобран простым перебором, брутфорсом и т.д.
P.S: почитайте про методы авторизации в Vault, про JWT токены, про access и refresh токены. А то у меня создалось ощущение, что вы даже не стали вчитываться в мой ответ =)
Что значит пароль для самого Vault? И каким образом злоумышленник прочитает Vault, если:
а) root token глубоко спрятан и доступен только лицам, которые отвечают за Vault кластер
б) Те, кто имеют доступ к Vault авторизуются в нем исключительно по LDAP (если мы говорим про UI)
в) Для того, чтобы микросервисы могли авторизоваться и забирать нужные секреты Vault настроена kubernetes авторизация на основе SA токенов по определенным политикам исключительно на чтение нужных секретов сервиса. (Собственно во второй части об этом будет информация)
г) Root-токен вообще не используется для авторизации пользователями
"то вам нужен Vault2 чтобы хранить пароль Vault" - мне очень интересно, как вы пришли к такому выводу о паролях Vault? Если изначальная из коробки аутентификация и авторизация происходит по root токену, если не настроено иное. Использование которого, как уже оговаривалось выше, является совсем не безопасным, так как есть риск утечки.
Что же касается хранения тогда уж НЕ пароля а Root-токена, то об этом как раз будет вторая часть статьи)
На основе двух вышеописанных пунктов, смею задать вам встречный вопрос : а вы уверены, что правильно понимаете зачем нужен Vault и как его использовать? =)
Да, полностью согласен с вами. В статье акцент делался не на безопасность, а на удобство, скорость и оптимизацию. Чтобы отвечать требованиям бизнеса с точки зрения скорости разработки.
Но тем менее НЕбезопасная сторона вопроса также рассмотрена в последнем разделе статьи и сделан акцент на решения и доработки. В нашем случае это скорее всего будет Bank-Vaults Mutating Webhook.
"а их невозможно хранить иначе" - здесь также солидарен, в статье также акцент сделан на это в контексте OpaqueSecert. Но будем честны, если у злоумышленника оказался доступ к Kuberntes кластеру, то говорить о чем-то более конкретном ИМХО не имеет уже никакого смысла...
Дополню, если речь про токены для распечатывания кластера и изначальный root токен, который в принципе не используется для доступов к секретам, то они хранятся в Opaque Secret также в ns vault. Что с точки зрения OpaqueSecert не безопасно, как об этом собственно подчёркнуто в статье. Но пояснения и комментарии по этому также даны в статье)
Привет, взаимно!
Как раз я не дождался ответа от вас про аллегории. Так как ответил вам в первой части статьи).
Доступ к провайдеруСекретов осуществляется на основании ServiceAcounts, к которым привязаны роли и политики, созданные в Vault заранее благодаря методу авторизации Kuberntes.
Здравствуйте!
К сожалению ссылка на видео не открывается, возможно у меня одного так, очень хотелось бы посмотреть ваше решение!
Окей :)
6. Раз все дети знают, что пароль к Базе нужно хранить в Vault, то делаем вывод, что все дети знают что такое Vault, хотя бы просто знают =), таким образом:
все дети, зная что такое Vault, могут пойти и узнать или мы им можем поведать, что у чудного, неведомого Vault, есть инструмент (Database Secret Engine - не вдаваясь в тех. подробности сейчас).
7. все дети ТЕПЕРЬ знают, что есть инструмент для безопасной добычи пароля из Vault (абстрагируясь от абстракций Kubernetes, VM и т.д. будь то железка)
8. все дети, ТЕПЕРЬ знают, что в принципе есть различные инструменты безопасного извлечения секретов из Vault.
P.S: дети же когда-то, от кого-то узнали, что такое База и почему нельзя хранить пароль в конфиге, дети же когда-то узнали, от кого-то узнали, что пароль к Базе нужно хранить в Vault - соответственно именно дети задались вопросом: "А как соединить эти две сущности, чтобы безопасно получить пароль?" и пришли с ним ко взрослым =)
Да, увы. Складывается ощущение, что безопасность из коробки до сегодняшних версий Kubernetes (вплоть до 1.30/1.31) совсем НЕ является приоритетом ни в каком виде.
Здравствуйте.
Да, с вашими тезисами соглашусь отчасти. Но конечная цель была в удобстве, отсутствии лишних рабочих нагрузок (в отличие от того же Vault Agent Injector, где у нас есть sidecar и init контейнеры) и в быстрой доставке:
"поэтому нам нужно было ускорить и оптимизировать доставку секретов в контейнеры с микросервисом, избежать дополнительных рабочих нагрузок в kubernetes, гарантировать безопасность при доставке секретов и исключить внешние зависимости" - вот главные причины, по которым мы пришли к инструментам, о которым говориться в самом конце. И тут сделан акцент на "гарантировать безопасность при доставке секретов" - доставка секретов безопасная, а вот ее итоговое хранение в Opaque Secrets почти в открытом виде (так как все мы знаем, на сколько безопасен base64 энкодинг =) ) - действительно нет.
Что же касается безопасности хранения секретов:
1) Vault здесь используется как единый источник хранения секретов, таким образом нам не нужны секреты хранить в репозиториях (пусть даже с шифрованием в виде инструментов SOPS, helm secrets, etc...) - ведь если мы говорим о подходе IaC, что для нас немаловажно, то хранить даже секреты где-то нужно и чтобы это "где-то" - было единственным источником правды.
2) Что касается secrets и rbac - тут вы правы про гранулярность и аудит доступов к Opaque Secrets. Поэтому вторая часть статьи будет именно про то, какие решения есть для шифрования этих Opaque Secrets уже непосредственно в etcd или обхода Opaque Secrets в процессе доставки секретов в микросервисы
3) Ну и третье (из разряда "паранойи" =)) - если у злоумышленника есть доступ к Kubernetes кластеру, где он может даже с учетом настроенных rbac просмотреть Opaque Secrets, то он уже может "веселиться" с кластером, как он хочет. И говорить тут о чем-то более важном не имеет уже особого смысла.
Безусловно с точки зрения ИБ стоит вопрос о том, что есть также проблема, что в конечном счете секреты хранятся в переменных окружения, а не где-нибудь в RAM, shared memory и т.д. Собственно во второй части статьи будут предложены решения в том числе и по данной проблеме.
"нам дают без пароля соединиться с Vault и взять там пароль БД" - вам не дают соединиться с Vault без какого-либо типа авторизации, она все равно есть. Будь то UI для обычного пользователя. Будь то токены, пароли, LDAP и т.д для админов, либо сервисов =)
Я не могу ответить на поставленный вами вопрос, так как природа возникновения вашего утверждения "но! нам дают без пароля соединиться с Vault и взять там пароль БД" - мне не ясна.
И я в очередной раз буду утверждать, что беспарольная авторизация != отсутствие авторизации. Так как в Vault есть авторизация (из коробки по токену) из типов и методов в том числе, можно создать локальную УЗ с паролем.
Позтому, если это возможно, изложите свой тезис немного иначе. Так как со вторым пунктом я в корне не согласен, так как это не корелируется с Vault по ранее указанным мною пунктам :)
"но с Vault безопасно соединяться без пароля" - данным своим утверждением, вы полностью подтверждаете, что даже не вчитывались в весь мой ответ вам, в котором я не раз подчеркнул про root-токен и другие типы авторизаций в Vault
У меня встречный вопрос к вам: вы я так понимаю кроме метода авторизации по паролю, других не пробовали?
1) по JWT
2) по SSL
3) по access токенам
Ну и тогда лее (то что сразу в голову пришло)
Пароль, точно также, как и токен, точно также, как сертификаты для авторизации, может быть скомпрометирован. Мы с вами говорим о совершенно разных вещах, вы скажем так, прицепились к тому, что в Vault авторизация без парольная, это действительно из коробки так. Но там авторизация идёт по токену, который точно также может быть утерян, скомпрометирован. Но в отличие от пароля никаким брутфорсом или иным методом НЕ подобран.
Как итог: мнение в том числе и разработчиков Vault( раз уж они из коробки авторизацию по root токену вшили) что аутентификация и авторизация по паролю менее безопасная, чем по токену, который, вновь повторюсь, в отличие от пароля НЕ может быть подобран простым перебором, брутфорсом и т.д.
P.S: почитайте про методы авторизации в Vault, про JWT токены, про access и refresh токены. А то у меня создалось ощущение, что вы даже не стали вчитываться в мой ответ =)
Кстати, что касается вашего конкретного примера с БД, отвечу и на это, для авторизации микросервисами в БД есть специальный тип для этого "Database Secret Engine" https://developer.hashicorp.com/vault/docs/secrets/databases
Здравствуйте!
Отвечая на ваши вопросы:
Что значит пароль для самого Vault? И каким образом злоумышленник прочитает Vault, если:
а) root token глубоко спрятан и доступен только лицам, которые отвечают за Vault кластер
б) Те, кто имеют доступ к Vault авторизуются в нем исключительно по LDAP (если мы говорим про UI)
в) Для того, чтобы микросервисы могли авторизоваться и забирать нужные секреты Vault настроена kubernetes авторизация на основе SA токенов по определенным политикам исключительно на чтение нужных секретов сервиса. (Собственно во второй части об этом будет информация)
г) Root-токен вообще не используется для авторизации пользователями
"то вам нужен Vault2 чтобы хранить пароль Vault" - мне очень интересно, как вы пришли к такому выводу о паролях Vault? Если изначальная из коробки аутентификация и авторизация происходит по root токену, если не настроено иное. Использование которого, как уже оговаривалось выше, является совсем не безопасным, так как есть риск утечки.
Что же касается хранения тогда уж НЕ пароля а Root-токена, то об этом как раз будет вторая часть статьи)
На основе двух вышеописанных пунктов, смею задать вам встречный вопрос : а вы уверены, что правильно понимаете зачем нужен Vault и как его использовать? =)