Comments 7
Здравствуйте!
К сожалению ссылка на видео не открывается, возможно у меня одного так, очень хотелось бы посмотреть ваше решение!
привет, рад новой встрече!
в своей прошлой статье вы так и не дали ВНЯТНОГО ответа. зело продолжим:
Дано. Для "повышения безопасности", вы храните в ПровайдереСекретов Секреты для доступа к Серверам.
Вопрос: Где вы храните Секреты для доступа к самому ПровайдеруСекретов?
Привет, взаимно!
Как раз я не дождался ответа от вас про аллегории. Так как ответил вам в первой части статьи).
Доступ к провайдеруСекретов осуществляется на основании ServiceAcounts, к которым привязаны роли и политики, созданные в Vault заранее благодаря методу авторизации Kuberntes.
Дополню, если речь про токены для распечатывания кластера и изначальный root токен, который в принципе не используется для доступов к секретам, то они хранятся в Opaque Secret также в ns vault. Что с точки зрения OpaqueSecert не безопасно, как об этом собственно подчёркнуто в статье. Но пояснения и комментарии по этому также даны в статье)
не безопасно
это правильный ответ.
небезопасно хранить Секреты доступа к ПровайдеруСекретов - это глупо. а их невозможно хранить иначе.
Да, полностью согласен с вами. В статье акцент делался не на безопасность, а на удобство, скорость и оптимизацию. Чтобы отвечать требованиям бизнеса с точки зрения скорости разработки.
Но тем менее НЕбезопасная сторона вопроса также рассмотрена в последнем разделе статьи и сделан акцент на решения и доработки. В нашем случае это скорее всего будет Bank-Vaults Mutating Webhook.
"а их невозможно хранить иначе" - здесь также солидарен, в статье также акцент сделан на это в контексте OpaqueSecert. Но будем честны, если у злоумышленника оказался доступ к Kuberntes кластеру, то говорить о чем-то более конкретном ИМХО не имеет уже никакого смысла...
Наш путь delivery of secrets: как мы пришли к связке Bank-Vaults и Vault Secret Operator