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

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

env:
- name: DB_PASSWORD
  value: password

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

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

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

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

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

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


person hohner    schedule 26.08.2015    source источник
comment
@larsks Но разве файл определения секрета не будет хранить учетные данные в виде открытого текста? Или в base64, который можно было бы легко расшифровать.   -  person hohner    schedule 26.08.2015
comment
Да, и я неправильно понял тот факт, что вы уже использовали этот API. Так что, неважно...   -  person larsks    schedule 26.08.2015
comment
Насколько я понимаю, Secrets — это способ передачи конфиденциальной информации, но у него есть свои ограничения. Тем не менее, это лучше, чем просто передавать конфиденциальную информацию непосредственно в переменные ENV.   -  person MrE    schedule 26.08.2015
comment
Ре. другие способы: stackoverflow.com/questions/30749899 /   -  person Sergei Rodionov    schedule 26.08.2015


Ответы (2)


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

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

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

person lavalamp    schedule 31.08.2015
comment
Ну, вот почему я не уверен, что это хорошая идея: 1. Я думаю, что размещение секретов в отдельных файлах немного неуклюже, так как большинство приложений так не работают с конфиденциальными данными. Вам нужно будет написать дополнительную логику загрузки, что неудобно. 2. Монтировать файлы томов и помещать их в env слишком статично. Я бы предпочел, чтобы конфигурация моего приложения динамически сохранялась в etcd, используя crypt для шифрования. 3. С точки зрения безопасности, я думаю, что лучше требовать дополнительное время и знания для доступа, чем давать их им в виде открытого текста. - person hohner; 03.09.2015
comment
Секрет может состоять только из 256 символов... так что, может быть, он хорошо работает для паролей и ключей, но не для таких вещей, как сертификаты и т.д..., которые могут быть намного длиннее. - person MrE; 03.09.2015
comment
Секретный ключ может состоять только из 256 символов; нет ограничений на секретные данные. - person lavalamp; 04.09.2015
comment
Итак, что касается пунктов Хохнера: 1: вы должны написать логику запуска, несмотря ни на что. 2: Если вы можете изменить конфигурацию без перезапуска приложения, то да, вы, вероятно, захотите управлять этим самостоятельно; это не нормальный случай. 3: вы всегда даете что-то в виде открытого текста, будь то ключ или сами данные напрямую. - person lavalamp; 04.09.2015

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

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

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

person Soren    schedule 05.09.2015