Для улучшения работы сайта мы используем файлы cookies. Оставаясь на сайте, вы соглашаетесь с политикой обработки персональных данных.

Установка с помощью HELM

StarVault работает с Kubernetes в следующих режимах: dev, standalone, ha и external.

1. Helm-чарт

Для установки и настройки StarVault в Kubernetes рекомендуется использовать Helm-чарт для StarVault.

Хотя Helm-чарт автоматически настраивает сложные ресурсы и подгоняет конфигурацию под требования, он не поддерживает работу StarVault автоматически. Полезно иметь навыки вести мониторинг, делать резервные копии, устанавливать обновления и тому подобное в кластере StarVault, чтобы поддерживать ту часть работы StarVault, которую не можете автоматизировать.

По умолчанию чарт работает в автономном режиме, в котором используется один сервер StarVault с бэкендом файлового хранилища. Эта конфигурация не так надежна и безопасна, а потому НЕ подходит для боевой среды. Настоятельно рекомендуется использовать должным образом защищенный кластер Kubernetes.

2. Установка StarVault

Helm должен быть установлен и настроен.

Для использования Helm-чарта введите логин и пароль для входа в репозиторий и убедитесь, что есть доступ к чарту:

helm registry login -u USER -p PASSWORD https://hub.orionsoft.ru/public
helm show chart oci://hub.orionsoft.ru/public/starvault

  • USER — логин от учетной записи в репозитории.

  • PASSWORD — пароль от учетной записи в репозитории.

Helm-чарт – это новое решение, которое находится в стадии интенсивной разработки. Поэтому перед установкой или обновлением всегда запускайте Helm командой --dry-run, чтобы проверить наличие изменений.

С помощью команды helm install установите последний релиз Helm-чарта для StarVault.

helm install starvault oci://hub.orionsoft.ru/public/starvault --namespace starvault --create-namespace

Команда helm install принимает параметры для переопределения значений конфигурации по умолчанию – как встроенных, так и определенных в файле.

Переопределите значение конфигурации server.dev.enabled:

helm install starvault oci://hub.orionsoft.ru/public/starvault --namespace starvault --create-namespace --set "server.dev.enabled=true"

Переопределите все значения конфигурации, которые есть в файле:

cat override-values.yml
server:
  ha:
    enabled: true
    replicas: 5
##

helm install starvault oci://hub.orionsoft.ru/public/starvault --namespace starvault --create-namespace --values override-values.yml

Скачать файл с переменными:

helm show values oci://hub.orionsoft.ru/public/starvault > override-values.yaml

2.1. Режим разработки (dev-режим)

Helm-чарт может запустить сервер StarVault в режиме разработки (режим dev). При этом устанавливается одиночный сервер StarVault с бэкендом хранения в оперативной памяти.

Режим разработки подходит для учебных и демонстрационных сред, но НЕ рекомендуется для боевой среды.

Установите последнюю версию Helm-чарта для StarVault в режиме разработки.

helm install starvault oci://hub.orionsoft.ru/public/starvault --namespace starvault --create-namespace --set "server.dev.enabled=true"

2.2. Автономный режим (standalone)

По умолчанию Helm-чарт запускается в режиме standalone. В этом режиме устанавливается одиночный сервер StarVault с бэкендом файлового хранилища.

Установите последнюю версию Helm-чарта для StarVault в автономном режиме.

helm install starvault oci://hub.orionsoft.ru/public/starvault --namespace starvault --create-namespace

2.3. Режим высокой доступности (HA)

Helm-чарт можно запустить в режиме высокой доступности (HA). При этом устанавливаются три сервера StarVault с бэкендом хранения Integrated Storage (Raft).

Установите последнюю версию Helm-чарта для StarVault в режиме высокой доступности.

helm install starvault oci://hub.orionsoft.ru/public/starvault --namespace starvault --create-namespace --set "server.ha.enabled=true"

3. Пользовательский интерфейс StarVault

В целях безопасности пользовательский интерфейс StarVault включен, но НЕ доступен как сервис. Доступ к пользовательскому интерфейсу StarVault можно открыть через переадресацию портов или через значение конфигурации UI.

Откройте доступ к пользовательскому интерфейсу StarVault через переадресацию портов:

$ kubectl port-forward starvault-0 8200:8200 -n starvault
Forwarding from 127.0.0.1:8200 -> 8200
Forwarding from [::1]:8200 -> 8200
##...

4. Инициализация и распечатывание StarVault

После установки Helm-чарта для StarVault в режиме standalone или ha необходимо инициализировать один из серверов StarVault. При инициализации генерируются учетные данные, необходимые для распечатывания всех серверов StarVault.

4.1. Инициализация и распечатывание с помощью интерфейса командной строки

Просмотрите все поды StarVault в текущем пространстве имен:

$ kubectl get pods -l app.kubernetes.io/name=starvault -n starvault

NAME                                    READY   STATUS    RESTARTS   AGE
starvault-0                           0/1     Running   0          1m49s
starvault-1                           0/1     Running   0          1m49s
starvault-2                           0/1     Running   0          1m49s

Инициализируйте один сервер StarVault с заданным по умолчанию количеством частей ключа и заданным по умолчанию пороговым количеством частей ключа:

$ kubectl -n starvault exec -it starvault-0 -- starvault operator init

Unseal Key 1: MBFSDepD9E6whREc6Dj+k3pMaKJ6cCnCUWcySJQymObb
Unseal Key 2: zQj4v22k9ixegS+94HJwmIaWLBL3nZHe1i+b/wHz25fr
Unseal Key 3: 7dbPPeeGGW3SmeBFFo04peCKkXFuuyKc8b2DuntA4VU5
Unseal Key 4: tLt+ME7Z7hYUATfWnuQdfCEgnKA2L173dptAwfmenCdf
Unseal Key 5: vYt9bxLr0+OzJ8m7c7cNMFj7nvdLljj0xWRbpLezFAI9

Initial Root Token: s.zJNwZlRrqISjyBHFMiEca6GF
##...

В выводе отображаются сгенерированные части ключа распечатвания и изначальный корневой ключ.

Распечатывайте сервер StarVault, добавляя части ключа, пока не будет достигнуто пороговое количество частей ключа:

kubectl -n starvault exec -it starvault-0 -- starvault operator unseal #Unseal Key 1
kubectl -n starvault exec -it starvault-0 -- starvault operator unseal #Unseal Key 2
kubectl -n starvault exec -it starvault-0 -- starvault operator unseal #Unseal Key 3

Повторите процесс распечатывания для всех подов сервера StarVault. Когда все поды сервера StarVault будут распечатаны, они сообщат о готовности: READY 1/1.

+

$ kubectl get pods -l app.kubernetes.io/name=starvault

NAME                                    READY   STATUS    RESTARTS   AGE
starvault-0                                 1/1     Running   0          1m49s
starvault-1                                 1/1     Running   0          1m49s
starvault-2                                 1/1     Running   0          1m49scode

5. Пробы

Пробы нужны для обнаружения сбоев, перепланировки и использования подов в Kubernetes. Helm-чарт предлагает настраиваемые пробы готовности и работоспособности, которые можно доработать под разнообразные сценарии использования.

Конечную точку /sys/health в StarVault можно доработать так, чтобы модифицировать процесс проверки работоспособности. Например, можно изменить пробу готовности StarVault, чтобы показывать готовые поды StarVault, даже если они еще не инициализированы и запечатаны, с помощью следующей пробы:

server:
  readinessProbe:
    enabled: true
    path: '/v1/sys/health?standbyok=true&sealedcode=204&uninitcode=204'

С помощью этой доработанной пробы скрипт postStart может запускаться автоматически, как только под будет готов к дополнительной настройке.

6. Обновление StarVault в Kubernetes

Для обновления StarVault в Kubernetes используется обычная процедура обновления StarVault, за исключением того, что можно использовать Helm-чарт для обновления параметра Statef`ulSet сервера StarVault. Прежде чем читать дальше, важно понять, что имеется в виду под обычной процедурой обновления StarVault. Параметр StatefulSet в StarVault использует стратегию обновления OnDelete. Крайне важно использовать OnDelete вместо RollingUpdate, потому что резервные узлы должны быть обновлены раньше основного активного узла. Всегда избегайте отката к более старой версии StarVault в случае отказа.

Всегда перед обновлением делайте резервную копию ваших данных! StarVault не дает гарантий обратной совместимости для своего хранилища данных. Просто заменив недавно установленный двоичный файл StarVault на предыдущую версию, вы вряд ли сможете полноценно откатиться на старую версию StarVault, поскольку обновления могут вносить изменения в базовую структуру данных, делая их несовместимыми со старой версией. Если нужно откатиться до предыдущей версии StarVault, следует также откатить и ваше хранилище данных.

6.1. Обновление серверов StarVault

По умолчанию Helm установит самую последнюю версию чарта, которую найдет в репозитории. Рекомендуется перед обновлением указать версию чарта.
Пример:
helm install starvault oci://hub.orionsoft.ru/public/starvault --version 1.4.0 --namespace starvault --create-namespace

Чтобы инициировать обновление, задайте для параметра server.image значения, соответствующие желаемой версии StarVault; это могут быть значения в YAML-файле или в командной строке.
В целях демонстрации в примере ниже используется hub.orionsoft.ru/public/starvault:1.4.0.

server:
  image:
    repository: 'hub.orionsoft.ru/public/starvault'
    tag: '1.4.0'

Затем выберите нужную версию Helm для установки.

Далее протестируйте обновление с помощью --dry-run, чтобы проверить изменения, отправленные в кластер Kubernetes.

$ helm upgrade starvault oci://hub.orionsoft.ru/public/starvault --version1.4.0 --namespace starvault \
    --set='server.image.repository=hub.orionsoft.ru/public/starvault' \
    --set='server.image.tag=1.4.0' \
    --dry-run

Это не должно привести к каким-либо изменениям (хотя ресурсы обновлены). Если все стабильно, можно запустить helm upgrade. Команда helm upgrade должна обновить шаблон StatefulSet для серверов StarVault, однако ни один под удален не был. Для обновления поды следует удалять вручную. Удаление подов не приводит к удалению постоянно хранящихся данных.

Если StarVault не развернут в режиме ha, одиночный сервер StarVault можно удалить, запустив следующую команду:

$ kubectl delete pod <имя пода StarVault> -n starvault

Если StarVault развернут в режиме ha, то сначала следует обновить резервные поды. Благодаря встроенной функции обнаружения сервисов K8s (когда она включена в конфигурации сервера) StarVault будет автоматически менять метки пода, учитывая статус ведущего. По этим меткам можно фильтровать поды.

Например, можно выбрать все резервные поды StarVault:

kubectl get pods -l vault-active=false -n starvault

Выберите активный под StarVault:

kubectl get pods -l vault-active=true -n starvault

Затем последовательно можно удалить каждый под, который не является активным, и при этом все время сохранять кворум:

kubectl delete pod <имя пода StarVault> -n starvault

Если автоматическое распечатывание не используется, вновь запланированные резервные поды StarVault нужно распечатать:

kubectl exec -ti <имя пода> -n starvault -- vault operator unseal

Наконец, как только резервные узлы обновлены и распечатаны, можно удалить активный основной узел:

kubectl delete pod <имя основного узла StarVault> -n starvault

Как и в случае с резервными узлами, бывший основной тоже нужно распечатать:

kubectl exec -ti <имя пода> -n starvault -- vault operator unseal

Затем через пару секунд кластер StarVault должен выбрать новый активный основной узел. Кластер StarVault обновлен.

7. Защита конфиденциальных конфигураций StarVault

Helm для StarVault во время установки формирует файл конфигурации StarVault и хранит его в карте конфигурации Kubernetes. Некоторые конфигурации требуют включения конфиденциальных данных в файл конфигурации и после создания в Kubernetes будут храниться в незашифрованном виде.

В следующем примере показано, как добавить дополнительные файлы конфигурации в Helm для StarVault, чтобы зашифровать хранящиеся конфиденциальные конфигурации с помощью секретов Kubernetes.

Сначала создайте частичную конфигурацию StarVault с конфиденциальными настройками, которые StarVault загружает во время запуска:

$ cat <<EOF >>config.hcl
storage "mysql" {
username = "user1234"
password = "secret123!"
database = "vault"
}
EOF

Затем создайте секрет Kubernetes, содержащий эту частичную конфигурацию:

$ kubectl create secret generic vault-storage-config \
    --from-file=config.hcl

Создайте файл values.yaml и добавьте следующий блок в него:

server:
  volumes:
    - name: userconfig-vault-storage-config
      secret:
        defaultMode: 420
        secretName: "vault-storage-config"
  volumeMounts:
    - name: "userconfig-vault-storage-config"
      mountPath: "/starvault/userconfig/vault-storage-config"
      readOnly: true
  extraArgs: "-config=/starvault/userconfig/vault-storage-config/config.hcl"

Наконец, смонтируйте этот секрет как дополнительный том.

Команда запуска StarVault:

$ helm install starvault oci://hub.orionsoft.ru/public/starvault --namespace starvault --create-namespace --values values.yaml

8. Архитектура

Рекомендуем запускать StarVault в Kubernetes с той же обычной архитектурой, что используется при запуске в любой другой среде. У Kubernetes есть ряд преимуществ, которые могут упростить эксплуатацию кластера StarVault и будут приведены ниже. Однако стандартное руководство по развертыванию в боевой среде все равно стоит прочитать, даже если StarVault запускается в Kubernetes.

8.1. Чеклист по развертыванию в боевой среде

Сквозное шифрование по протоколу TLS. StarVault в боевой среде всегда следует использовать с шифрованием по протоколу TLS.
Промежуточные балансировщики нагрузки, обратные прокси-серверы должны шифровать проходящий через них трафик по протоколу TLS.
Таким образом, идущий в StarVault трафик всегда шифруется, что минимизирует риски, создаваемые промежуточными участниками процесса передачи.

Один процесс. StarVault должен быть единственным основным процессом, запущенным на машине. Это снижает риск того, что другой процесс, запущенный на той же машине, будет скомпрометирован и сможет взаимодействовать с StarVault. Сделать это можно с помощью настраиваемого поля affinity, которое есть в Helm для StarVault. Пример настройки Helm для StarVault на использование правил совместного существования (affinity) см. в официальной документации.

Функция аудита. Включенная функция аудита StarVault поддерживает несколько бэкендов аудита. Если включить функцию аудита, то сохранится история всех операций, выполненных StarVault, и можно будет получить доказательства в случае расследования злоупотреблений или компрометации. Журналы аудита надежно хэшируют любые конфиденциальные данные, но доступ все равно должен быть ограничен, чтобы предотвратить непреднамеренное раскрытие. Helm для StarVault включает в себя настраиваемую опцию auditStorage, которая предоставляет постоянный том для хранения журналов аудита. Пример настройки Helm для StarVault на использование аудита см. в официальной документации.

Обновление до новых версий без внесения изменений в уже работающие сервера. Для сохранения стабильности работы StarVault использует внешний бэкенд хранения, что позволяет не вносить изменения в сервера, на которых StarVault уже запущен. При обновлении до новых версий запускаются новые сервера с обновленной версией StarVault. Они подключаются к тому же общему бэкенду хранения и распечатываются. Затем старые сервера уничтожаются. В результате снижается необходимость в удаленном доступе и оркестрации процесса обновления, из-за которых могут возникнуть пробелы в безопасности.

Ограничение доступа к хранилищу. StarVault шифрует все хранящиеся данные, независимо от используемого бэкенда хранения. Хотя данные зашифрованы, злоумышленник с административными правами может изменить или удалить ключи, что приведет к повреждению или потере данных. Доступ к бэкенду хранения должен быть только у StarVault, чтобы избежать несанкционированного доступа или использования.