Комментарии 12
"auth/approle/*" { capabilities = [ "create", "read", "update", "delete", "list" ] }
path "sys/policies/acl/*" { capabilities = [ "create", "read", "update", "delete", "list" ] }
Возможно я где-то что-то проглядел, но получается, что пользователь может сам себе политику поменять на любые права и забиндить любую роль.
Статья год в черновиках лежала, что то мог и сам упустить, а что то упрощено специально, чтобы каждый мог воспроизвести. Что собственно подтверждается двумя абзацами ранее:
Для дальнейшего конфигурирования данного метода авторизации можно использовать root token. Что само по себе не безопасно и не рекомендуется. Хорошей практикой является создавать отдельные учетные записи для каждого инженера или, например, включить авторизацию через LDAP.
Чтобы пользователь смог выполнять действия по дальнейшему конфигурированию, необходимо назначить для него следующую политику.
Естественно, что политики создают админы, и "create" как правило выдавать нужно не везде. Но мы даем разрешению пользователю с админискими правами.
command = "ps ax | grep 'nginx: maste[r]'... можно заменить на pkill
если она есть в контейнере, но нам процесс убивать не нужно, нам нужно отправить ему сигнал
`nginx -s reload`?
вот лишь бы написать, я конечно понимаю что вы не внимательно читали, команда выполняется из контейнера с вольтом, там нет никакого nginx, ровно как и pkill, если смотреть манифест то там контейнерам разрешен shareProcessNamespace: true
это значит что один контейнер может видеть процессы другого в рамках пода, и все что мы можем сделать это взаимодействовать через сигналы, отправка сигнала HUP равна nginx -s reload, но вызвать его напрямую из контейнера с вольтом мы не можем.
Не разобравшись в теме, еще и минусят карму, вот зачем не понимаю?
Надеюсь вы понимаете почему так? Все дело в том, что у контейнеров в рамках пода разный chroot это значит, что контейнеры не видят файловую систему друг друга, и исполнять бинари из одного контейнера в другом мы физически не можем, но при этом мы можем использовать межпроцессное взаимодействие с помощью сигналов, что и реализовано в темплейте вольта.
ну уж тогда сократить до ps ax | awk '/nginx: maste[r]/{system("kill -HUP "$1}'
Таким образом получается, что для авторизации нашего приложения, нам необходим всего лишь один параметр - это role-id, который сам по себе не является секретным и его утечку в сеть можно пережить и ничего не менять в своей системе при условии, что вы настроили роль правильно и ограничили подсети, откуда этой ролью можно воспользоваться.
То есть любое другое приложение, работающее в той же подсети, сможет авторизоваться, воспользовавшись утекшим role_id?
vault-agent, который позволяет, зная только role-id, авторизоваться и получить token доступа в хранилище
На самом деле при создании approle вы указали bind_secret_id=false
и теперь Vault просто не требует secret_id у всех, кто подключается к этой роли и все дела.
Не важно кто там подключается, agent или curl ;)
Используем Hashicorp Vault для хранения секретов