Секреты Кубернетов против ConfigMaps

Использовали тайны Кубернетов. Теперь у нас есть ConfigMaps.

Каков предпочтительный путь вперед - секреты или карты конфигурации?

P.S. После нескольких итераций мы стабилизировались по следующему правилу:

  • configMaps на один домен решения (может использоваться совместно с микросервисами в домене, но в конечном итоге это однотипные записи конфигурации)

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

Ответы

Ответ 1

Я являюсь автором обеих этих функций. Идея состоит в том, что вы должны:

  • Используйте секреты для вещей, которые на самом деле секретны, как ключи API, учетные данные и т.д.
  • Использовать конфигурационную карту для несекретных конфигурационных данных

В будущем, вероятно, будут некоторые отличия в секретах, таких как ротация или поддержка для поддержки секретного API w/HSM и т.д. В целом нам нравятся API-интерфейсы на основе намерений, и намерение, безусловно, отличается для секретных данных по сравнению с обычным старых конфигураций.

Надеюсь, что это поможет.

Ответ 2

Одно заметное отличие в реализации состоит в том, что kubectl apply -f:

  • ConfigMaps "неизменны", если данные не изменились.
  • Секреты всегда "настраиваются" - даже если файл не изменился

Ответ 3

И ConfigMaps, и Secrets хранят данные в виде пары ключ-значение. Основное отличие заключается в том, что секреты хранят данные в формате base64, а ConfigMaps хранит данные в виде простого текста.

Если у вас есть важные данные, такие как ключи, пароли, учетные данные сервисных учетных записей, строка подключения к БД и т.д., То вам всегда следует использовать Секреты, а не Конфиги.

И если вы хотите выполнить настройку приложения с использованием переменных среды, которые вы не хотите хранить в секрете/скрытых, таких как тема приложения, URL-адрес базовой платформы и т.д., То вы можете выбрать ConfigMaps.