Vault with k8s v2: различия между версиями
Материал из noname.com.ua
Перейти к навигацииПерейти к поискуSirmax (обсуждение | вклад) |
Sirmax (обсуждение | вклад) |
||
Строка 135: | Строка 135: | ||
==Собственно настройка Vault== |
==Собственно настройка Vault== |
||
+ | |||
+ | Для настройки Vault потребуется токен с рутовыми правами. |
||
+ | * Токен для примера (отличается для каждой инсталляции Vault) |
||
+ | * В случае https - требуется добавить CA в доверенные (если не добавлен до того) |
||
+ | <PRE> |
||
+ | export VAULT_TOKEN="s.pRFenxR9CANXqLtGI0b6fvy3" |
||
+ | export VAULT_ADDR="https://vault.domain.tld:8200" |
||
+ | </PRE> |
Версия 13:06, 9 февраля 2022
Авторизация K8S POD в Vault
Постановка задачи
- Получать "секреты" из Vault при этом не передавая в POD пароли, токены или другую секретную информацию
Предварительны условия
- Установлен и настроен Vault
(базовая настройка - https://noname.com.ua/mediawiki/index.php/Vault_Basic_Setup)
- кластер Kubernetes установлен и настроен
- kubectl настроен для работы с кластером
Принципы работы
- Создается один или несколько Service Account
- POD запускается в определенном Service Account
- POD может воспользоваться токеном этого Service Account
- В качестве входных данных POD получает НЕ СЕКРЕТНУЮ информацию
- Адрес Vault в переменной окружения VAULT_ADDR
- Имя роли в переменной окружения VAULT_K8S_ROLE
- POD авторизуется в VAULT под ролью переданной в переменной VAULT_K8S_ROLE используя для этого JWT принадлежащий Service Account
- Vault настроен на проверку прав токена PODs в API K8S (Сам процесс VAULT использует ДРУГОЙ сервисный аккаунт, отличный от того под которым запускается POD для проверки токена PODa)
- После успешной авторизации POD может читать "секреты" из VAULT согласно политик которые привязаны к роле (политики и роли тут - это объекты в Vault)
Настройка Vault
Настройка со стороны k8s
Namespace
- Создать пространство (имен если не создано)
- Имя пространства имен выбрано произвольно
- kubectl apply -f kilda-namespace.yaml
- Содержимое kilda-namespace.yaml:
--- apiVersion: v1 kind: Namespace metadata: name: kilda
- проверка: kubectl get namespaces
NAME STATUS AGE default Active 56d kilda Active 7s kube-public Active 56d kube-system Active 56d metallb-system Active 56d ...
Сервисный аккаунт
- Это аккаунт с которым Vault подключается к API k8s для валидации JWT
- Этот аккаунт отличается от того который используется для запуска POD
- Создается в правильном пространстве имен (в частном случае может использоваться default)
- Имя аккаунта выбрано произвольно
- kubectl apply -f kilda-vault-token-review-service-account.yaml
- Содержимое файла kilda-vault-token-review-service-account.yaml:
--- apiVersion: v1 kind: ServiceAccount metadata: name: kilda-vault-token-review-service-account namespace: kilda
- Проверка: kubectl get serviceAccount --namespace kilda
NAME SECRETS AGE default 1 9m12s kilda-vault-token-review-service-account 1 3m37s
Права сервисного аккаунта
- Для того что б аккаунт мог проверить JWT у других сервисных аккаунтов ему назначается ClusterRole system:auth-delegator
Важно: Назначить права нужно в 2 пространствах имен
Если назначить только в kilda-namespace то прав для проверки JWT недостаточно (что совершенно не очевидно из конфигурации)
kilda-namespace
- Права назначаются на аккаунт созданный ранее: kilda-vault-token-review-service-account в kilda-namespace
- kubectl apply -f kilda-vault-token-review-service-account-role-binding-in-kilda-namespace.yaml
- Содержимое файла kilda-vault-token-review-service-account-role-binding-in-kilda-namespace.yaml:
--- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: kilda-vault-token-review-service-account-role-binding-in-kilda-namespace namespace: kilda-namespace roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:auth-delegator subjects: - kind: ServiceAccount name: kilda-vault-token-review-service-account namespace: kilda-namespace
default-namespace
- Права назначаются на аккаунт созданный ранее: kilda-vault-token-review-service-account в default-namespace
- kubectl apply -f kilda-vault-token-review-service-account-role-binding-in-default-namespace.yaml
- Содержимое файла kilda-vault-token-review-service-account-role-binding-in-default-namespace.yaml:
--- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: kilda-vault-token-review-service-account-role-binding-in-default-namespace namespace: default roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: system:auth-delegator subjects: - kind: ServiceAccount name: kilda-vault-token-review-service-account namespace: kilda-namespace
Проверка
- Проверить: kubectl get clusterRoleBinding
NAME ROLE ... kilda-vault-token-review-service-account-role-binding-in-default-namespace ClusterRole/system:auth-delegator kilda-vault-token-review-service-account-role-binding-in-kilda-namespace ClusterRole/system:auth-delegator ...
Собственно настройка Vault
Для настройки Vault потребуется токен с рутовыми правами.
- Токен для примера (отличается для каждой инсталляции Vault)
- В случае https - требуется добавить CA в доверенные (если не добавлен до того)
export VAULT_TOKEN="s.pRFenxR9CANXqLtGI0b6fvy3" export VAULT_ADDR="https://vault.domain.tld:8200"