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

ПоЗагрузка умолчаниюполитики:

vault чартеpolicy включеныwrite blitz-helm-test-read policy.hcl

Настройка idpAppRole,

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

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"

Получение reg, recovery. Модули panelrole_id и ldapMfasecret_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'

СхемаБлок конфигурации

В чарте используется двухуровневая модель конфигурации:

• статическая конфигурация
• динамическая конфигурация

Статическая конфигурация

Статическая конфигурация рендерится Helm и попадаетVault в Secretvalues.yaml, ConfigMap или, при использовании Vault, в VaultStaticSecret.

ТиповыеМинимальный статические файлы:

• boot.conf
• overlay.conf
• play.conf
• logback.xml
• blitz-keystore.bks
• console.conf

Для модулей Blitz эти файлы по умолчанию монтируются в каталог:пример:

vault:
  enabled: true
  refreshAfter: "60s"
  source:
    mount: "kv"
    path: "blitz/helm/test/env"
  connection:
    create: true
    address: "https:/usr/share/identityblitz/blitz-config/vault.company.loc"
    

Динамическаяfalse конфигурация

Динамическаяcreate: конфигурацияtrue используетсяmount: в"approle" сценариях,appRole: гдеroleId: конфиги"aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa" поставляютсяsecretRef: не только внутри образа, но и из внешнего источника.

По умолчанию она размещается по пути:

/usr/share/identityblitz/idp-config"vault-approle-secretid"

Если выбраниспользуется режимVault Enterprise, можно дополнительно задать namespace Vault в config.readOnly=false, чарт использует общий PersistentVolumeClaimvault.source.vaultNamespace и публикует туда конфигурацию через специальный Jobvault.auth.vaultNamespace.

ДваСценарий режимабез поставки конфигурацииVault

Режим

Blitz image-only

Режим config.readOnly=true подходит для случаев, когда конфигурация встроена в Docker-образразвернуть и еёбез не нужно инициализировать из Git или локального каталога.Vault:

vault:
  enabled: false

ОсобенностиВ режима:этом случае нужно:

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

Режим

Ограничения Git/Localтакого -> PVC

Режим config.readOnly=false нужен, когда конфигурацию требуется публиковать в общий каталог во время установки.

Особенности режима:подхода:

• используетсявыше общийриск PersistentVolumeClaimутечки секретов через файлы конфигурации
• источниксложнее динамическойуправлять конфигурации задаётся через config.source.typeротацией
• создаётсябольше init-confручной Job
работы
• рабочиепри поды могут ожидают готовности конфигурации через initContainerсопровождении

Kubernetes-ресурсыLDAP MFA

Ingress

Ingress публикует HTTP-эндпоинты Blitz наружу. Чарт поддерживает настройку класса ingress-контроллера, аннотаций и TLS-секрета.

PersistentVolumeClaim

PersistentVolumeClaim нужен только в сценарии с динамической конфигурацией. Он хранит конфигурацию и вспомогательные ресурсы, доступные модулям Blitz IDP.

Vault и VSO

Если используется Blitz LDAP MFA с vault.enabled=trueconfirmationFactor.type=radius, чартнужен может забирать секреты из HashiCorp Vault через Vault Secrets Operator. В этом случае вместо прямого создания некоторых Secret в кластере используются ресурсы:секрет:

• VaultConnection
• VaultAuth
• VaultStaticSecretBLITZ_LDAP_MFA_CONFIRMATION_SHARED_KEY

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

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

• не передавайте секреты через PodDisruptionBudgethelm

  PodDisruptionBudget--set защищаетв модулиproduction-среде

от
• храните добровольныхисходные прерываний,значения напримерв при kubectl drainVault или плановомкорпоративном обслуживаниихранилище узлов.
  секретов

фиксируйте, кто отвечает за ротацию NetworkPolicymaster key

NetworkPolicy ограничивает сетевой доступ к подам Blitz. В чарте есть как более мягкий режим, так и строгийпаролей режимБД с

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