Когда вы используете функцию зашифрованных пакетов данных для 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», для получения учетных данных, которые мы используем для администраторов (пользователей) в среде dev, рецепт ищет ключ с именем «edb_dev_couch.key».
Затем он ищет в пакете данных с именем «edb_dev» предмет с именем «couch_credentials».
Для управления ключами в настоящее время я использую простой подход:
Надеемся, что это ограничивает время, в течение которого ключи вне области действия одного узла восприимчивы до тех пор, пока машина не будет загружена и не выполнит первый запуск chef_client.
Это наш первый раунд тестирования защиты ключей, но пока он отвечает нашим текущим потребностям, поскольку не позволяет одному корневому dev-серверу иметь возможность немедленного доступа к любым другим учетным данным сервера, хранящимся в EDB.
Чтобы сохранить один рецепт в конце каждого списка выполнения, я использую задание exec, которое гарантирует, что этот рецепт delete_keys является точно последним рецептом на каждом узле.
Мои ключи запечены в AMI, которые мы используем, или в изображениях, которые мы используем. Я не делаю это как часть начальной загрузки, так как эти данные не защищены. Обычно вы можете видеть данные в журналах и тому подобное, если не будете осторожны.