Encerre o Acesso ao Banco de Dados Quando o Relatório Terminar

Introdução

Um relatório de liquidação precisa de acesso ao banco de dados enquanto é executado. Quando a tarefa termina, sua credencial salva deve deixar de abrir novas conexões. Uma mensagem de aceitação de um serviço de segredos não é evidência suficiente desse resultado.

Este ambiente independente da MarketLedger começa com as permissões corretas de view. Você executará o relatório, revogará sua concessão exata do OpenBao, observará uma concessão separada expirar naturalmente e recuperará o acesso obtendo um novo login. A loja e seu relatório de inventário independente devem continuar utilizáveis. O laboratório guiado anterior ensinou os campos de credenciais e a política limitada de relatório; nenhum arquivo ou estado de sessão é transferido.

Comece pela Loja em Funcionamento e pela Política Correta de Relatório

Nesta etapa, você identificará o negócio normal e os dois papéis de relatório antes de iniciar o relógio de qualquer concessão. Use Terminal durante todo o processo. Entre na área de trabalho independente:

cd /home/labex/project/market-report

cat exibe o exemplo funcional preparado:

cat demo.tsv

A liquidação cobre 2026-10-28: Birch tem dois pedidos pagos totalizando 4700 centavos, Elm tem um totalizando 2000 e Maple tem um totalizando 2700. O pedido cancelado é excluído. O relatório usa reporting.daily_settlement; e-mails privados de clientes e referências bancárias estão fora de seu escopo.

O cliente preparado da loja se comunica com o serviço real da loja. Seus argumentos identificam um novo pedido, vendedor e valor em centavos. Faça um pedido normal para a próxima data comercial sintética, 2026-10-29:

python3 shop.py place --order O201 --vendor V101 --cents 600

Esse pedido posterior não pertence à liquidação de ontem. Se repetir o comando, o serviço recusa a duplicata; use python3 shop.py list para ver o pedido existente em vez de excluí-lo.

O env.sh fornecido contém os endereços dos serviços locais e lê o token de operador restrito de seu arquivo privado. source carrega essas atribuições no shell atual; export as disponibiliza aos comandos filhos. Um novo terminal precisa carregá-las novamente:

source env.sh

O token de operador autoriza solicitações OpenBao; não é uma senha de banco de dados. Este token pode obter e revogar concessões exatas dos papéis settlement-report e settlement-short. Não pode gerenciar o relatório de inventário independente nem ler a conexão de administrador do banco.

Leia as instruções corretas de criação de contas:

cat role.sql

Elas criam um login gerado com a expiração de senha fornecida, concedem localização no schema e acesso de leitura à view de liquidação e mantêm a auditoria SQL nativa. Mantenha essas instruções e as duas configurações de papéis inalteradas neste laboratório.

O papel normal de relatório tem dez minutos por padrão. Um papel preparado separado, settlement-short, dura trinta segundos e tem as mesmas permissões de view. Nenhum relógio começa até você solicitar credenciais. Você não precisa correr pela lição antes que credenciais criadas na preparação expirem.

Você pode emitir credenciais desses papéis, executar a consulta de relatório fornecida, salvar o relatório e as respostas privadas de credenciais e revogar as concessões exatas de relatório que obteve. Preserve os registros originais do banco, a loja, o papel e a concessão independentes de inventário, a consulta fornecida, o ambiente, o token de operador e o ambiente de execução preparado. Nunca revogue um prefixo inteiro de concessões.

Para um erro de digitação em um caminho, volte com o cd absoluto acima, execute ls e tente novamente com o nome real do arquivo. A mesma recuperação funciona sem reinicializar o ambiente.

Nesta etapa, você produzirá um relatório real antes de encerrar o acesso dessa tarefa. Permaneça em Terminal, com env.sh carregado.

umask 077 torna os arquivos recém-criados privados à sua conta. bao read -format=json solicita uma credencial dinâmica real e emite JSON; > salva o resultado em um arquivo em vez de exibir sua senha. Essa emissão inicia o relógio da concessão de dez minutos:

umask 077

bao read -format=json database/creds/settlement-report > lease.json

jq seleciona campos JSON. Leia o ID não secreto da concessão, a duração e o nome de usuário gerado do banco:

jq '.lease_id, .lease_duration, .data.username' lease.json

O ID de concessão identifica esta emissão no OpenBao; o nome de usuário identifica seu login PostgreSQL. Nenhum deles é o token de operador. Não sobrescreva essa resposta apenas para inspecioná-la novamente: você precisará de seu ID exato de concessão ao encerrar o acesso.

A opção -r remove as aspas do JSON. Substituições de comandos entre aspas carregam o nome de usuário e a senha gerados no ambiente do cliente de banco sem exibir a senha:

export PGUSER="$(jq -r .data.username lease.json)"

export PGPASSWORD="$(jq -r .data.password lease.json)"

psql -X ignora arquivos pessoais de inicialização do psql, -v ON_ERROR_STOP=1 para em erros SQL e -c fornece um comando SQL. Pergunte à conexão real qual identidade ela usa:

psql -X -v ON_ERROR_STOP=1 -c 'SELECT current_user;'

Espere seu nome de usuário recém-gerado. -f report.sql lê a consulta preparada; > salva sua saída real separada por tabulações:

psql -X -v ON_ERROR_STOP=1 -f report.sql > settlement.tsv

cat settlement.tsv

Espere as três linhas de vendedores com as mesmas contagens de pedidos pagos e totais do exemplo funcional. Execute a verificação de resultado somente de leitura:

sudo python3 /opt/labex-report/verify.py result

O verificador preparado usa sudo para ler evidências nativas protegidas e testar o SQL da política em um ambiente de teste isolado com conta comum. Não emite suas credenciais reais nem gera o relatório. Uma demonstração copiada sem uma consulta real de relatório sob a identidade emitida não passa.

Se você ler devagar e o login expirar antes da execução do relatório, solicite um substituto apenas uma vez, recarregue as duas variáveis de banco e execute novamente os comandos de identidade e relatório. Para uma emissão existente que você ainda pretende encerrar explicitamente, guarde sua resposta com um nome de arquivo separado antes de solicitar outra. Cada substituto usado para executar o relatório também deve ter sua própria concessão exata encerrada; a conclusão usa a execução real de relatório mais recente.

Revogue a Concessão Exata da Tarefa Concluída

Nesta etapa, você encerrará o acesso da tarefa de relatório e testará uma nova conexão com a credencial antiga salva. Permaneça em Terminal.

bao lease revoke solicita a revogação de uma emissão. A substituição $(jq -r .lease_id lease.json) entre aspas fornece o ID completo da concessão salva. Use esse ID exato, não um nome de usuário do banco nem um prefixo contendo outras concessões. Se essa emissão de dez minutos já tiver expirado enquanto você lia, a revogação poderá informar que sua concessão não foi mais encontrada. Para o exercício de revogação explícita, guarde essa resposta antiga, obtenha uma credencial substituta do papel normal com um novo nome de arquivo, recarregue as duas variáveis do banco, execute novamente o relatório e use o nome de arquivo do substituto no comando e na sondagem abaixo. Uma emissão já expirada não é evidência de sua revogação explícita:

bao lease revoke "$(jq -r .lease_id lease.json)"

A CLI pode dizer que as operações de revogação foram enfileiradas. Essa resposta sozinha não comprova que o PostgreSQL recusou o login antigo.

A sondagem preparada access.py lê a credencial salva e abre uma nova conexão TCP autenticada por senha. --wait-denied 10 permite até dez segundos para uma rejeição de senha. Ela distingue essa rejeição de um banco indisponível ou de uma consulta SQL recusada; parar o servidor não pode satisfazê-la:

python3 /opt/labex-report/access.py lease.json --wait-denied 10

Espere a mensagem password authentication failed do PostgreSQL seguida da confirmação de que essa credencial salva não consegue abrir uma nova conexão. A sondagem informa o status nativo 2 do psql. A própria sondagem retorna sucesso somente após confirmar a negação esperada.

echo $? exibe o status de saída do comando imediatamente anterior. Aqui, espere 0: a sondagem confirmou com sucesso a falha pretendida, em vez de o psql ter se conectado com sucesso:

echo $?

Verifique a tarefa concluída:

sudo python3 /opt/labex-report/verify.py finished

A verificação exige uma revogação nativa bem-sucedida da concessão exata, o evento correspondente de revogação concluída, uma falha posterior de nova autenticação e um login PostgreSQL efetivamente inutilizável. Também mantém intactos o relatório completo e as funções independentes de loja/relatório. Não revoga nada por você.

Este exercício testa conexões novas feitas por comandos clientes de curta duração. A expiração da senha não força o fechamento de todas as conexões já abertas, e esta lição não afirma esvaziar todos os pools de conexão de produção.

Observe uma Concessão Separada Expirar Naturalmente

Nesta etapa, você distinguirá a expiração natural de sua revogação explícita. Use Terminal com o mesmo operador restrito do OpenBao.

O papel preparado settlement-short tem um TTL de trinta segundos. Você solicitará sua credencial e testará imediatamente uma leitura real permitida em uma única operação, para que ler a explicação a seguir não consuma seu tempo útil. && executa a sondagem apenas se a emissão de credenciais tiver sucesso:

bao read -format=json database/creds/settlement-short > short-lease.json && python3 /opt/labex-report/access.py short-lease.json

Espere um nome de usuário gerado, a view real de liquidação com três linhas e Native psql exit: 0. Este é um nome de usuário e um ID de concessão diferentes dos da tarefa explicitamente revogada. A sondagem somente de leitura não cria seu arquivo de relatório nem conclui a tarefa de relatório por você.

Agora deixe essa concessão expirar sozinha. Não revogue nem renove short-lease.json. A sondagem a seguir abre conexões novas repetidamente, esperando até quarenta segundos por uma negação real de autenticação por senha:

python3 /opt/labex-report/access.py short-lease.json --wait-denied 40

Se você levou mais de trinta segundos para ler antes deste comando, a negação pode aparecer imediatamente. Isso ainda é expiração natural: a operação combinada anterior já provou que a credencial funcionava inicialmente. Caso contrário, a sondagem espera até a expiração. Espere a falha nativa do PostgreSQL e a confirmação da sondagem, como antes.

Um erro de conexão dizendo que o servidor está indisponível não é prova de expiração. Se a emissão inicial ou sua leitura imediata falhou, inspecione esse erro antes de repetir a operação combinada. Não apresente uma senha inválida nunca usada como evidência de que uma credencial funcional expirou. A verificação final exige a leitura bem-sucedida real do papel curto, o evento nativo de expiração e a recusa de autenticação posterior.

O relógio da concessão começou com sua solicitação, não com a preparação, e nenhuma etapa exige que você digite dentro de uma janela incidental de inicialização.

Nesta etapa, você concluirá uma tentativa posterior de relatório depois de as credenciais antigas terem parado de funcionar. Permaneça em Terminal. Recuperar significa obter uma nova credencial pelo serviço autorizado; editar uma resposta antiga não renova sua identidade no banco de dados.

Salve a nova emissão do papel normal com outro nome para que a evidência anterior seja mantida:

bao read -format=json database/creds/settlement-report > recovery-lease.json

Carregue essa nova identidade e execute o mesmo relatório real:

export PGUSER="$(jq -r .data.username recovery-lease.json)"

export PGPASSWORD="$(jq -r .data.password recovery-lease.json)"

psql -X -v ON_ERROR_STOP=1 -f report.sql > settlement.tsv

cat settlement.tsv

O resultado completo de negócio permanece inalterado. O nome de usuário do banco é novo, que é o caminho de recuperação esperado após o fim de uma emissão antiga.

Encerre também a concessão exata dessa tarefa substituta:

bao lease revoke "$(jq -r .lease_id recovery-lease.json)"

python3 /opt/labex-report/access.py recovery-lease.json --wait-denied 10

Se executar novamente o relatório usando outro login substituto, encerre também essa concessão exata. A verificação de conclusão usa a identidade por trás da execução real de relatório mais recente, portanto uma conta revogada anteriormente não prova que uma tarefa posterior terminou.

O cliente preparado da loja usa sua identidade de escrita independente. Confirme que o pedido normal de hoje permanece:

python3 shop.py list

Execute a verificação final do ciclo de vida:

sudo python3 /opt/labex-report/verify.py lifecycle

Ela lê os eventos nativos existentes de emissão, consulta, revogação e autenticação antes de fazer sondagens de preservação somente de leitura. Espere a confirmação de evidências distintas de revogação explícita, expiração natural e recuperação com login substituto, com as credenciais antigas testadas incapazes de abrir novas conexões. Os dados originais de relatório, a loja e a credencial independente de inventário devem permanecer intactos.

Se um comando de relatório falhar porque um substituto expirou enquanto você lia, guarde essa resposta, solicite outro substituto com um novo nome de arquivo, recarregue suas variáveis de banco, execute o relatório novamente e encerre essa nova concessão exata. Use os mesmos comandos ensinados com esse nome de arquivo. Não estenda a expiração do nome de usuário antigo nem revogue um prefixo inteiro de papel.

Resumo

Você executou um relatório real, encerrou sua concessão exata, observou uma credencial separada expirar naturalmente e recuperou o acesso com uma identidade recém-emitida cujo acesso de tarefa também encerrou. Distinguiu uma solicitação enfileirada de uma negação real do banco de dados e um serviço parado de uma senha recusada.

O resultado é deliberadamente limitado a novas conexões autenticadas por senha neste ambiente preparado. Não afirma que toda sessão já aberta ou todo pool de produção foi encerrado. O desafio combina a política de permissões e o ciclo de vida de tarefa concluída para uma view de relatório diferente.