Настраиваем управление секретами с Yandex Lockbox, AWS Secret Manager, Vault Secrets и shell-operator

[Artarik]

про шелл-оператора не понял.

А что делать, если мы не хотим использовать секреты в качестве объектов K8s

и ниже

как только в кластере появляется секрет с аннотацией lockbox=yes оператор создает новый секрет или заменяет его, а после удаляет ненужные секреты

то есть секрет все равно надо создавать, но с определенной аннотацией. Тогда в чем смысл?

Далее

  if ! kubectl get -f - <<< "$object" >/dev/null 2>/dev/null; then
    kubectl create -f - <<< "$object" >/dev/null
  else
    kubectl replace --force -f - <<< "$object" >/dev/null
  fi

почему б не заменить на kubectl apply ... ?

[Tall13]

Совсем от использования секретов мы конечно же не уйдем, но с помощью оператора мы создавали секрет, который использовался только при запуске приложения и потом удалялся из кластера. Можно использовать и kubectl apply, ограничений нет)

[Yerzhan46]

Спасибо за статью - прочитал с большим интересом.

Насколько, по вашему, external secrets operator готов к использованию в production environment?

Сам продукт развивается с 03/2021, 103 релизa, но все ещё бета версия (0.9.2) и 123 open issues. Поддержка - только коммьюнити. Linux Foundation project.

[Artarik]

мы используем в проде уже год, с версии 0,5.*, ни одного ложного срабатывания.

[trublast]

Сложно понять, что имеется ввиду под "готов для продакшн", поэтому и ответить на такой вопрос сложно.

Я слышал, что Linux написал какой-то финский судент, и, хотя проект развивается уже десятки лет, там всё ещё тысячи open issues на https://bugzilla.kernel.org

Тем не менее некоторые используют Linux в production environment. Но, как вы понимаете продакшн продакшну рознь, тут конечно каждый сам решает, подойдёт ли им Linux или пока нет. Тоже самое с external secrets operator - если у вас очень ответственный продакшн, то, возможно, и external secrets operator и Linux использовать пока рановато.

Например мы рискнули и начали использовать в продакшн и Linux, и Kubernetes, и External secrets operator. Если говорить про количество возникших проблем, то с external secrets operator за все время эксплуатации (около полугода) их не было совсем. А больше всего проблем было с Linux.

Имея такую статистику можно сделать (неправильный) вывод, что проект External secrets operator на голову лучше и стабильнее, чем Linux.

Ну а если кроме шуток, то оператор очень не плох, нам нравится и мы используем его в продакшн. И как я писал выше - проблем (пока) не было.

[Yerzhan46]

И с Linux и с Kubernetes есть разные уровни риска - можно поставить все самим и разбираться с проблемами тоже самостоятельно. Можно найти вендора и все проблемы решать через официальную поддержку. А с ESO - только community support - так что доверия от клиентов меньше.

[Tall13]

Используем в прод окружениях на нескольких проектах. Полет нормальный.

[Yerzhan46]

Спасибо. Основная причина почему наши клиенты не особо стремятся использовать ESO - отсутствие поддержки. Community support не доверяют.