Заполнение контейнеров Docker конфиденциальной информацией с использованием kubernetes

Question

У меня есть модуль, который запускает контейнеры, которые требуют доступа к конфиденциальной информации, такой как ключи API и пароли БД. Прямо сейчас эти конфиденциальные значения встроены в определения контроллера следующим образом:

env:
- name: DB_PASSWORD
  value: password

которые затем доступны внутри контейнера Docker как $DB_PASSWORD переменная окружения. Все довольно просто.

Но, читая их документацию по секретам, они прямо заявляют, что включение конфиденциальных значений конфигурации в ваше определение нарушает передовой опыт и потенциально является проблемой безопасности. Единственная другая стратегия, о которой я могу подумать, заключается в следующем:

• создать ключ OpenPGP для сообщества пользователей или пространства имен
• используйте crypt для установки значения конфигурации в etcd (который зашифрован с использованием закрытого ключа)
• создайте секрет kubernetes, содержащий закрытый ключ, вот так
• связать этот секрет с контейнером (это означает, что закрытый ключ будет доступен как монтирование тома), вот так
• когда контейнер запускается, он получает доступ к файлу внутри монтирования тома для закрытого ключа и использует его для расшифровки значений conf, возвращаемых из etcd
• затем его можно включить в confd, который заполняет локальные файлы в соответствии с определением шаблона (например, файлы конфигурации Apache или WordPress)

Это кажется довольно сложным, но более безопасным и гибким, так как значения больше не будут статичными и хранятся в виде открытого текста.

Итак, мой вопрос, и я знаю, что он не совсем объективен, является ли это абсолютно необходимым или нет? Только администраторы смогут просматривать и выполнять определения RC в первую очередь; так что, если кто-то нарушил хозяина kubernetes, у вас есть другие проблемы для беспокойства. Единственное преимущество, которое я вижу, состоит в том, что нет никакой опасности, что секреты будут переданы в файловую систему в виде открытого текста...

Существуют ли другие способы безопасного наполнения контейнеров Docker секретной информацией?

Answer 1

Если у вас нет много мегабайт конфигурации, эта система звучит излишне сложно. Предполагается, что вы просто поместите каждую конфигурацию в секрет, и модули, нуждающиеся в конфигурации, могут монтировать этот секрет как том.

Затем вы можете использовать любой из множества механизмов для передачи этой конфигурации в вашу задачу, например, если это переменные среды source secret/config.sh; ./mybinary это простой способ.

Я не думаю, что вы получаете дополнительную безопасность, храня закрытый ключ как секрет.

Answer 2

Я лично решил бы использовать удаленный менеджер ключей, чтобы ваше программное обеспечение могло получить доступ через сеть через соединение HTTPS. Например, Keywhiz или Vault, вероятно, будут отвечать всем требованиям.

Я бы размещал менеджер ключей в отдельной изолированной подсети и настраивал брандмауэр так, чтобы он разрешал доступ только к IP-адресам, для которых, как я ожидал, понадобятся ключи. И KeyWhiz, и Vault поставляются с механизмом ACL, так что вам, возможно, вообще не нужно ничего делать с брандмауэрами, но это не повредит, если учесть это - однако ключ здесь в том, чтобы разместить менеджер ключей в отдельной сети, и возможно даже отдельный хостинг-провайдер.

Ваш локальный файл конфигурации в контейнере будет содержать только URL-адрес службы ключей и возможные учетные данные для извлечения ключа из менеджера ключей - учетные данные будут бесполезны для злоумышленника, если он не соответствует адресам ACL/IP.