Distribuidores e parceiros · Plataforma
Instalar o AuthGuard no cluster Kubernetes de um cliente (Helm)
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?
| Necessidade | Detalhe |
|---|---|
| Kubernetes | 1.27 ou mais recente; os pods cumprem o Pod Security Standard restrito |
| PostgreSQL 18 | Externo, com TLS, com duas bases de dados (authguard e authguard_coordination); o chart não inclui base de dados |
| Chaves de assinatura | Chaves AWS KMS para o perfil de assinaturas pós-quânticas, e uma identidade que os pods possam usar |
| TLS | Um 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 |
| Imagem | A 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?
- 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.
- Copie
values-standard.yamlouvalues-sovereign.yamlpara um ficheiro do local e preencha todos os valores de exemplo. - Execute
helm upgrade --install. O Helm corre primeiro as tarefas de migração e só depois arranca o serviço. - Crie a primeira organização com o token de instalação e depois retire-o. Ver Instalação própria.
- 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.
Esta página ajudou?
Obrigado. A resposta fica guardada apenas neste browser; não enviamos nada.
Lamentamos. Experimente:
- pesquisar com o texto exato da mensagem ou o código de erro
- consultar o índice de códigos de erro
- falar com o administrador da sua organização