Зачем нужны 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’ах. Сделать это можно двумя способами:
- Подключение конфигураций через переменные среды.
- Монтирование конфигураций в виде файлов.
Использование 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
- Разделение конфигурации и кода: ConfigMaps и Secrets позволяют отделить конфигурацию приложения от кода, что упрощает управление и развертывание.
- Использование нескольких окружений: для разных окружений (например, development и production) можно использовать разные ConfigMap и Secret.
- Минимизация данных: храните в ConfigMaps и Secrets только необходимые данные. Лишняя информация может привести к утечке данных или усложнить управление.
- Шифрование секретов: всегда используйте шифрование для хранения чувствительных данных.
- Ограничение доступа: используйте RBAC для контроля доступа к Secret и ConfigMap. Не давайте Pod’ам доступ к секретам, если это не требуется.
- Частая ротация ключей: секреты и ключи доступа должны регулярно меняться. Это снижает вероятность их компрометации.
Заключение
Kubernetes ConfigMaps и Secrets — это мощные инструменты для управления конфигурациями и секретами приложений в кластере. Они обеспечивают гибкость и безопасность при передаче данных в Pod’ы, а также способствуют лучшему разделению ответственности между конфигурацией и кодом. Бэкенд-разработчики должны уделять особое внимание правильному управлению этими объектами, поскольку их неправильное использование может привести к утечкам данных и снижению безопасности системы.
Эффективное использование ConfigMaps и Secrets помогает создать более гибкую, безопасную и управляемую инфраструктуру, что особенно важно при работе с микросервисами и масштабируемыми приложениями в Kubernetes.
