Заполнение докерных контейнеров с конфиденциальной информацией с использованием кубернетов

Question

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

env: 
- name: DB_PASSWORD 
    value: password 

, которые затем доступны внутри контейнера Докер в качестве переменной в $DB_PASSWORD окружающей среды. Все довольно легко.

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

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

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

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

Есть ли еще какие-либо способы для заполнения контейнеров Docker секретной информацией безопасным способом?

Answer 1

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

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

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

Answer 2

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

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

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