Vault от HashiСorp — довольно известное open-source-решение для хранения секретов и неплохая альтернатива реализации секретов в Kubernetes. Vault использует свой сайдкар-контейнер на каждом поде, который получает секреты из хранилища и доставляет их в под или же реализует доступ к секретам через csi-драйвер.
Но как быть, если необходимо положить секреты из Vault в секреты Kubernetes? Например, мы хотим хранить и обновлять свой tls-сертификат для ингресса из Vault. Или мы решили использовать gitops и хотим, чтобы в репозитории безопасно хранилось все описание инфраструктуры, в том числе и секретов Kubernetes?
Разберем этот сценарий на практике и реализуем его с помощью vault-secrets-operator.
Установка и настройка Vault. На эту тему написано уже много мануалов, так что подробно останавливаться не буду. Например, можно положиться на официальную документацию установки через helm-чарт в кластер Kubernetes.
С его помощью несложно сделать HA-установку c базой PostgreSQL и настроенным ингрессом. Главное в этом случае — не забыть создать в базе таблицы для HA-режима. После необходимо проинициализировать под командой vault operator init, если хотите вручную распечатывать Vault при перезапусках подов.
Итак, у нас на руках токен доступа, наш Vault настроен и доступен извне. Ставим себе консольную утилиту Vault на десктоп и создаем переменные окружения (у вас, конечно, будут свои значения).
export VAULT_ADDR=https://vault.example.cloud
VAULT_TOKEN=s.cyVpg9kDV10CQt9fEaIhdo
Проверяем статус нашего vault-сервера.
vault status
Key Value
--- -----
Seal Type shamir
Initialized true
Sealed false
Total Shares 5
Threshold 3
Version 1.7.3
Storage Type postgresql
Cluster Name vault-cluster-d487efe3
Cluster ID 11aa752a-d492-8784-6c26-e9a3e05952f9
HA Enabled true
HA Cluster https://vault-0.vault-internal:8201
HA Mode active
Active Since 2021-07-08T09:30:53.565132822Z
Здесь мы также можем обратить внимание на:
Генерируем его для домена site.example.cloud:
openssl req -x509 -newkey rsa:4096 -keyout tls.key -out tls.crt -nodes -days 365 -subj '/CN=site.example.cloud'
Создаем key-value хранилище в Vault и закидываем в него сгенерированный сертификат:
vault secrets enable -path=ingress-tls kv
vault write ingress-tls/site.example.cloud tls.crt=@tls.crt tls.key=@tls.key
На всякий случай проверим наш сертификат в Vault:
vault read ingress-tls/site.example.cloud
Cоздание политики на чтение секретов и генерация токена. Сертификат на месте. Теперь создадим политику и сгенерируем на ее основе токен доступа к хранилищу, где лежит сертификат.
cat <<EOF | vault policy write vault-secrets-operator -
path "ingress-tls/site.example.cloud" {
capabilities = ["read"]
}
EOF
vault token create -period=720h -policy=vault-secrets-operator
helm repo add ricoberger https://ricoberger.github.io/helm-charts
helm repo update
Предполагается, что наш токен доступа к Vault в процессе работы будет продлеваться. Создаем kubernetes-секрет для его хранения.
Переводим токен в формат base64 и описываем секрет.
cat <<EOF >> operator-secrets.yaml
apiVersion: v1
kind: Secret
metadata:
name: vault-secrets-operator
namespace: vault-operator
type: Opaque
data:
VAULT_TOKEN: $(echo -n s.W4ndAJbuoDMsoLDZyVBG18F2 | base64)
EOF
Описываем конфигурацию нашего helm-чарта:
cat <<EOF >> values.yaml
environmentVars:
- name: VAULT_TOKEN
valueFrom:
secretKeyRef:
name: vault-secrets-operator # указываем наш секрет
key: VAULT_TOKEN
- name: VAULT_TOKEN_LEASE_DURATION
value: "720"
vault:
address: "https://vault.example.cloud"
authMethod: token
reconciliationTime: 15 #Время в секундах, через которое оператор будет обновлять секрет
EOF
Создаем неймспейс и применяем созданную конфигурацию:
kubectl create ns vault-operator
kubectl create -f operator-secrets.yaml
Устанавливаем helm-chart:
helm install vault-secrets-operator ricoberger/vault-secrets-operator -n vault-operator -f values.yaml
Установка закончена.
Теперь с помощью оператора посмотрим, как будет выглядеть наш секрет.
cat <<EOF | kubectl apply -f -
apiVersion: ricoberger.de/v1alpha1
kind: VaultSecret
metadata:
name: ingress-tls
spec:
path: ingress-tls/site.example.cloud
type: kubernetes.io/tls
EOF
В дальнейшем при работе проверить взаимодействие секрет-оператора с vault-сервером можно в логах пода.
Там мы увидим, как по тайм-ауту синхронизируются наши секреты, а также происходит процесс продления токена (renew token):
{"level":"info","ts":1627985973.7251098,"logger":"vault","msg":"Renew Vault token"}
{"level":"info","ts":1627985978.8396158,"logger":"controllers.VaultSecret","msg":"Use shared client to get secret from Vault","vaultsecret":"default/ingress-tls"}
{"level":"info","ts":1627985978.839656,"logger":"vault","msg":"Read secret ingress-tls/site.example.cloud"}
{"level":"info","ts":1627985978.90391,"logger":"controllers.VaultSecret","msg":"Updating a Secret","vaultsecret":"default/ingress-tls","Secret.Namespace":"default","Secret.Name":"ingress-tls"}
{"level":"info","ts":1627985993.925628,"logger":"controllers.VaultSecret","msg":"Use shared client to get secret from Vault","vaultsecret":"default/ingress-tls"}
{"level":"info","ts":1627985993.9256816,"logger":"vault","msg":"Read secret ingress-tls/site.example.cloud"}
{"level":"info","ts":1627985993.9865305,"logger":"controllers.VaultSecret","msg":"Updating a Secret","vaultsecret":"default/ingress-tls","Secret.Namespace":"default","Secret.Name":"ingress-tls"}
Проверяем kubernetes-секрет в кластере:
kubectl get secrets ingress-tls -o yaml
Секрет на месте. Все готово!
В дальнейшем мы можем применить tls-сертификат, к примеру, на нашем тестовом ингрессе. Не забудьте перед запуском отредактировать под себя.
kubectl create -f https://raw.githubusercontent.com/xor222xor/habr-ingress/main/manifest.yml
Смотрим наш сертификат снаружи:
openssl s_client -showcerts -connect site.example.cloud:443 </dev/null 2>/dev/null | openssl x509 -noout -text | grep Issuer
Конечно, не стоит забывать, что при получении полного доступа к кластеру даже Vault не решит проблем с безопасностью.
habr.com
Но как быть, если необходимо положить секреты из Vault в секреты Kubernetes? Например, мы хотим хранить и обновлять свой tls-сертификат для ингресса из Vault. Или мы решили использовать gitops и хотим, чтобы в репозитории безопасно хранилось все описание инфраструктуры, в том числе и секретов Kubernetes?
Разберем этот сценарий на практике и реализуем его с помощью vault-secrets-operator.
Схема работы vault-secrets-operator
При использовании оператора у нас появляется возможность создать CRD-объект с описанием kubernetes-секрета. Cамо это описание мы можем безопасно хранить в репозитории, а его данные будут находиться в Vault:
Установка и настройка Vault. На эту тему написано уже много мануалов, так что подробно останавливаться не буду. Например, можно положиться на официальную документацию установки через helm-чарт в кластер Kubernetes.
С его помощью несложно сделать HA-установку c базой PostgreSQL и настроенным ингрессом. Главное в этом случае — не забыть создать в базе таблицы для HA-режима. После необходимо проинициализировать под командой vault operator init, если хотите вручную распечатывать Vault при перезапусках подов.
Итак, у нас на руках токен доступа, наш Vault настроен и доступен извне. Ставим себе консольную утилиту Vault на десктоп и создаем переменные окружения (у вас, конечно, будут свои значения).
export VAULT_ADDR=https://vault.example.cloud
VAULT_TOKEN=s.cyVpg9kDV10CQt9fEaIhdo
Проверяем статус нашего vault-сервера.
vault status
Key Value
--- -----
Seal Type shamir
Initialized true
Sealed false
Total Shares 5
Threshold 3
Version 1.7.3
Storage Type postgresql
Cluster Name vault-cluster-d487efe3
Cluster ID 11aa752a-d492-8784-6c26-e9a3e05952f9
HA Enabled true
HA Cluster https://vault-0.vault-internal:8201
HA Mode active
Active Since 2021-07-08T09:30:53.565132822Z
Здесь мы также можем обратить внимание на:
- Sealed — запечатан ли наш Vault;
- HA Enabled — включен ли HA-режим работы;
- Total shares — общее количество ключей;
- Threshold — количество ключей, необходимое для распечатывания.
Генерируем его для домена site.example.cloud:
openssl req -x509 -newkey rsa:4096 -keyout tls.key -out tls.crt -nodes -days 365 -subj '/CN=site.example.cloud'
Создаем key-value хранилище в Vault и закидываем в него сгенерированный сертификат:
vault secrets enable -path=ingress-tls kv
vault write ingress-tls/site.example.cloud tls.crt=@tls.crt tls.key=@tls.key
На всякий случай проверим наш сертификат в Vault:
vault read ingress-tls/site.example.cloud
Cоздание политики на чтение секретов и генерация токена. Сертификат на месте. Теперь создадим политику и сгенерируем на ее основе токен доступа к хранилищу, где лежит сертификат.
cat <<EOF | vault policy write vault-secrets-operator -
path "ingress-tls/site.example.cloud" {
capabilities = ["read"]
}
EOF
vault token create -period=720h -policy=vault-secrets-operator
Настройка vault-secrets-operator
Сначала устанавливаем репозиторий с чартом:helm repo add ricoberger https://ricoberger.github.io/helm-charts
helm repo update
Предполагается, что наш токен доступа к Vault в процессе работы будет продлеваться. Создаем kubernetes-секрет для его хранения.
Переводим токен в формат base64 и описываем секрет.
cat <<EOF >> operator-secrets.yaml
apiVersion: v1
kind: Secret
metadata:
name: vault-secrets-operator
namespace: vault-operator
type: Opaque
data:
VAULT_TOKEN: $(echo -n s.W4ndAJbuoDMsoLDZyVBG18F2 | base64)
EOF
Описываем конфигурацию нашего helm-чарта:
cat <<EOF >> values.yaml
environmentVars:
- name: VAULT_TOKEN
valueFrom:
secretKeyRef:
name: vault-secrets-operator # указываем наш секрет
key: VAULT_TOKEN
- name: VAULT_TOKEN_LEASE_DURATION
value: "720"
vault:
address: "https://vault.example.cloud"
authMethod: token
reconciliationTime: 15 #Время в секундах, через которое оператор будет обновлять секрет
EOF
Создаем неймспейс и применяем созданную конфигурацию:
kubectl create ns vault-operator
kubectl create -f operator-secrets.yaml
Устанавливаем helm-chart:
helm install vault-secrets-operator ricoberger/vault-secrets-operator -n vault-operator -f values.yaml
Установка закончена.
Теперь с помощью оператора посмотрим, как будет выглядеть наш секрет.
cat <<EOF | kubectl apply -f -
apiVersion: ricoberger.de/v1alpha1
kind: VaultSecret
metadata:
name: ingress-tls
spec:
path: ingress-tls/site.example.cloud
type: kubernetes.io/tls
EOF
В дальнейшем при работе проверить взаимодействие секрет-оператора с vault-сервером можно в логах пода.
Там мы увидим, как по тайм-ауту синхронизируются наши секреты, а также происходит процесс продления токена (renew token):
{"level":"info","ts":1627985973.7251098,"logger":"vault","msg":"Renew Vault token"}
{"level":"info","ts":1627985978.8396158,"logger":"controllers.VaultSecret","msg":"Use shared client to get secret from Vault","vaultsecret":"default/ingress-tls"}
{"level":"info","ts":1627985978.839656,"logger":"vault","msg":"Read secret ingress-tls/site.example.cloud"}
{"level":"info","ts":1627985978.90391,"logger":"controllers.VaultSecret","msg":"Updating a Secret","vaultsecret":"default/ingress-tls","Secret.Namespace":"default","Secret.Name":"ingress-tls"}
{"level":"info","ts":1627985993.925628,"logger":"controllers.VaultSecret","msg":"Use shared client to get secret from Vault","vaultsecret":"default/ingress-tls"}
{"level":"info","ts":1627985993.9256816,"logger":"vault","msg":"Read secret ingress-tls/site.example.cloud"}
{"level":"info","ts":1627985993.9865305,"logger":"controllers.VaultSecret","msg":"Updating a Secret","vaultsecret":"default/ingress-tls","Secret.Namespace":"default","Secret.Name":"ingress-tls"}
Проверяем kubernetes-секрет в кластере:
kubectl get secrets ingress-tls -o yaml
Секрет на месте. Все готово!
В дальнейшем мы можем применить tls-сертификат, к примеру, на нашем тестовом ингрессе. Не забудьте перед запуском отредактировать под себя.
kubectl create -f https://raw.githubusercontent.com/xor222xor/habr-ingress/main/manifest.yml
Смотрим наш сертификат снаружи:
openssl s_client -showcerts -connect site.example.cloud:443 </dev/null 2>/dev/null | openssl x509 -noout -text | grep Issuer
Что в результате
Я разобрал простой способ использования HashiCorp Vault для хранения секретов Kubernetes. В дальнейшем манифест c описанием секрета можно безопасно хранить в git-репозитории и использовать в своих интеграциях, а данные централизованно держать в Vault.Конечно, не стоит забывать, что при получении полного доступа к кластеру даже Vault не решит проблем с безопасностью.
HashiСorp Vault & Kubernetes Secret: используем vault-secrets-operator
Vault от HashiСorp — довольно известное open-source-решение для хранения секретов и неплохая альтернатива реализации секретов в Kubernetes. Vault использует свой сайдкар-контейнер на каждом поде,...
habr.com