Vault от HashiСorp — довольно известное open-source-решение для хранения секретов и неплохая альтернатива реализации секретов в Kubernetes. Vault использует свой сайдкар-контейнер на каждом поде, который получает секреты из хранилища и доставляет их в под или же реализует доступ к секретам через csi-драйвер.

Но как быть, если необходимо положить секреты из 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 — количество ключей, необходимое для распечатывания.

Отправка сертификата в Vault. В нашем примере для простоты воспроизведения будем использовать самоподписанный tls-сертификат.

Генерируем его для домена 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 не решит проблем с безопасностью.