Кажется, есть небольшая проблема "курицы и яйца" с пароли к менеджеры паролей, такие как Hashicorp Vault для Linux.
Исследуя это для некоторых серверов Linux, кто-то умный спросил: «Если мы храним все наши секреты в службе хранения секретов, где мы храним секрет доступа к этой службе хранения секретов? В нашей службе хранения секретов?»‡
Я был поражен, так как нет смысла использовать отдельную службу хранения секретов, если все серверы Linux, на которых я буду хранить секреты, так или иначе, имеют свой токен доступа.
Например, если я перемещаю свои секреты в Vault, разве мне все равно не нужно хранить секреты для доступа к Hashicorp Vault где-нибудь на сервере Linux?
Поговаривают о том, чтобы решить эту проблему творчески и, по крайней мере, сделать все лучше, чем сейчас. Мы можем делать умные вещи, такие как авторизация на основе CIDR или гибридных паролей. Но есть еще и компромисс безопасности. Например, если хакер получит доступ к моей машине, он может попасть в хранилище, если доступ основан на CIDR.
На этот вопрос может не быть ответа, и в этом случае ответ будет: «Нет, здесь нет общепринятого решения серебряной пули, проявите изобретательность, найдите свои компромиссы, бла-бла-бла»
Я хочу получить ответ на следующий конкретный вопрос:
Есть ли общепринятый способ защиты пароля от удаленного автоматизированного хранилища секретов, такого как Hashicorp Vault, на современных серверах Linux?
Очевидно, что об открытом тексте не может быть и речи.
Есть ли на это канонический ответ? Я вообще спрашиваю об этом в нужном месте? Я тоже рассматривал security.stackexchange.com, но это казалось специфичным для путь хранения секретов для серверов Linux. Я понимаю, что это может показаться слишком общим или основанным на мнении, поэтому я приветствую любые предложения по редактированию, которые могут вам понадобиться, чтобы этого избежать.
‡Мы смеемся, но ответ, который я получаю здесь, вполне может быть «в хранилище». : / Например, сервер Jenkins или что-то еще имеет 6-месячный отзывный пароль, который он использует для генерации одноразовых токенов, которые затем они могут использовать для получения собственного небольшого эфемерного (ограниченного сеансом) пароля, сгенерированного из Vault, который предоставляет им сегмент информации.
Что-то вроде этого, похоже, в том же духе, хотя это было бы только частью решения: Управление паролями служб с помощью Puppet
// Прежде всего, обсуждаемая здесь проблема выходит за рамки простой доставки секрета 0 или того, что они называют «безопасным введением» на языке ops.
Скорее, речь идет о сохранении однажды полученного секрета.
У меня нет серебряной пули на этот счет. Но есть несколько вариантов глубокоэшелонированной защиты:
