Comments 14
Я не понимаю, как ваши слова противоречат статье и паттерну использования Vault.
Vault не запрещает гибко управлять доступами к секретам. Общность секретов — только в расположении secret/infra/whatever.
Вы можете и должны делать токены для доступа только к тем секретам, которые необходимы и достаточны для выполнения работ.
Например у вас есть сервис, который использует все секреты из secret/service_name и только jenkins_api_token из инфраструктурных секретов.
Вы можете сделать политику
path "secret/service_name/*" {
policy = "read"
}
path "secret/infra/jenkins/api_token" {
policy = "read"
}
И выдать токен, ограниченный только теми доступами, которые вам нужны.
Можно ли из этого построить корпоративную базу паролей наподобие teampass
или привязать teampass
к такой базе?
Можно построить, только без веб-gui.
Хм. Ценность teampass — именно в том, что все сотрудники получают удобный общий интерфейс для ввода/отображения паролей. Мне лично удобнее standalone-приложения (после keepass, который очищает буфер обмена как-то непривычно знать, что сайт не очистит пароль), но приходится пользоваться общими тулзами.
Количество ключей для распечатки хранилища:
Мало смысла делать отличным от 1. Админ с root доступом к машине на которой крутится unsealed vault может легко вытащить master key.
воспроизвести пароль второй раз так и не смог.
Как не хранить секреты где придётся, или зачем нам Hashicorp Vault