Menu AuthGuardCentro de ajuda
Englishauthguard.pt

Distribuidores e parceiros · Plataforma

Instalar o AuthGuard no cluster Kubernetes de um cliente (Helm)

  • 2 min de leitura
  • Instalação própria

Além do serviço partilhado na União Europeia, o AuthGuard pode correr na infraestrutura do próprio cliente. O chart deploy/helm/authguard usa a mesma imagem, as mesmas definições e a mesma porta do serviço na nuvem; o procedimento completo é o runbook docs/runbooks/helm-install-upgrade-rollback.md do repositório AuthGuard. Este artigo dá ao distribuidor o quadro geral antes de apresentar uma proposta.

De que precisa o cliente?

NecessidadeDetalhe
Kubernetes1.27 ou mais recente; os pods cumprem o Pod Security Standard restrito
PostgreSQL 18Externo, com TLS, com duas bases de dados (authguard e authguard_coordination); o chart não inclui base de dados
Chaves de assinaturaChaves AWS KMS para o perfil de assinaturas pós-quânticas, e uma identidade que os pods possam usar
TLSUm certificado de servidor para o anfitrião do serviço; os próprios pods terminam o TLS 1.3, por isso publique-os com um balanceador de carga L4 ou com TLS em passagem, nunca com um ingress que termine o TLS
ImagemA imagem da versão, verificada e copiada para um registo a que o cluster chegue

As instalações Sovereign precisam também do transporte pós-quântico do PostgreSQL e de uma cadeia de certificados ML-DSA-65.

Como decorre uma instalação?

  1. Crie os Secrets do Kubernetes (identidades da base de dados, TLS, chaves da aplicação) a partir de ficheiros: o chart nunca guarda o valor de um segredo.
  2. Copie values-standard.yaml ou values-sovereign.yaml para um ficheiro do local e preencha todos os valores de exemplo.
  3. Execute helm upgrade --install. O Helm corre primeiro as tarefas de migração e só depois arranca o serviço.
  4. Crie a primeira organização com o token de instalação e depois retire-o. Ver Instalação própria.
  5. Corra a verificação depois de cada instalação, atualização e reversão.

O que deve o cliente saber sobre as atualizações?

  • As migrações só avançam. Faça uma cópia de segurança da base de dados antes de cada atualização.
  • Não use --atomic: depois de uma migração bem-sucedida, os pods antigos não conseguem servir o novo esquema.
  • Uma versão com migrações tem uma pequena interrupção, de cerca de um arranque de pod; uma versão sem migrações atualiza sem interrupção.
  • Reverter para trás de uma migração obriga a restaurar a cópia de segurança feita antes da atualização.

O que não está no chart?

Os trabalhadores de auditoria correm em servidores reforçados, com as suas unidades systemd, porque os volumes do Kubernetes não cumprem as verificações de propriedade dos ficheiros sob a política restrita. Os trabalhadores de sincronização do Entra e do Active Directory correm como CronJobs, a partir das suas próprias imagens. As appliances Edge instalam-se à parte. Ver Instalar a appliance Edge.

Estado de validação

O chart passa as verificações de lint, de template e de contrato estático para os dois perfis, mas ainda não foi instalado num cluster real com um PostgreSQL 18 e um KMS reais. Planeie a primeira instalação num ambiente de testes e guarde os resultados da verificação antes de passar a produção.

Referência do artigods-self-hosted-helmindique-a ao suporte para identificar este artigo. Verificado contra o produto no commit 78c33b39.