APRENDER. PRATICAR. EVOLUIR.Descrever o fluxo antes de corrigir a policy
Regista origem, namespace, labels, destino, protocolo e porta. Se ambos os extremos estão isolados na direção relevante, a saída da origem e a entrada do destino precisam de permitir a ligação. DNS funcional e um processo a escutar ajudam o diagnóstico, mas não substituem essa autorização. No batch do exercício, egress já permite o destino e o problema está nos labels selecionados por ingress. Usa esta informação para reduzir hipóteses. Não abras todas as origens apenas porque o fecho está próximo; relaciona a correção com a fronteira aprovada.
Tratar labels como contrato de release
Um fornecedor muda role=settler para role=worker para padronizar manifests. A policy continua a selecionar o valor anterior e a nova ligação falha. O gestor técnico deve incluir selectors no impacto da mudança de labels, tal como inclui consumidores de uma API. No peer com apenas podSelector, o âmbito é o namespace da policy; não assumes todos os namespaces. O ensaio deve comparar um cliente autorizado com outro que deva ser recusado. Guarda os labels efetivamente publicados e não apenas o template que alguém planeava usar na janela.
Escolher o controlo que entende o requisito
Permitir /status e impedir /admin na mesma porta é uma condição de aplicação. NetworkPolicy padrão não oferece um campo de caminho HTTP para essa decisão. Combina a fronteira de rede com autorização adequada no serviço ou proxy, conforme a arquitetura. Da mesma forma, runtimeClassName:sandbox não prova sozinho que o isolamento pretendido existe. Confirma handler, configuração e limitações. A revisão de arquitetura deve ligar cada requisito ao mecanismo que o aplica e à evidência observável, evitando aceitar um nome de objeto como prova de proteção suficiente.
Avaliar exceções pela identidade que cria o Pod
Uma exemption de Pod Security Admission não conserva automaticamente warn e audit enquanto ignora enforce: os três modos são ignorados para pedidos abrangidos. Além disso, isentar o autor de um Deployment não isenta a identidade diferente que cria os Pods. Antes de propor isenção do controlador, considera o alcance sobre todos os workloads que ele pode criar. Prefere corrigir o template e validar o requisito funcional. Qualquer exceção precisa de âmbito explícito, responsável, prazo e método de observação que continue a fornecer a evidência necessária à operação.
Controlar a referência e o significado da contenção
Fixar uma versão PSA ensaiada torna explícita a referência durante uma atualização; também exige planear a revisão posterior. Usar latest não oferece uma referência minor imutável. Em resposta a incidente, distingue outro limite: uma policy que bloqueia ligações novas pode não terminar sessões existentes, dependendo do plugin. No exercício, o fluxo antigo continua a transferir bytes. O resultado contradiz a declaração de contenção completa. Aciona o mecanismo autorizado que cubra esse fluxo, preservando evidência e capacidade saudável conforme o plano de resposta acordado.
Construir critérios de aceitação por mudança
Para uma release, verifica configuração publicada, identidade usada, caminhos permitidos e caminhos proibidos. Para contenção, acrescenta sessões existentes e resultado da ação executada. Para atualização, regista a versão de política ensaiada e quem avalia a seguinte. Organiza o handover por afirmações verificáveis, como cliente A pode ligar ou cliente B é recusado, com prazo e evidência. Estes critérios ajudam APS a repetir o diagnóstico sem depender de quem escreveu o manifesto. A prática apresentada é sintética; um laboratório autorizado continua necessário para observar o comportamento do plugin e do cluster reais.
Uma ligação nova é recusada após contenção, mas a sessão antiga continua: o incidente só pode avançar quando esse fluxo também for tratado.
Armadilhas comuns
Assumir que ingress basta; confundir nome de porta com caminho HTTP; isentar controladores amplamente; afirmar contenção apenas com ligações novas.
Tópicos relacionados: NetworkPolicy e selectors · PSA e resposta a incidentes
Uma fronteira útil mantém o fluxo aprovado e demonstra a recusa pretendida sob as condições efetivas da mudança.
Referência: Network policies · Kubernetes v1.35; current six-domain CKS outline