Салют! Меня зовут Сулейман, и я Senior Software Engineer с более чем 10 годами опыта в программировании. Я разрабатываю веб-сервисы, способные масштабироваться и выдерживать высокие нагрузки, а также активно участвую в open source проектах, публикую статьи, связанные с разработкой, и видео по решению алгоритмических задач, a еще пишу статьи в медиа вАЙТИ. Я сертифицированный Kubernetes Application Developer (CKAD), и мой опыт охватывает различные сферы разработки: от бэкенда и фронтенда до DevOps и разработки Android-приложений.

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

Зачем нужны ConfigMaps и Secrets?

Когда приложения разворачиваются в кластере, они могут нуждаться в определенных конфигурациях, таких как URL базы данных, API-ключи или любые другие параметры, которые варьируются в зависимости от окружения (development, production и т. д.).

Что такое ConfigMap?

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

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

• URL внешнего API

• Конфигурации сервисов

• Различные настройки для логирования

Что такое Secret?

Secret — это объект Kubernetes, предназначенный для хранения чувствительных данных, таких как пароли, ключи шифрования и API-токены. Он позволяет безопасно передавать такие данные в Pod’ы, защищая их от утечек и неправильного доступа.

Основное отличие от ConfigMap заключается в том, что данные в Secret хранятся в закодированном виде (Base64), и Kubernetes накладывает строгие ограничения на их доступ и использование.

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

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

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  service_url: "https://api.example.com"
  timeout: "30"

Здесь:

• service_url — это адрес сервиса.

• timeout — время ожидания в секундах.

Чтобы создать этот ConfigMap в кластере, можно использовать команду:

kubectl apply -f configmap.yaml

Использование ConfigMap в Pod’ах

Теперь мы можем использовать данные ConfigMap в Pod’ах. Сделать это можно двумя способами:

1. Подключение конфигураций через переменные среды.

2. Монтирование конфигураций в виде файлов.

Использование ConfigMap через переменные среды:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mycontainer
    image: myapp:1.0
    env:
    - name: SERVICE_URL
      valueFrom:
        configMapKeyRef:
          name: app-config
          key: service_url
    - name: TIMEOUT
      valueFrom:
        configMapKeyRef:
          name: app-config
          key: timeout

Здесь мы используем значения service_url и timeout из ConfigMap как переменные среды для контейнера.

Монтирование ConfigMap в виде файлов:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mycontainer
    image: myapp:1.0
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config
  volumes:
  - name: config-volume
    configMap:
      name: app-config

Это позволит получить доступ к данным ConfigMap как к файлам внутри контейнера. Каждый ключ из ConfigMap будет представлен отдельным файлом, где имя файла соответствует ключу, а содержимое файла — значению этого ключа.

Создание и использование Secrets

Создадим Secret для хранения API-ключа.

apiVersion: v1
kind: Secret
metadata:
  name: api-secret
data:
  api_key: dXNlcm5hbWU6cGFzc3dvcmQ=

Значение ключа должно быть закодировано в Base64. Чтобы закодировать данные, можно использовать команду:

echo -n "username:password" | base64

Команда вернет строку, которую можно использовать в секции data.

Использование Secret в Pod’ах

Подобно ConfigMap, Secret может быть использован как переменные среды или в виде файлов.

Использование Secret через переменные среды:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mycontainer
    image: myapp:1.0
    env:
    - name: API_KEY
      valueFrom:
        secretKeyRef:
          name: api-secret
          key: api_key

Здесь переменная API_KEY содержит значение из секрета.

Монтирование Secret в виде файлов:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mycontainer
    image: myapp:1.0
    volumeMounts:
    - name: secret-volume
      mountPath: /etc/secret
  volumes:
  - name: secret-volume
    secret:
      secretName: api-secret

В этом случае в контейнере будут созданы файлы внутри директории /etc/secret, где имя каждого файла соответствует ключу из Secret, а содержимое файла — расшифрованному значению этого ключа.

Безопасность и управление Secrets

Хотя Secrets хранятся в закодированном виде (Base64), это не является надежным способом шифрования. Для обеспечения максимальной безопасности рекомендуется:

• Использовать шифрование на уровне etcd.

• Ограничить доступ к Secret’ам с помощью ролей и правил доступа (RBAC).

• Использовать специализированные инструменты для управления секретами, такие как HashiCorp Vault или AWS Secrets Manager.

Лучшая практика управления ConfigMaps и Secrets

1. Разделение конфигурации и кода: ConfigMaps и Secrets позволяют отделить конфигурацию приложения от кода, что упрощает управление и развертывание.

2. Использование нескольких окружений: для разных окружений (например, development и production) можно использовать разные ConfigMap и Secret.

3. Минимизация данных: храните в ConfigMaps и Secrets только необходимые данные. Лишняя информация может привести к утечке данных или усложнить управление.

4. Шифрование секретов: всегда используйте шифрование для хранения чувствительных данных.

5. Ограничение доступа: используйте RBAC для контроля доступа к Secret и ConfigMap. Не давайте Pod’ам доступ к секретам, если это не требуется.

6. Частая ротация ключей: секреты и ключи доступа должны регулярно меняться. Это снижает вероятность их компрометации.

Заключение

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

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

вАЙТИ — DIY-медиа для ИТ-специалистов. Делитесь личными историями про решение самых разных ИТ-задач и получайте вознаграждение.

Еще больше статей

#Научпоп
Программисты на службе у науки: как мы изобрели ПО для моделирования плазмы
Рассказываю о работе программиста на стыке науки и разработки

Как российская компания стала одним из мировых лидеров на рынке роботов-промоутеров
С роботами-промоутерами мы уже встречаемся в МФЦ, торговых центрах и на выставках. Россия на этом рынке — в числе лидеров.

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

#Хранение данных
Основные ошибки хранения персональных данных: как их избежать
Несколько советов, которые помогут навести порядок в большом массиве персональных данных.

Как перенести 2 ТБ данных из одного дата-центра в другой при низкой скорости интернета
Что нужно сделать, чтобы быстро объединить два кластера MongoDB, которые работают в разных ЦОД.

Защита личных данных пациентов. Как работать с конфиденциальными медданными
Как работает с личными данными компания, которая проводит дистанционные медицинские осмотры.