Всех с пятницей!!!

При управлении секретами есть одна весомая проблема – Secret Zero, т.е. как доставить «первичный секрет», который будет использоваться для доступа к другим секретам внутри хранилища?

Допустим, наш первичный секрет – Token. Иронично, но сам по себе он уже секрет. Наверное, надо сделать секрет, который будет контролировать доступ к нашему Token, получается рекурсия…

Одним из выходов становятся «центры доверия» - например, GitLab и JWT, Kubernetes и ServiceAccount, LDAP и учетные данные. Принцип простой – есть «третья сторона», которой мы доверяем и у которой можем спросить – «Может ли эта сущность запрашивать секреты? Можно ли ее пропустить в хранилище?». А ответ оставляем на рассмотрение третьей стороны.

Но что делать, если такой третьей стороны нет? И вот тут на помощь приходит AppRole (у HashiCorp Vault).

В видео от HashiCorp можно ознакомиться с общими рассуждениями на тему Secret Zero и с тем, как можно использовать AppRole для решения проблемы.

Недавно мы уже писали о похожем подходе для извлечения секретов в CI-pipeline. Однако, в видео Hashi есть ряд существенных отличий:
🍭 Первое заключается в том, что RoleID находится у Runner, а не задается в pipeline.
🍭 Второе – в процессе получения SecretID. В упоминаемом посте Token использовался для получения SecretID сразу, но есть и альтернативный способ!

Вместо SecretID можно вернуть еще один Token (да сколько можно!), назовем его Wrap Token, который предоставляет доступ только в Cubbyhole – некоторую область внутри Vault. Это называется Response Wrapping. Можно настроить количество использований или время жизни Wrap Token, что еще больше минимизирует риск компрометации.

Соответственно, чтобы извлечь SecretID надо реализовать обратную процедуру – Unwrapping.
Unwrapping осуществляется с использованием Wrap Token, который у нас уже есть, в результате мы получаем SecretID.

Готово! У нас есть RoleID и SecretID, ничего не мешает нам извлечь Secret из Vault ☺️