Хранение конфигурации и секретов

Я планирую обернуть наше приложение (которое состоит из нескольких микросервисов) в диаграмму.

Прямо сейчас для каждого микросервиса мы храним секреты и значения конфигурации, жестко запрограммированные непосредственно в наших deployment.yaml файлах, в ...containers[].env. Все наши файлы yaml хранятся в репозитории git.

Я заметил, что в некоторых популярных диаграммах используется ConfigMap (1, 2) и Secret (1, 2) Объекты Kubernetes для хранения значений конфигурации и секретов соответственно.

Каковы преимущества использования ConfigMap и Secret объектов, будь то эргономика и/или усиление безопасности?

Я уже мог создавать шаблоны из всех yaml файлов, которые у нас есть, делая все жестко заданные значения настраиваемыми и, таким образом, разрешаемыми во время компиляции шаблона helm.

Однако, поскольку Kubernetes предоставляет специализированные объекты для хранения конфигурации и секретов, я хочу оправдать добавление файлов шаблонов configmap.yaml и secrets.yaml, а также добавление ссылок на них из существующих файлов deployment.yaml.


kubernetes kubernetes-helm configuration
person gmile    schedule 07.06.2017    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Configmaps — это очень общие файлы конфигурации. Они могут состоять из списка пар ключ-значение, но они также могут быть универсальными файлами. Например, вы можете сохранить файл конфигурации nginx nginx.conf в configmap и загрузить его в нужное место, чтобы демон nginx мог его прочитать.

Предполагается, что секреты используются для хранения конфиденциальных данных, к сожалению, сейчас секреты не шифруются, они просто закодированы на основе 64. Так что, хотя это помогает вам удалить жестко закодированные незашифрованные значения из ваших манифестов, это совсем не помогает с шифрованием. Это должно стать лучше в v1.7

Вы можете настроить переменные среды в манифесте развертывания, чтобы они указывали на определенные значения в секреты или configmaps. Оба также легко генерируются с помощью kubectl, например:

  • kubectl create secret generic foobar --from-literal=password=foobar
  • kubectl create configmap foobar --from-file=foobar.conf

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

Лично, когда мне нужно загрузить файл в Pod, я использую configmap, а когда я имею дело с чувствительной переменной env, я использую секрет, имея в виду, что он не зашифрован.

person Sebastien Goasguen    schedule 07.06.2017