Безопасное использование ConfigMaps в Kubernetes

ConfigMaps — это объект API, используемый в Kubernetes для хранения данных в парах ключ-значение. По сути, это словарь, содержащий параметры конфигурации. Некоторые данные, которые можно ожидать найти в ConfigMap, включают имена хостов, публичные учетные данные, строки подключения и URL-адреса.

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

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

В этой статье рассматривается принцип работы ConfigMaps, способы безопасного использования ConfigMaps, а также некоторые случаи использования, когда нам необходимо обратиться к другим, более безопасным хранилищам данных.

ConfigMaps в Kubernetes

Прежде чем мы рассмотрим, как использовать ConfigMaps, давайте изучим технические детали того, как работают ConfigMaps и какую роль они играют в Kubernetes.

Принцип работы ConfigMaps

ConfigMaps хранит пары ключ-значение в виде простых и двоичных данных, что отличает его от других объектов Kubernetes, использующих поля spec. ConfigMaps имеет возможность хранить двоичные данные в виде строк с кодировкой base64, а обычные данные — в виде последовательностей байтов UTF-8.

Кластер может получить доступ к ConfigMaps следующими способами:

  • Монтирование их как тома данных.
  • Подгруппы в том же пространстве имен Kubernetes получают к ним удаленный доступ.
  • Отделить их от Pods и позволить другим компонентам кластера Kubernetes использовать их.

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

При работе с ConfigMaps необходимо учитывать их ограниченный размер — 1 МБ. Если у нас есть более обширные наборы данных, следует рассмотреть другие варианты хранения данных, такие как базы данных, отдельные файловые монтирования или файловые сервисы.

Роль ConfigMaps

Наиболее важная роль ConfigMaps — сделать приложения переносимыми, отделив код приложения от параметров конфигурации. Такое разделение позволяет эффективно мигрировать из среды разработки в тестовую среду и, в конечном итоге, в производственную среду.

Давайте рассмотрим пример того, как ConfigMap может помочь нам при работе с Kubernetes. Для этой демонстрации предположим, что мы создаем приложение локально и собираемся развернуть его с помощью управляемых поставщиков услуг Kubernetes.

Чтобы получить доступ к базе данных локально, мы должны установить переменную окружения DATABASE_HOST на localhost или 127.0.0.1. При миграции в производственную среду мы должны изменить значение этой переменной на такое, которое открывает доступ к компоненту базы данных.

Безопасное использование ConfigMaps

Прежде чем мы начнем, приведем предварительные условия для создания ConfigMap в локальном кластере Kubernetes:

  • Последняя версия Docker Desktop
  • Minikube
  • Kubectl
  • Редактор кода, например VS Code.

В этой демонстрации мы рассмотрим, как создать ConfigMap в YAML и смонтировать его как том. Этот метод позволяет нам создать его так же, как мы создаем ресурс Kubernetes.

Создайте файл с именем mongo-config.yaml и добавьте следующий код:

kind: ConfigMap
apiVersion: v1
metadata:
  name: test-configmap
data:
  # Setting the configuration as key-value properties
  database: mongodb
  database_uri: mongodb://localhost:8080
keys: |
  image.public.key=554
  rsa.public.key=36
Войти в полноэкранный режим Выйти из полноэкранного режима

Затем создайте ConfigMap из вышеуказанного файла с помощью следующей команды:

kubectl apply -f mongo-config.yaml
Войти в полноэкранный режим Выйти из полноэкранного режима

Теперь давайте посмотрим, как использовать ConfigMap. В этой демонстрации используется созданная выше ConfigMap с переменными окружения. Чтобы использовать ConfigMap, добавьте свойство envFrom в YAML Pod, как показано в приведенном ниже коде:

kind: Pod
apiVersion: v1
metadata:
  name: pod-variables-env
spec:
  containers:
    - name: configmap-var
      image: nginx:1.7.9
      envFrom:
        - configMapRef:
          name: test-configmap
Войти в полноэкранный режим Выйти из полноэкранного режима

В приведенном выше фрагменте кода мы использовали envFrom для доступа к информации ConfigMap из контейнера.

Последний шаг — прикрепить ее к Pods, которые мы создаем, выполнив команду ниже:

kubectl exec -it pod-variables-env sh
Войти в полноэкранный режим Выйти из полноэкранного режима

Это сделает ConfigMap доступной для контейнеров в качестве переменной окружения.

Секреты в Kubernetes

Секреты часто представляются как безопасная альтернатива ConfigMap, поскольку у них есть несколько общих черт:

  • Они используют пары ключ-значение для хранения данных.
  • Подсыпки могут использовать их как файлы в томе.
  • Они могут использоваться как переменные окружения (хотя это не очень хорошая идея).
  • Они представляют собой типы объектов, доступ к которым осуществляется с помощью сервера API.
  • Они оба имеют ограничение в 1 МБ и поэтому не подходят для больших данных.

Secrets — это объекты, предназначенные для шифрования и хранения конфиденциальных данных в Kubernetes. Некоторые из данных, которые мы должны хранить в Secrets, включают пароли, ключи API, токены, строки подключения к базе данных и так далее. Они позволяют отделить конфиденциальные данные от кода приложения. Такое разделение снижает риск раскрытия конфиденциальных данных, что может подвергнуть опасности кластер и приложение. Единственное, для чего не следует использовать Secrets, — это переменные окружения. Как пишут Лиз Райс и Майкл Хаузенбласбокк в своей книге «Безопасность Kubernetes:

  • env vars часто сбрасываются в журналы при сбоях/ошибках
  • kubectl describe pod раскрывает значения env var в свободном текстовом виде
  • docker inspect раскрывает значения env var в свободном тексте

Существует несколько типов секретов, в зависимости от того, какие данные мы хотим сохранить в тайне. Наиболее часто используемым типом является Opaque, который работает с произвольными данными, определенными пользователем. Для базовой аутентификации мы используем тип basic-auth.

По умолчанию секреты не шифруются и хранятся в etcd, серверном хранилище API. Любой человек, имеющий доступ к API, может получить доступ и изменить секреты. Чтобы ограничить доступ к ним, необходимо сделать следующее:

  • Включить шифрование секретных данных в состоянии покоя (многие, если не все, управляемые поставщики K8 делают это для вас в качестве опции при создании кластера).
  • Включите и настройте правила RBAC для ограничения чтения и редактирования.
  • Ограничьте создателей секретов с помощью RBAC.

ConfigMaps против Secrets

Хотя ConfigMaps и Secrets имеют общие черты, это не одно и то же — и оба они лучше всего подходят для определенных случаев использования, определяемых нашими потребностями безопасности.

Основное различие между ConfigMaps и Secrets заключается в конфиденциальности содержащихся в них данных. Secrets обфусцирует данные с помощью кодировки base64, в то время как данные ConfigMaps хранятся в виде обычного текста. Обратите внимание, что в ConfigMaps можно хранить и обычный текст в виде строк с кодировкой base64.

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

Когда использовать ConfigMaps

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

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

Вы можете легко отобразить данные, содержащиеся в ConfigMaps, выполнив команду kubectl describe configmaps <name>. Мы также можем легко редактировать эти данные, поскольку они отображаются в виде обычного текста. Хотя эти возможности позволяют легко изменять конфигурации в зависимости от среды (разработка, тестирование или производство), они также не подходят для работы с конфиденциальными данными. Чувствительные данные следует хранить в Kubernetes Secrets, чтобы их можно было зашифровать и ограничить доступ к ним.

Когда использовать Secrets

Как и ConfigMaps, Secrets позволяет отделить данные от кода приложения. Это позволяет нам предотвратить раскрытие конфиденциальных данных во время создания или изменения Pod.

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

Давайте сравним два фрагмента кода. Первый демонстрирует, как ConfigMap работает с данными, а второй — как Secret работает с данными.

Вот как выглядит ConfigMap:

db-configmap.yaml

apiVersion: v1
kind: ConfigMap
# ConfigMap data
metadata:
  name: employee-database-conf
  namespace: default
# Database configurations
data:
  server.host: "10.07.11.653"
  server.port: "3030"
  db.name: employees_data
Вход в полноэкранный режим Выход из полноэкранного режима

Приведенный выше YAML-файл ConfigMap содержит нечувствительные данные о подключении к базе данных — хост сервера, порт сервера и имя базы данных.

Вот как будет выглядеть файл Secrets:

db-secret.yaml

apiVersion: v1
kind: Secret
# Secret Data
metadata:
  name: employee-database-auth
  namespace: default
# The type of Secret 
type: kubernetes.io/basic-auth
# Secret data
stringData:
  username: dGhlYWRtaW4= //theadmin
  password: YWRtaW5wYXNz //adminpass
Войти в полноэкранный режим Выйти из полноэкранного режима

В приведенном выше YAML-файле Secret тип Secret указан как basic-auth, который обрабатывает основные учетные данные авторизации. Строка stringData содержит данные, которые должны быть приватными. В данном случае это имя пользователя и пароль.

В приведенном выше гипотетическом случае Secrets помог нам сохранить имя пользователя и пароль к базе данных в тайне. Это также гарантирует отсутствие риска раскрытия этой информации при создании или изменении Pod.

Безопасность конфигурации Kubernetes

ConfigMap — это объект API в Kubernetes, используемый для хранения нечувствительных данных конфигурации в парах ключ-значение. По умолчанию они хранят данные в виде обычного текста и позволяют отделить код приложения от конфигураций. Secrets — это также объект API в Kubernetes, используемый для шифрования и хранения конфиденциальных данных конфигурации в парах ключ-значение. Однако они снижают риск раскрытия конфиденциальных данных, которые могут подвергнуть опасности кластер и приложение.

Чтобы создать безопасный кластер Kubernetes, в котором код приложения и конфигурации разделены, убедитесь, что вы храните конфиденциальные данные в Secrets, а нечувствительные конфигурации — в ConfigMaps. Кроме того, очень важно включить RBAC для ограничения доступа к ConfigMaps и Secrets. Это снижает риск несанкционированного доступа или изменения конфигурации.

Оцените статью
devanswers.ru
Добавить комментарий