Перейти к основному контенту

Подготовка секретов и Vault

Blitz использует набор секретов для доступа к БД, шифрования, работы административной консоли, keystore и дополнительных модулей. Этот раздел описывает, как подготовить такие секреты и как подключить HashiCorp Vault.

Какие секреты нужны Blitz

Типовой набор включает:

  • BLITZ_BOOT_MASTERKEY
  • BLITZ_INTERNALSTORE_JDBC_SECRET
  • BLITZ_CREDENTIALS_ADMIN_PASSWORD
  • BLITZ_KEYSTORE_PASSWORD
  • BLITZ_LICENSE
  • BLITZ_CONSOLE_FP_CLIENT_SECRET
  • BLITZ_CONSOLE_UTILSCS_ENCODING_KEY
  • BLITZ_CONSOLE_UTILSCS_HMAC_KEY
  • BLITZ_PANEL_CLIENT_SECRET
  • BLITZ_PANEL_ENCODING_KEY
  • BLITZ_PANEL_HMAC_KEY
  • BLITZ_PANEL_JDBC_PASSWORD
  • BLITZ_LDAP_MFA_MASTER_KEY
  • BLITZ_LDAP_MFA_CONFIRMATION_SHARED_KEY
  • BLITZ_LDAP_MFA_KEYSTORE_PASSWORD

Если вы хотите хранить keystore в Vault, также используются:

  • BLITZ_KEYSTORE_BKS_B64
  • BLITZ_LDAP_MFA_KEYSTORE_JKS_B64

Генерация секретов

В архиве Helm чарта поставляется утилита для быстрой генерации необходимых секретов:

tools/secrets/blitz-secrets.sh

Основной функционал:

  • генерация секретов
  • генерация Keystore для Blitz IDP
  • генерация Keystore для Blitz LDAP MFA
  • вывод секретов в формате KEY=VALUE
  • вывод секретов в формате JSON для загрузки в Vault

Вместе с утилитой поставляется README, в нем вы можете найти более подробную информацию по использованию.

Пример генерации секретов в JSON формате для Vault

tools/secrets/blitz-secrets.sh \
  --db-pass "S3cureDBPass" \
  --admin-pass "S3cureAdminPass" \
  --license "AAAABBBBCCCCDDDD" \
  --master-key "0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef" \
  --ldap-mfa-confirmation-shared-key "radius-shared-key" \
  --format json > secrets.json

Пример генерации секретов в stdout

tools/secrets/blitz-secrets.sh \
  --db-pass "S3cureDBPass" \
  --admin-pass "S3cureAdminPass" \
  --license "AAAA-BBBB-CCCC-DDDD" \
  --format stdout

Когда использовать Vault

Для production-среды рекомендуется включать Vault:

vault:
  enabled: true

Это даёт несколько преимуществ:

  • секреты не хранятся в открытом виде в values.yaml
  • можно централизованно управлять ротацией
  • чарт использует VSO для доставки секретов в Kubernetes

Загрузка секретов в Vault

Пример записи данных в KV:

vault kv put kv/blitz/helm/test/env \
  BLITZ_BOOT_MASTERKEY="0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef" \
  BLITZ_CONSOLE_FP_CLIENT_SECRET="console-fp-secret" \
  BLITZ_CONSOLE_UTILSCS_ENCODING_KEY="console-encoding-key" \
  BLITZ_CONSOLE_UTILSCS_HMAC_KEY="console-hmac-key" \
  BLITZ_CREDENTIALS_ADMIN_PASSWORD="AdminPassword123" \
  BLITZ_INTERNALSTORE_JDBC_SECRET="db-password" \
  BLITZ_KEYSTORE_PASSWORD="keystore-password" \
  BLITZ_KEYSTORE_BKS_B64="<base64>" \
  BLITZ_LICENSE="AAAA-BBBB-CCCC-DDDD" \
  BLITZ_PANEL_CLIENT_SECRET="panel-client-secret" \
  BLITZ_PANEL_ENCODING_KEY="panel-encoding-key" \
  BLITZ_PANEL_HMAC_KEY="panel-hmac-key" \
  BLITZ_PANEL_JDBC_PASSWORD="panel-db-password" \
  BLITZ_LDAP_MFA_MASTER_KEY="0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef" \
  BLITZ_LDAP_MFA_CONFIRMATION_SHARED_KEY="radius-shared-key" \
  BLITZ_LDAP_MFA_KEYSTORE_PASSWORD="ldap-mfa-keystore-password" \
  BLITZ_LDAP_MFA_KEYSTORE_JKS_B64="<base64>"

Чарт ожидает полный путь до секрета в параметре vault.source.path.

Политика доступа в Vault

Минимальная политика может выглядеть так:

path "kv/data/blitz/helm/test/env" {
  capabilities = ["read"]
}

path "kv/metadata/blitz/helm/test/*" {
  capabilities = ["list"]
}

Загрузка политики:

vault policy write blitz-helm-test-read policy.hcl

Настройка AppRole

Пример создания AppRole:

vault write auth/approle/role/blitz-vso-helm-test \
  token_policies="blitz-helm-test-read" \
  token_ttl="1h" \
  token_max_ttl="4h" \
  secret_id_ttl="24h"

Получение role_id и secret_id:

vault read -field=role_id auth/approle/role/blitz-vso-helm-test/role-id
vault write -field=secret_id -f auth/approle/role/blitz-vso-helm-test/secret-id

secret_id нужно сохранить в Kubernetes:

kubectl -n blitz create secret generic vault-approle-secretid \
  --from-literal=id='generated-secret-id'

Блок Vault в values.yaml

Минимальный пример:

vault:
  enabled: true
  refreshAfter: "60s"
  source:
    mount: "kv"
    path: "blitz/helm/test/env"
  connection:
    create: true
    address: "https://vault.company.loc"
    skipTLSVerify: false
  auth:
    create: true
    mount: "approle"
    appRole:
      roleId: "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
      secretRef: "vault-approle-secretid"

Если используется Vault Enterprise, можно дополнительно задать namespace Vault в vault.source.vaultNamespace и vault.auth.vaultNamespace.

Сценарий без Vault

Blitz можно развернуть и без Vault:

vault:
  enabled: false

В этом случае нужно:

  • передать нужные значения через values.yaml
  • использовать Secret Kubernetes там, где это требуется режимом поставки конфигурации
  • аккуратно организовать хранение и доставку секретов вне Helm-чарта

Ограничения такого подхода:

  • выше риск утечки секретов через файлы конфигурации
  • сложнее управлять ротацией
  • больше ручной работы при сопровождении

LDAP MFA

Если используется Blitz LDAP MFA с confirmationFactor.type=radius, нужен секрет:

  • BLITZ_LDAP_MFA_CONFIRMATION_SHARED_KEY

При включённом Vault его можно не дублировать в конфигурации.

Практические рекомендации

  • не передавайте секреты через helm --set в production-среде
  • храните исходные значения в Vault или корпоративном хранилище секретов
  • фиксируйте, кто отвечает за ротацию master key и паролей БД
  • используйте один согласованный процесс для всех окружений
Наверх