Kubernetes Secrets, RBAC и Vault
Jump to navigation
Jump to search
1. ConfigMap vs Secret
- ConfigMap: Используется для хранения обычных конфигураций (динамических конфигов). Если менять их внутри имиджа (Dockerfile), придется каждый раз пересобирать имидж. ConfigMap позволяет делать это динамически.
- Secret: Используется для чувствительных данных (пароли, TLS-сертификаты).
- Главное отличие: ConfigMap хранит данные в открытом виде. Secret использует кодирование Base64.
- Критическое замечание: Преподаватель подчеркивает, что Base64 — это не шифрование (encryption), а просто кодирование. Любой, у кого есть доступ к неймспейсу, может легко декодировать секрет одной командой.
2. Типы секретов (Secret Types)
В Kubernetes есть несколько стандартных типов:
- Opaque (Generic): Обычные данные "ключ-значение".
- kubernetes.io/tls: Для хранения сертификатов (нужны два файла:
tls.crtиtls.key). Часто используется с Ingress-контроллерами. - kubernetes.io/dockerconfigjson: Для доступа к приватным Docker-регистрам (например, Nexus или Harbor).
3. Работа с секретами в терминале
Преподаватель в видео выполнял следующие действия:
- Создание секрета из строки (Literal):
kubectl create secret generic secret-1 --from-literal=pass=a1245
- Просмотр секрета в YAML (где виден Base64):
kubectl get secret secret-1 -o yaml
- Декодирование секрета (Linux way):
<pre
echo "ЗНАЧЕНИЕ_ИЗ_YAML" | base64 -d
- Создание секрета из файла:
kubectl create secret generic db-secret --from-file=db.properties
4. Доступ к приватным регистрам (Docker Registry Secret)
Если имидж лежит в приватном Nexus или Harbor, Kubernetes не сможет его скачать без пароля.
- Решение 1: Создать секрет типа
docker-registryи указать его в деплойменте в полеimagePullSecrets. - Решение 2 (DevOps way): Настроить логин прямо на уровне Container Runtime (на воркер-нодах), чтобы не прописывать секрет в каждом манифесте.
5. Безопасность и HashiCorp Vault
Так как стандартные секреты K8s не очень безопасны (Base64 легко взломать), профессионалы используют Vault:
- Sidecar-контейнер (Vault Agent): Рядом с основным приложением в поде запускается агент. Он берет токен, идет в Vault, забирает пароль и подкладывает его приложению.
- TTL (Time To Live): Токены в Vault живут недолго (например, 15 минут), что гораздо безопаснее статичных паролей.
6. RBAC (Role-Based Access Control)
Это система управления доступом. Она отвечает на вопрос: "Кто и что может делать?".
- Authentication (Кто ты?): Проверка сертификата или токена.
- Authorization (Что тебе можно?): Проверка прав (RBAC).
- Admission Control: Финальная проверка (например, запрет на запуск подов без лимитов ресурсов).
Основные объекты RBAC:
- Role / ClusterRole: Список правил (например: можно только "геттить" поды).
- RoleBinding / ClusterRoleBinding: Связка "Роль + Пользователь/Сервис-аккаунт".