Introdução
Uma tarefa de resumo de suporte lê tickets de clientes e publica uma síntese breve. Alguém removeu sua chave de API do exemplo mais recente do repositório, mas as requisições com esse valor continuam funcionando. Você é responsável por investigar o alerta.
Primeiro conheça o fluxo normal, depois recupere as evidências históricas, identifique a credencial e a revogue. Você usará um provedor local sintético, dois papéis de terminal preparados e Key Manager. Basta familiaridade básica com o terminal; Git, requisições de API e revogação são apresentados aqui.
Ler um ticket pela API
Nesta etapa, você enviará uma requisição de leitura de tickets e aprenderá a reconhecer a resposta.
Selecione a aba Workstation na interface do laboratório para começar esta etapa.
Antes de investigar a credencial, veja o funcionamento normal da integração de suporte. Um ticket é uma solicitação de ajuda de um cliente. A tarefa de resumo é um programa preparado que lê um lote de tickets e envia uma síntese breve ao serviço. Uma integração é simplesmente um programa trabalhando com outro.
Este laboratório usa um provedor local de treinamento com clientes e chaves sintéticos. Sua API implementa autenticação e verificações reais de permissão, mas não replica um provedor de nuvem. Não envolve contas reais nem alvos externos.
Use os dois papéis de terminal
Workstation é o terminal de manutenção, aberto em /home/labex/project/repository, com exemplos de configuração. Integration executa como keyworker, a conta proprietária da configuração privada da tarefa. Use o terminal indicado para cada comando; mudar de diretório não muda a conta. A aba Key Manager administra credenciais por um login separado de operador.
Em Workstation, pwd imprime o diretório atual e ls lista os nomes de arquivos:
Mude para a aba Workstation antes de executar o comando a seguir.
pwd
/home/labex/project/repository
ls
Você deverá ver README.md e summary-example.ini. São exemplos do repositório, não o arquivo privado lido pela tarefa em execução.
Entenda a interface de requisições
Uma API é a interface de um serviço para requisições de programas. Um endpoint combina operação e caminho. Aqui, GET /v1/tickets lê tickets e POST /v1/summaries publica um resumo. http://127.0.0.1:8000 aponta para o serviço local desta VM: 127.0.0.1 significa esta máquina e 8000 é a porta de escuta.
As requisições levam uma chave de API, um valor secreto que autentica o programa. Ela é enviada no cabeçalho Authorization, um metadado nomeado da requisição. O provedor espera Bearer seguido do segredo. Mantenha as chaves sintéticas do exercício separadas de credenciais reais.
Mude para a aba Workstation. Faça uma leitura. curl envia uma requisição HTTP; -s oculta o progresso e -H fornece um cabeçalho. Aspas simples mantêm juntos os espaços e o separador de consulta ?. batch=demo seleciona os dados de prática:
curl -s -H 'Authorization: Bearer lab_key_support_exposed' 'http://127.0.0.1:8000/v1/tickets?batch=demo'
A resposta é JSON, um formato de campos nomeados e valores. batch identifica os dados; items é uma lista cujo ticket tem id e subject. request_id é um identificador variável de auditoria, não um segredo. Procure o assunto Delivery question.
Publicar um resumo de demonstração
Nesta etapa, você usará o worker preparado para transformar os tickets lidos em um resumo aceito pelo serviço. A etapa anterior apenas leu os dados; este programa também publica o resultado.
Selecione a aba Integration na interface do laboratório para começar esta etapa.
Mude para a aba Integration. Execute o worker no mesmo lote de demonstração. python3 executa o programa Python fornecido; o caminho identifica o programa e demo é o argumento do lote. Você não precisa escrever nem entender Python neste curso:
Mude para a aba Integration antes de executar o comando a seguir.
python3 /opt/keylab/worker.py demo
Read batch: demo (1 items)
{"batch":"demo","count":1,"subjects":["Delivery question"]}
Received batch: demo
Receiving key ID: key_support_old
A primeira requisição leu a entrada; a segunda publicou o resumo. Received batch significa que a API receptora o aceitou. Um ID como key_support_old é um rótulo não secreto, diferente do segredo enviado no cabeçalho. Esta execução mostra o comportamento normal e não conclui o lote atribuído ao laboratório posterior de recuperação.
Encontrar e revogar a chave histórica
Nesta etapa, você encontrará a credencial histórica, relacionará seu ID ao registro do provedor e revogará essa chave exata. Apagar uma linha visível pode ocultá-la do arquivo atual sem invalidar a credencial.
Selecione a aba Workstation na interface do laboratório para começar esta etapa.
Leia o presente antes do passado
Mude para a aba Workstation. Imprima o exemplo atual com cat. Um arquivo INI agrupa configurações sob seções entre colchetes, como [integration]; cada configuração tem nome, sinal de igual e valor:
Mude para a aba Workstation antes de executar o comando a seguir.
cat summary-example.ini
[integration]
key_id = key_support_old
api_key = SET_AT_RUNTIME
O marcador é adequado para um exemplo compartilhável, mas nada informa sobre cópias anteriores ou o estado da chave no serviço.
Git registra snapshots do projeto chamados commits. O repositório contém os arquivos atuais e esse histórico. git log lista primeiro os commits mais recentes; --oneline produz uma linha curta por commit. A opção global --no-pager imprime diretamente no terminal, sem abrir um visualizador interativo:
git --no-pager log --oneline
Você verá Document prepared worker, Remove credential from current example e Add integration example. Os identificadores curtos à esquerda podem variar.
HEAD representa o commit mais recente; HEAD~2, dois commits antes. git show exibe um objeto histórico; os dois-pontos separam a revisão do nome do arquivo:
git --no-pager show HEAD~2:summary-example.ini
[integration]
key_id = key_support_old
api_key = lab_key_support_exposed
O segredo original ainda pode ser recuperado. Apagar o exemplo atual ou reescrever o histórico local não informa à API que pare de confiar nas cópias já obtidas por outras pessoas.
Relacione a credencial ao registro do provedor
Key Manager usa um token de operador, uma credencial de manutenção separada. Uma chave de aplicação não pode administrar chaves. Mude para a aba Workstation. Mostre o token local preparado:
cat /home/labex/.config/keylab/operator-token
Mude para a aba Key Manager, cole o valor em Operator token, selecione Sign in e Open Key Manager. Não coloque esse token no repositório. Se o login for recusado, selecione Return to Key Manager nessa mesma aba, mude para a aba Workstation para copiar novamente o token de operador desta VM e volte à aba Key Manager para tentar de novo. Encontre a linha key_support_old com estado Active. Seus escopos descrevem operações permitidas; o próximo laboratório ensinará a escolhê-los.
Em Recent API requests, encontre uma requisição bem-sucedida dessa chave. O estado 200 significa leitura aceita pela API. O histórico prova a exposição e a requisição prova que a credencial funciona; nenhum identifica quem fez as requisições anteriores. Não é necessário relatório nem cópia de logs.
Revogue a chave identificada
Revogue somente a chave comprometida. Você testará a rejeição e a disponibilidade independente na próxima etapa. A revogação muda a decisão de aceitação do provedor; não apaga cópias do segredo.
Mude para a aba Workstation. Solicite novamente os tickets de demonstração, agora com o estado HTTP. -w acrescenta um resultado formatado; \n cria uma nova linha e %{http_code} insere o estado da resposta:
curl -s -w '\nHTTP %{http_code}\n' -H 'Authorization: Bearer lab_key_support_exposed' 'http://127.0.0.1:8000/v1/tickets?batch=demo'
A resposta termina em HTTP 200. Mude para a aba Key Manager. Selecione Revoke na linha key_support_old. Confira o ID: revogar todas as chaves interromperia trabalhos independentes. A linha deverá mostrar Revoked.
Testar a contenção e a disponibilidade
Nesta etapa, você testará a rejeição da credencial antiga enquanto a API e o monitor independente continuam disponíveis. O estado do gestor ajuda, mas requisições reais estabelecem o limite de acesso.
Selecione a aba Workstation na interface do laboratório para começar esta etapa.
Repita a mesma requisição na aba Workstation:
Mude para a aba Workstation antes de executar o comando a seguir.
curl -s -w '\nHTTP %{http_code}\n' -H 'Authorization: Bearer lab_key_support_exposed' 'http://127.0.0.1:8000/v1/tickets?batch=demo'
{"error":"Invalid or revoked key"}
HTTP 401
Nesta API, 401 significa que a credencial fornecida não pode autenticar. Essa rejeição esperada confirma a contenção. Um erro de conexão significaria que o serviço não está acessível; pará-lo não é uma correção.
Mude para a aba Integration. Execute o worker outra vez:
Mude para a aba Integration antes de executar o comando a seguir.
python3 /opt/keylab/worker.py demo
HTTP 401: {"error":"Invalid or revoked key"}
Este comando deve terminar com falha. A tarefa ainda lê o valor revogado de seu arquivo privado e não consegue ler a entrada. Uma pausa temporária é aceitável durante a contenção. O próximo laboratório começa desse estado e restaura a tarefa.
Volte à aba Workstation. Teste o monitor independente. Ele usa sua própria credencial e o endpoint de saúde:
Mude para a aba Workstation antes de executar o comando a seguir.
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
Você removeu o acesso da credencial exposta e manteve disponíveis o serviço e a integração independente. Pode avançar até a recuperação; o laboratório não penaliza uma restauração válida.
Resumo
Você acompanhou uma integração funcional, distinguiu o ID da chave de seu segredo, recuperou um segredo do histórico do Git e revogou a credencial correspondente. Testou a rejeição real e a disponibilidade independente. Apagar uma linha não invalidou a chave; revogá-la, sim. O próximo laboratório restaura a tarefa com uma substituta dedicada e restrita.
