Introdução
A chave de suporte exposta foi revogada. O serviço está disponível, mas a tarefa de resumo não autentica porque sua configuração privada ainda contém o valor antigo. O lote pendente daily ainda precisa do resumo.
Você aprenderá escopos, emitirá uma substituta, atualizará a configuração privada do worker e concluirá uma execução real de negócio. Também testará que o diretório de clientes continua proibido e o monitor independente permanece saudável. Este laboratório oferece seu próprio estado após a contenção, sem reutilizar a VM anterior.
Testar uma credencial somente de leitura
Nesta etapa, você distinguirá uma credencial inválida de uma válida com permissões insuficientes. O ambiente novo começa após a contenção: key_support_old está revogada, a tarefa usa seu segredo antigo e daily não foi processado. Não precisa dos arquivos nem da VM do laboratório anterior. Chaves e tokens de operador pertencem a esta VM; obtenha os valores aqui em vez de reutilizar credenciais de outro ambiente.
Workstation é o terminal de manutenção em /home/labex/project/repository. Integration executa como keyworker em /home/labex/project. Key Manager é a interface de manutenção do provedor. A API local está em http://127.0.0.1:8000; seu comportamento sintético é específico deste curso.
Um escopo permite uma operação nomeada. Privilégio mínimo concede apenas operações necessárias à tarefa, deixando as demais indisponíveis. O programa lê tickets e publica resumos; não lê o diretório de clientes.
| Operação | Escopo necessário | A tarefa precisa? |
|---|---|---|
GET /v1/tickets |
tickets:read |
Sim: entrada |
POST /v1/summaries |
summaries:write |
Sim: saída |
GET /v1/customers |
customers:read |
Não |
GET /v1/health |
health:read |
Não: monitor separado |
GET /v1/results |
tickets:read |
Consultar resumos recebidos |
Reconheça uma falha de permissão
Uma chave de demonstração somente de leitura é válida, mas não permite publicar. Em Workstation, envie uma requisição de publicação. curl -X POST escolhe a escrita; -H fornece cabeçalhos, -d o corpo JSON, -s oculta o progresso e -w mostra o estado. O objeto vazio {} basta, pois o provedor rejeita a permissão antes de validar o corpo: O cabeçalho Content-Type: application/json informa ao serviço que o corpo usa JSON.
curl -s -w '\nHTTP %{http_code}\n' -X POST -H 'Authorization: Bearer lab_demo_read_only' -H 'Content-Type: application/json' -d '{}' http://127.0.0.1:8000/v1/summaries
{"error":"Missing scope","required":"summaries:write"}
HTTP 403
Nesta API, 403 significa que houve autenticação, mas falta o escopo necessário. Já 401 rejeita a própria credencial. Uma chave de leitura não conclui uma tarefa de leitura e escrita; uma chave de acesso total permite demais. A substituta precisa dos dois escopos de negócio da tabela.
Emitir uma substituta dedicada
Nesta etapa, você emitirá uma substituta dedicada com os dois escopos escolhidos anteriormente. Guardará o segredo privadamente na próxima etapa. O nome é um rótulo útil; somente os escopos controlam as permissões.
Emita uma credencial dedicada
Em Workstation, imprima o token de operador com cat, que exibe um arquivo:
cat /home/labex/.config/keylab/operator-token
Em Key Manager, insira em Operator token, selecione Sign in e Open Key Manager. A autenticação de operador é separada das chaves de aplicação. Confirme que key_support_old já está Revoked.
Em Issue a key, preencha Name com Support summary replacement. Selecione somente tickets:read e summaries:write, depois Issue key. Aparecem um ID não secreto e Secret shown once. Copie o segredo que começa com lab_key_ antes de sair da página. O provedor armazena um hash, não um segredo recuperável. Um hash é uma impressão digital unidirecional: permite comparar um valor fornecido sem mostrar o original armazenado.
Se perder o valor, revogue a chave não usada pelo ID e emita outra. Não reutilize o valor exposto nem amplie permissões para corrigir um erro de cópia.
Salvar a configuração privada de execução
Nesta etapa, você salvará a substituta no arquivo privado da conta de serviço e verificará as permissões. Use Integration para todos os comandos abaixo.
A configuração de execução é o arquivo lido pelo programa ao funcionar. O worker lê /home/labex/project/runtime/job.ini a cada invocação, dispensando reinício. O exemplo do repositório é outro arquivo. Em Integration, veja a configuração atual:
cat /home/labex/project/runtime/job.ini
[integration]
api_key = lab_key_support_exposed
Mantenha segredos fora do repositório e do histórico de comandos. read do Bash aceita um valor em um prompt: -r preserva caracteres literais, -s oculta a entrada e -p imprime a mensagem. API_KEY é uma variável temporária do shell. Execute em Integration, cole o novo segredo quando solicitado e pressione Enter. A entrada fica oculta:
read -r -s -p 'Replacement key: ' API_KEY
printf escreve texto formatado. \n cria quebras de linha, %s insere o valor, aspas duplas o mantêm como um argumento e > substitui o arquivo indicado. O arquivo privado existente pertence a keyworker, a conta deste terminal:
printf '[integration]\napi_key = %s\n' "$API_KEY" > /home/labex/project/runtime/job.ini
Use chmod para definir permissões. O modo 600 permite leitura e escrita apenas ao proprietário; grupo e outras contas ficam sem acesso:
chmod 600 /home/labex/project/runtime/job.ini
ls -l mostra propriedade e permissões sem imprimir o segredo:
ls -l /home/labex/project/runtime/job.ini
Procure -rw------- e proprietário keyworker. Tamanho e data podem variar. Uma variável sozinha não atualiza o arquivo; salvar a configuração faz a próxima invocação usar a nova credencial.
Mantenha este terminal Integration aberto. API_KEY pertence a este shell, não a todos os terminais. A próxima etapa a utiliza para requisições independentes e depois a remove. Se fechar ou reconectar o terminal, repita esta etapa com o segredo atual de job.ini, mostrado pelo comando cat acima.
Concluir e verificar a execução de negócio
Nesta etapa, você processará daily e testará comportamentos permitidos e proibidos. O worker está preparado: mantenha /opt/keylab/worker.py inalterado. A tarefa é recuperar credenciais, não alterar o programa para contornar a autenticação.
Em Integration, execute o lote atribuído:
python3 /opt/keylab/worker.py daily
Read batch: daily (3 items)
{"batch":"daily","count":3,"subjects":["Reset password","Invoice copy","Delivery question"]}
Received batch: daily
Receiving key ID: ...
O ID receptor deve corresponder ao da substituta em Key Manager. Se ocorrer 401, confira se o segredo salvo corresponde à substituta ativa. Com 403, compare os escopos à tabela. Se necessário, revogue a substituta incorreta, emita outra adequada, atualize o arquivo privado e repita o lote. A repetição substitui o registro recebido em vez de criar resumos duplicados.
Inspecione o serviço receptor real
Continue no mesmo terminal Integration. A variável API_KEY da etapa anterior ainda está disponível; não é preciso digitar novamente o segredo exibido uma só vez.
Use o endpoint de resultados somente de leitura. Um pipeline | passa a resposta ao próximo programa; python3 -m json.tool executa o formatador JSON do Python com indentação legível:
curl -s -H "Authorization: Bearer $API_KEY" http://127.0.0.1:8000/v1/results | python3 -m json.tool
Encontre daily, seus três assuntos em payload e o key_id da substituta. O registro vem da API receptora, não de um arquivo local de sucesso. O backend também registra qual credencial leu os dados de origem.
Teste agora a requisição proibida ao diretório de clientes:
curl -s -w '\nHTTP %{http_code}\n' -H "Authorization: Bearer $API_KEY" http://127.0.0.1:8000/v1/customers
{"error":"Missing scope","required":"customers:read"}
HTTP 403
A rejeição esperada confirma a restrição. Use unset para remover a variável temporária quando não precisar mais dela; o arquivo de execução salvo permanece inalterado:
unset API_KEY
Em Workstation, confirme que a chave antiga continua inutilizável e o monitor está saudável:
curl -s -w '\nHTTP %{http_code}\n' -H 'Authorization: Bearer lab_key_support_exposed' http://127.0.0.1:8000/v1/tickets
{"error":"Invalid or revoked key"}
HTTP 401
curl -s -w '\nHTTP %{http_code}\n' -H 'Authorization: Bearer lab_key_monitor_only' http://127.0.0.1:8000/v1/health
{"status":"ok","integration":"monitor"}
HTTP 200
Por fim, git status --short lista de forma compacta arquivos modificados ou não rastreados do repositório:
git status --short
O percurso guiado não produz saída, pois apenas o arquivo privado foi modificado. Nunca coloque a substituta em um exemplo ou commit. Como mostrou o primeiro laboratório, o histórico pode guardar segredos após desaparecerem suas linhas visíveis.
Resumo
Você distinguiu falha de autenticação de falta de permissão, escolheu escopos de leitura e escrita, guardou privadamente um segredo exibido uma só vez e concluiu o resumo pendente. Verificou o registro recebido, a rejeição da chave antiga, a proibição de acesso a clientes e a disponibilidade do monitor. Uma rotação útil restaura o trabalho legítimo e remove o acesso da credencial exposta.



