Когда вы используете функцию пакета зашифрованных данных для Chef, как вы развертываете ключ на многих серверах? Если вы поместите его в рецепт, любой, кто имеет доступ к любому из серверов или клиентов Chef, сможет извлечь ключ и потенциально расшифровать любой из тегов данных.
Как сделать так, чтобы ключ был на машинах, которые в нем нуждаются, но в то же время в безопасности от любого шпионящего средства?
К сожалению, вы не так много можете сделать, поскольку ключ должен быть где-то в узле Chef в виде обычного текста. Если у кого-то есть оболочка или локальный доступ к ящику, он может прочитать ключ (и).
Чтобы немного смягчить ситуацию, я добавляю к своему базовому узлу следующее (т.е. некоторый рецепт или роль, общие для всех узлов):
directory "/etc/chef/keys" do
mode 0700
owner "root"
group "root"
end
и какой бы механизм распределения ключей у вас ни был, ключи помещаются в это место. Разрешения и владение предотвращают чтение ключей, если кто-то забудет указать правильные разрешения для файла ключа.
На мой взгляд, зашифрованные пакеты данных больше предназначены для защиты ключевого материала от чтения в системе управления версиями, а не как функция безопасности на самих узлах Chef.
Мои EDB разделены по:
Мы загружаем все ключи со специальным суффиксом в каждый новый экземпляр EC2 по мере его загрузки, а затем удаляем все ключи, которые не использовались ни в одном из рецептов в run_list в конце первого запуска chef-client (который будет прямо в момент запуска экземпляра.)
Все файлы загружаются как владелец и группа «root» и только с разрешениями на чтение.
Каждый рецепт, который использует EDB, генерирует имя EDB и имя файла ключа во время выполнения рецепта путем объединения 'edb_' + окружение узлов + имя рецепта / элемента + '.key', а затем ищет ключ по этому имени . (Если его не существует, по умолчанию выдается исключение.)
Таким образом, для нашего сервера couchdb, выполняющего роль под названием 'couch', чтобы получить учетные данные, которые мы используем для пользователей-администраторов в среде разработки, рецепт ищет ключ с именем 'edb_dev_couch.key'
Затем он ищет в пакете данных с именем edb_dev элемент с именем couch_credentials.
Для управления ключами я сейчас использую простой подход:
Надеюсь, это ограничивает время, в течение которого ключи вне области действия одного узла становятся восприимчивыми до тех пор, пока машина не будет загружена и не получит первый запуск chef_client.
Это наш первый раунд тестирования защиты ключей, но пока он отвечает нашим текущим потребностям, так как не позволяет одному рутированному серверу разработки немедленно получить доступ к любым другим учетным данным серверов, которые хранятся в EDB.
Чтобы поддерживать один рецепт в конце каждого списка запусков, я использую задание exec ножа, которое гарантирует, что этот рецепт delete_keys является в точности последним рецептом на каждом узле.
Мои ключи встроены в AMI, которые мы используем, или изображения, которые мы используем. Я не делаю это как часть начальной загрузки, так как эти данные небезопасны. Обычно вы можете видеть данные в журналах и тому подобном, если не будете осторожны.