Mantenha o Acesso ao Estoque Dentro da Aplicação

KubernetesBeginner
Pratique Agora

Introdução

A Meadow Supply tem um pequeno catálogo e uma simulação de orçamento de cesta em funcionamento. Sua página pública consulta a Shop API para obter a disponibilidade. API significa Application Programming Interface (interface de programação de aplicações): aqui, é a interface de requisições da aplicação entre a página do cliente e o serviço interno de estoque. Essa API lê o estoque para a página. Atualmente, o processo do cliente e um visitante separado também conseguem ler o estoque diretamente, incluindo detalhes de prateleiras de que o catálogo público não precisa.

Mantenha o fluxo normal do cliente funcionando enquanto restringe as conexões ao estoque ao papel de API aprovado no namespace aprovado. Seu resultado reutilizável é uma NetworkPolicy salva e o limite correspondente em execução, sustentados por requisições reais, em vez de um diagrama verde.

Você já deve conhecer caminhos básicos no terminal, YAML simples, namespaces, Pods, Deployments, Services e labels. Este laboratório explica os campos da política, o comando de diagnóstico fornecido e os resultados das requisições antes de usá-los. Um cluster Kubernetes real de um único nó com Calico, a aplicação e os dados sintéticos estão preparados. Não é necessário instalar o cluster, criar imagens nem programar a aplicação. O tempo é uma estimativa do autor que inclui leitura e erros comuns. Estes são orçamentos de treinamento: nenhum pedido, reserva ou pagamento é realizado.

Mantenha o Estoque no Caminho Aprovado

Nesta etapa, você permitirá que a Shop API acesse o estoque enquanto impede que os processos de cliente e visitante a contornem.

Comece na aba Shop. A Meadow Supply deve mostrar Good things for everyday e três produtos. Abra Glass water bottle, observe seu preço de $18.00 e Available · 6 in stock, depois escolha Try a basket quote com Quantity definida como 1. O resultado deve dizer Ready for collection, mostrar $18.00 e afirmar explicitamente que nada foi reservado, pedido ou pago. Use Back to product e depois Back to collection.

O caminho real da requisição é:

Página do cliente → Shop API → Serviço de estoque

A página do cliente é executada em seu próprio Pod. Abrir o site não transforma seu navegador em um Pod do cluster; as requisições ao estoque partem dos processos da aplicação preparada. A API lê o estoque por uma nova conexão de rede e o combina com os preços aprovados do catálogo. Ela não tem uma alternativa estática para os dados de estoque. Uma aba Reference separada mostra as notas de retirada da Meadow Dispatch. Abra-a, leia P-104 e P-108 e depois mude para Workspace. Esse serviço separado deve continuar funcionando.

O terminal começa em /home/labex/project/stock-policy. pwd exibe o diretório atual; ls lista suas entradas. Use o comando cd absoluto se precisar retornar aqui:

pwd
ls
cd /home/labex/project/stock-policy

Espere scope.json, starter e tools. cat exibe o arquivo de escopo preparado. Ele usa JSON (JavaScript Object Notation), um formato de texto de valores nomeados e listas. Ele lista nomes reais de recursos e destinos de requisições, em vez de um estado inventado de topologia:

cat scope.json

--context=labex-v135 seleciona o cluster real preparado. --show-labels exibe as labels dos objetos. Um namespace agrupa objetos, mas, por si só, não bloqueia suas conexões de rede. Leia as identidades dos namespaces:

kubectl --context=labex-v135 get namespaces meadow-shop meadow-stock meadow-visitors --show-labels

Cada um tem uma label interna kubernetes.io/metadata.name igual ao seu nome. -n seleciona um namespace. Leia os Pods e suas labels:

kubectl --context=labex-v135 -n meadow-shop get pods --show-labels
kubectl --context=labex-v135 -n meadow-stock get pods --show-labels
kubectl --context=labex-v135 -n meadow-visitors get pods --show-labels

O processo do cliente tem role=customer, a API tem role=shop-api e o estoque tem role=inventory. O serviço separado de expedição tem role=dispatch. O visitante está em meadow-visitors, mas tem deliberadamente a mesma label role=shop-api da API real. Portanto, uma label de papel sozinha não identifica um namespace aprovado.

Leia os Services. Um Service seleciona os Pods preparados e fornece um endereço estável. Uma porta identifica o ponto de escuta de uma aplicação. TCP (Transmission Control Protocol, protocolo de controle de transmissão) fornece a conexão usada por essas requisições web; o processo de estoque escuta na porta TCP 8080:

kubectl --context=labex-v135 -n meadow-stock get services

O ./tools/network-test fornecido executa uma requisição real a partir de uma identidade existente da aplicação usando kubectl exec. O ./ inicial significa que a ferramenta está no diretório atual. Seu primeiro argumento escolhe customer, api, visitor, stock ou reference; o próximo escolhe http, dns ou dns-tcp; o último é o destino. Ela nunca altera políticas nem conserta a aplicação. Requisições http usam HTTP (Hypertext Transfer Protocol, protocolo de transferência de hipertexto), o protocolo de requisição e resposta desses pontos web/API. O nome completo stock.meadow-stock.svc.cluster.local identifica o Service de estoque em seu namespace por meio do DNS do cluster (Domain Name System, sistema de nomes de domínio), que resolve nomes de Services em endereços.

Primeiro estabeleça a conexão e o conteúdo atuais. Espera-se que ambas as requisições tenham sucesso antes do isolamento:

./tools/network-test api http http://stock.meadow-stock.svc.cluster.local:8080/stock.json
./tools/network-test customer http http://stock.meadow-stock.svc.cluster.local:8080/stock.json

Espere HTTP_REPLY 200 seguido dos mesmos dados de estoque: bottle tem 6 unidades na prateleira M-03, notebook tem 4 em M-08 e bag tem 0 em M-12. O cliente deve obter a disponibilidade pública pela API, não fazer essa leitura interna direta. A verificação inicial comprova que o destino está ativo antes de você restringi-lo.

Uma NetworkPolicy seleciona Pods e permite conexões específicas para uma direção de tráfego. Ingresso significa conexões que chegam aos Pods selecionados. Assim que uma política de ingresso seleciona o estoque, somente seus caminhos de entrada permitidos permanecem disponíveis, além das exceções documentadas pelo Kubernetes para tráfego de nó e do próprio Pod. Isso é controle de rede de Pods, não autenticação de usuário nem autorização HTTP.

Crie seu diretório de versão. mkdir -p o cria se necessário e mantém um diretório existente. O comando cat a seguir grava a política completa em seu próprio arquivo de versão: > redireciona a saída para esse arquivo, e o marcador YAML entre aspas mantém o texto literal até o marcador final em uma linha própria. Repeti-lo substitui somente esse arquivo editável de política.

mkdir -p release
cat > release/stock-ingress.yaml <<'YAML'
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: stock-ingress
  namespace: meadow-stock
spec:
  podSelector:
    matchLabels:
      role: inventory
  policyTypes:
    - Ingress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: meadow-shop
          podSelector:
            matchLabels:
              role: shop-api
      ports:
        - protocol: TCP
          port: 8080
YAML

Leia o arquivo salvo antes de aplicá-lo:

cat release/stock-ingress.yaml

O podSelector externo seleciona apenas o estoque, deixando a expedição fora desta política. Dentro da única entrada from, namespaceSelector e podSelector devem corresponder ambos: a origem deve estar em meadow-shop e ter role=shop-api. Os dois seletores ficam alinhados sob o mesmo item da lista. Acrescentar outro hífen antes do podSelector interno criaria uma segunda alternativa, significando OR (OU), e permitiria outros Pods no namespace aprovado. A porta é a porta TCP de escuta do Pod de estoque. Essa regra não restringe a saída da API.

apply -f lê seu manifesto salvo e cria ou atualiza a política nomeada. Ele não reinicia a aplicação:

kubectl --context=labex-v135 apply -f release/stock-ingress.yaml

describe mostra como o Kubernetes interpretou a regra:

kubectl --context=labex-v135 -n meadow-stock describe networkpolicy stock-ingress

Leia o papel de estoque selecionado, o namespace de origem, o papel de API e a porta TCP. A aplicação efetiva da política pode levar alguns segundos para convergir. Primeiro confirme que a requisição original permitida ainda retorna os dados completos:

./tools/network-test api http http://stock.meadow-stock.svc.cluster.local:8080/stock.json

Agora teste os dois motivos diferentes pelos quais uma origem deve ser negada:

./tools/network-test customer http http://stock.meadow-stock.svc.cluster.local:8080/stock.json
./tools/network-test visitor http http://stock.meadow-stock.svc.cluster.local:8080/stock.json

Para estes dois últimos comandos, NETWORK_TIMEOUT e um código de saída diferente de zero são esperados. Customer está no namespace aprovado, mas tem o papel incorreto; Visitor tem o papel correspondente, mas está no namespace incorreto. Uma conexão recusada, um erro de DNS ou um destino parado não comprovam isolamento. A requisição bem-sucedida da API ao mesmo destino é o controle positivo. Se uma requisição repetida imediatamente ainda tiver sucesso logo após aplicar a política, espere alguns segundos e repita; não declare isolamento até que os caminhos realmente negados terminem por timeout.

Se um caminho for digitado incorretamente, use os comandos anteriores pwd, ls e cd absoluto e depois repita a operação que falhou. Se o YAML não puder ser analisado, leia seu arquivo de versão e compare a indentação e a posição dos hífens com o exemplo completo, reescreva esse arquivo editável e aplique-o novamente. Se a API também estiver bloqueada, inspecione describe e as labels e a porta já exibidas, corrija sua política salva e reaplique-a. Mantenha os namespaces, labels, cargas de trabalho, Pods, Services, aplicação, arquivos de origem e ferramenta de diagnóstico originais. Não pare o estoque, não altere labels, não use regras de IP de Pod/CIDR, não altere a rede do host nem reinicialize a VM para fabricar uma negação.

Verifique Todo o Fluxo do Cliente

Nesta etapa, você verificará a experiência completa do cliente após o isolamento e manterá utilizável o serviço separado de expedição.

Comece em Workspace, em /home/labex/project/stock-policy. Uma requisição direta ao estoque é intencionalmente bloqueada para Customer, mas Customer ainda deve acessar a Shop API. Solicite seu catálogo por esse caminho original:

./tools/network-test customer http http://api.meadow-shop.svc.cluster.local:8080/catalogue.json

Espere HTTP_REPLY 200 e os três produtos aprovados com os preços e unidades originais: Glass water bottle 1800 centavos / 6 unidades, Everyday notebook 1400 / 4, Canvas market bag 2400 / 0. A API também informa qual Pod original de estoque respondeu; a página pública não expõe esse detalhe de infraestrutura. O caminho bem-sucedido pela API e o caminho direto com falha são compatíveis: a API faz sua própria conexão permitida ao estoque.

Mude para Shop e recarregue. Abra Glass water bottle, defina Quantity como 2 e selecione Try a basket quote. Espere Ready for collection, Quantity 2, Total $36.00 e Units available 6. Leia o aviso de treinamento: nenhum estoque é reservado. Use Back to product e Back to collection.

Abra Canvas market bag, marcado como Back soon, e tente um orçamento para Quantity 1. Espere Not enough stock, Total $24.00 e Units available 0. Essa é uma resposta de negócio válida, não uma falha de rede; não altere o estoque para fazer todos os orçamentos terem sucesso. Use Back to product e depois Back to collection. Abra Our approach, leia a descrição dos orçamentos de treinamento e use Back to collection.

O catálogo concluído tem os três produtos originais e disponibilidade em tempo real; compare seu título, preços e disponibilidade com este exemplo em execução:

A coleção protegida da Meadow Supply

Mude para Reference e recarregue. P-104 · Ready e P-108 · Packed devem permanecer visíveis. Selecione Download notes e abra o download real de notes.json: ele contém os dois registros inalterados de expedição, não dados de estoque. O download do navegador e o espaço de trabalho do terminal são locais diferentes; esta tarefa não pede que você copie esse arquivo para o espaço de trabalho.

Retorne a Workspace e leia esse mesmo Service separado a partir de Customer:

./tools/network-test customer http http://dispatch.meadow-stock.svc.cluster.local:8080/notes.json

Espere HTTP_REPLY 200 e ambas as notas originais. A política selecionou os Pods de inventário, não todo o namespace de estoque. Mantenha o processo de expedição, os dados e o Service original; desligá-lo ocultaria uma regra excessivamente ampla.

Sua entrega é release/stock-ingress.yaml e o limite correspondente em execução. O catálogo completo e ambos os resultados dos orçamentos devem continuar pela aplicação original, enquanto os dois acessos diretos que contornam a API permanecem negados. Mantenha todos os arquivos de origem preparados, objetos da aplicação e Pods originais. Se uma página mostrar Live availability unavailable, retorne às verificações ensinadas de labels, políticas e requisições, corrija somente sua política de versão e reaplique-a; uma página estática substituta não é um conserto. Os testes aqui são requisições TCP reais finitas em um cluster preparado, não uma garantia de segurança em produção nem de disponibilidade ininterrupta.

Resumo

Você preservou o fluxo real cliente → API → estoque enquanto impedia leituras diretas do estoque tanto por um cliente com papel incorreto quanto por um visitante com papel correspondente em outro namespace. Sua política de ingresso salva expressa a relação entre namespace e papel, e o catálogo em execução, os orçamentos de treinamento e o serviço separado de expedição continuam funcionando.

NetworkPolicy controla caminhos de rede dos Pods, não a autenticação de clientes. Um timeout só é uma evidência útil quando o destino e a conexão aprovada continuam funcionando. O próximo laboratório independente considera a outra direção: a saída da API, o DNS e as permissões fornecidas por outras políticas.