Pull to refresh

Comments 7

Вторую часть, когда я прокидываю секреты напрямую в приложение, я как раз рассматривал в своем видео. Пользуюсь таким подходов уже примерно с год.

Здравствуйте!

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

привет, рад новой встрече!
в своей прошлой статье вы так и не дали ВНЯТНОГО ответа. зело продолжим:

Дано. Для "повышения безопасности", вы храните в ПровайдереСекретов Секреты для доступа к Серверам.
Вопрос: Где вы храните Секреты для доступа к самому ПровайдеруСекретов?

Привет, взаимно!

  1. Как раз я не дождался ответа от вас про аллегории. Так как ответил вам в первой части статьи).

  2. Доступ к провайдеруСекретов осуществляется на основании ServiceAcounts, к которым привязаны роли и политики, созданные в Vault заранее благодаря методу авторизации Kuberntes.

Дополню, если речь про токены для распечатывания кластера и изначальный root токен, который в принципе не используется для доступов к секретам, то они хранятся в Opaque Secret также в ns vault. Что с точки зрения OpaqueSecert не безопасно, как об этом собственно подчёркнуто в статье. Но пояснения и комментарии по этому также даны в статье)

не безопасно

это правильный ответ.

небезопасно хранить Секреты доступа к ПровайдеруСекретов - это глупо. а их невозможно хранить иначе.

Да, полностью согласен с вами. В статье акцент делался не на безопасность, а на удобство, скорость и оптимизацию. Чтобы отвечать требованиям бизнеса с точки зрения скорости разработки.

Но тем менее НЕбезопасная сторона вопроса также рассмотрена в последнем разделе статьи и сделан акцент на решения и доработки. В нашем случае это скорее всего будет Bank-Vaults Mutating Webhook.

"а их невозможно хранить иначе" - здесь также солидарен, в статье также акцент сделан на это в контексте OpaqueSecert. Но будем честны, если у злоумышленника оказался доступ к Kuberntes кластеру, то говорить о чем-то более конкретном ИМХО не имеет уже никакого смысла...

Sign up to leave a comment.