O blog da CNCF apresenta uma receita operacional para criar uma pilha de código aberto de gerenciamento de segredos no Kubernetes, combinando o OpenBao e o CloudNativePG. O OpenBao é o fork de código aberto do HashiCorp Vault sob a Linux Foundation, enquanto o CloudNativePG transforma um cluster PostgreSQL em um serviço autorrecuperável, com replicação síncrona e autenticação baseada em certificados. A receita aproveita o Kubernetes, um projeto graduado da CNCF, e o CloudNativePG, um projeto Sandbox que está sendo avaliado pelo Comitê Técnico de Supervisão da CNCF para passar ao estágio de Incubação.
A ideia central não é simplesmente usar o PostgreSQL como um armazenamento comum, mas fazer com que o OpenBao dependa de um backend PostgreSQL altamente disponível, sem depender de um banco de dados em nuvem proprietário de um provedor específico. A receita usa três instâncias do CloudNativePG, com replicação síncrona baseada em quórum, de modo que a disponibilidade de uma única réplica síncrona seja suficiente para garantir a durabilidade dos dados. Por outro lado, as operações de gravação podem ser interrompidas se não houver uma réplica de backup que atenda à condição de durabilidade exigida.
O que muda no projeto?
O OpenBao usa o armazenamento nativo de PostgreSQL com a tabela de bloqueio de alta disponibilidade ativada por meio da opção ha_enabled = true. A configuração cria duas tabelas: openbao_kv_store, para armazenar os dados, e openbao_ha_locks, para manter os registros dos bloqueios de alta disponibilidade. A receita desativa o armazenamento local padrão no chart do OpenBao, pois presume que todo o estado permanecerá no CloudNativePG.
O CloudNativePG executa um cluster PostgreSQL de três instâncias, direcionando-as para nós dedicados e garantindo a distribuição entre domínios de falha separados por meio de seletores de nós, tolerâncias e restrições de afinidade de pods. A receita usa um catálogo de imagens que especifica a versão compacta do PostgreSQL 18, em vez de escrever manualmente uma tag de imagem fixa, e também apresenta um teste que usou uma imagem protegida por um digest SHA.
Autenticação sem senhas
Um dos aspectos mais importantes da receita é remover as senhas da conexão do OpenBao com o banco de dados. O CloudNativePG cria objetos DatabaseRole para uma função proprietária do schema e uma função operacional restrita chamada openbao-rw, e ambas recebem um certificado de cliente TLS. As regras pg_hba exigem uma conexão TLS e um certificado de cliente para essas funções, enquanto rejeitam conexões não criptografadas.
Esse detalhe é importante porque a criação do certificado, por si só, não impõe automaticamente seu uso; são as regras do PostgreSQL que determinam, para cada conexão, se a autenticação será feita por certificado, por senha ou será rejeitada. A receita também define as permissões dos arquivos de segredos montados nos contêineres como 0640, porque a biblioteca libpq rejeita chaves privadas que possam ser lidas pelo grupo ou por todos os usuários quando montadas com o valor padrão 0644.
Como o DatabaseRole atualmente não gerencia a concessão de permissões em nível de tabela, conforme o artigo, uma tarefa Job executada uma única vez cria as tabelas e concede as permissões SELECT, INSERT, UPDATE e DELETE à função restrita. A tarefa também revoga de PUBLIC a permissão CONNECT, revoga de PUBLIC o uso do schema público e, em seguida, concede novamente o mínimo necessário a openbao-rw. A opção skip_create_table é ativada na configuração do OpenBao para que a função operacional restrita não tente criar as tabelas por conta própria.
O que isso significa na prática para operadores de Kubernetes?
A receita oferece um caminho de teste local usando o repositório cnpg-playground, que cria um cluster Kind de seis nós e inclui configurações prévias do CloudNativePG. O experimento exige Docker, Kind, Helm e kubectl. No entanto, a distribuição dos nós no ambiente de teste impõe uma restrição importante: há nós PostgreSQL dedicados e rotulados, e restam apenas dois nós gerais para distribuir três réplicas do OpenBao com afinidade obrigatória. Por isso, a receita permite temporariamente que o OpenBao use um nó do plano de controle no ambiente Kind, com um alerta explícito contra levar essa tolerância para produção. Em um cluster de produção com três nós de trabalho não rotulados, esse tratamento não é necessário.
Depois de instalar o chart do OpenBao, é necessário inicializar o cluster e remover o selo de cada instância individualmente usando três das cinco chaves Shamir necessárias. Remover o selo da primeira instância não remove o selo das outras duas, e a política padrão OrderedReady do StatefulSet atrasa a criação da instância seguinte até que a anterior esteja pronta. Portanto, as chaves para remover o selo e o token raiz devem ser armazenados com segurança, e as chaves devem ser inseridas em cada instância na ordem.
Após a inicialização, o OpenBao armazena o estado de inicialização e suas chaves na tabela openbao_kv_store, e o valor do segredo de teste é armazenado como dados criptografados do tipo BYTEA, não como texto claro, mesmo quando a tabela do PostgreSQL é acessada diretamente. O artigo confirma o sucesso de um teste de gravação e leitura de um segredo usando KV v2 e a função restrita do PostgreSQL.
Limitações operacionais e o que a receita não cobre
A renovação dos certificados é automatizada pelo CloudNativePG: o certificado de cliente CNPG tem duração de 90 dias e normalmente é renovado cerca de uma semana antes de expirar. No entanto, o OpenBao não relê automaticamente os arquivos de certificados; a interface de armazenamento PostgreSQL abre o pool de conexões quando o processo é iniciado. Portanto, é necessário planejar uma reinicialização gradual das instâncias do OpenBao após a renovação, preferencialmente dentro da janela de renovação de 83 dias antes da expiração do certificado antigo.
Além disso, a alta disponibilidade dentro de um cluster Kubernetes não equivale a um plano completo de recuperação de desastres. A receita não cria automaticamente backups nem recuperação após a perda de todo o cluster. Para uso em produção, o artigo recomenda adicionar o Barman Cloud Plugin com um armazenamento de objetos, como Amazon S3, Google Cloud Storage ou Azure Blob Storage, e usar os recursos Backup e ScheduledBackup para arquivar WALs e backups básicos, habilitando a recuperação para um ponto no tempo. Já os objetivos de RTO e RPO que exigem sobrevivência à perda de um cluster inteiro precisam de um cluster PostgreSQL assíncrono em um segundo cluster ou região.