NZ
Можно же смонтировать так любой файл с хоста
nomad это собо не про безопасность. Если нужна, то стоит делать по кластеру на человека.
монтировать сертификаты с хоста все таки удобно
Size: a a a
2020 December 29
NZ
AY
volumes = ["/etc/ssl/certs:/etc/ssl/certs:ro"]
NZ
Это должно помочь наверное
AY
Это должно помочь наверное
я пока на 0.8 😄 скоро буду мигрировать
С
Спасибо! Вариант через скачивание артефакта помог. Попробую остальные варианты
AY
Для java других вариантов особо нет
OO
Привет! Если кто-то использует выдачу через vault одноразовые пароли и коротко живущих сертификатов или ключей или динамически создаваемых учеток, сколько операций на создание таких кредов у вас бывает в секунду, например, в результате массовых поднятий узлов или в результате массовых операций над узлами инфраструктуры?
OO
И если меряли то сколько iops генерится raft-ом при таких массовых изменениях
2020 December 30
GM
Всем привет! есть микросервисы которые ансиблом ходят в vault и дёргают свои секреты, задача каждому сделать токен и политику с доступом до своего секрета. Не совсем понимаю как лучше сделать. Создать entity и alias и к нему привязать policy?
С
Georgii Marinov
Всем привет! есть микросервисы которые ансиблом ходят в vault и дёргают свои секреты, задача каждому сделать токен и политику с доступом до своего секрета. Не совсем понимаю как лучше сделать. Создать entity и alias и к нему привязать policy?
А где микросервисы работают?
GM
контейнер, ансибл генерит конфиги с секретами, при запросе секрета передается токен, вот нужно каждому токену разграничить доступ до своего секрета
С
Georgii Marinov
контейнер, ансибл генерит конфиги с секретами, при запросе секрета передается токен, вот нужно каждому токену разграничить доступ до своего секрета
Тогда вопрос как к токену привязать политику. Как хост получает этот токен и на какое время?
С
Я бы наверное сделал approle или вообще долгоживущий токен.
GM
Тогда вопрос как к токену привязать политику. Как хост получает этот токен и на какое время?
Да, чтобы токен имел политику
GM
Я бы наверное сделал approle или вообще долгоживущий токен.
а approle это роль которая вяжется к entity?
С
Нет, approle как раз не вяжется. Но если я правильно понял, у вас хост, а не человек-пользователь. Есть ли смысл через entity всё завязывать? Он обычно нужен, когда один пользователь ходит через разные auth бекенды.
GM
Нет, approle как раз не вяжется. Но если я правильно понял, у вас хост, а не человек-пользователь. Есть ли смысл через entity всё завязывать? Он обычно нужен, когда один пользователь ходит через разные auth бекенды.
тогда это будет излишне, мне просто нужно 10-15 токенов и к каждому привязать политику с доступом только к своему секрету
С
Georgii Marinov
тогда это будет излишне, мне просто нужно 10-15 токенов и к каждому привязать политику с доступом только к своему секрету
Тогда будет достаточно или approle или статически выпущенных токенов. Статические токены надо будет где-то рефрешить и периодически выпускать и раскладывать новые, либо выпустить вечные, но всё равно их рефрешить. Для approle достаточно положить app_id и role_id на хост и получать токен оттуда по этим параметрам, но надо где-то написать процесс получения.