Resumo

  • Kubernetes descreve NetworkPolicy como comportamento desejado para Pods selecionados. Regras de ingresso e saída são aditivas; uma conexão entre Pods exige permissão de egress na origem e de ingress no destino.
  • A documentação também restringe a inferência: sem um controlador de rede que a implemente, o objeto não tem efeito; o tratamento é eventual, a API não revela quando ocorreu, e o efeito sobre conexões já existentes é definido pela implementação.
  • Uma afirmação defensável sobre um fluxo requer registros separados da revisão de política, do estado de seletores e extremos, da implementação de rede, da observação temporal da conexão e de qualquer decisão distinta de identidade ou aplicação.

“Negar por padrão” pode fazer um YAML parecer um resultado de segurança já realizado. Não é. O valor de NetworkPolicy é declarativo: ela permite isolar Pods escolhidos para ingress, egress ou ambos e descreve as conexões que devem permanecer permitidas. Isso é uma decisão sobre a fronteira desejada. Não é prova de que determinada conexão foi negada, de que uma conexão permitida se estabeleceu ou de que uma carga se tornou segura.

O modelo do recurso fixa o primeiro limite. NetworkPolicySpec representa comportamento desejado. A política seleciona Pods, indica isolamento Ingress ou Egress e contém regras. Os efeitos não são negações ordenadas que se substituem; eles se somam. Quando um Pod é isolado em uma direção, o conjunto permitido é a união do que todas as políticas aplicáveis permitem. Para um Pod de origem chegar a um Pod de destino, o egress da origem e o ingress do destino precisam permitir a conexão. Essa regra explica um conjunto de políticas; não entrega endereço observado, porta, protocolo, hora, processo, caminho de pacote ou resultado de uma conexão.

O estado do seletor é outro fato. podSelector, namespaceSelector e ipBlock não são listas permanentes de extremos concretos. Labels mudam, Pods são substituídos e o roteamento de Service pode alterar o caminho. Kubernetes também alerta que mecanismos de ingresso e saída podem reescrever endereços. Quando isso ocorre, não é definido se a reescrita vem antes ou depois do processamento de NetworkPolicy; o comportamento pode variar por plugin, provedor de nuvem, implementação de Service ou combinação. Um manifesto pode descrever o escopo esperado sem decidir como um pacote concreto foi representado no ponto de aplicação.

A implementação é outra superfície de prova. Kubernetes diz que NetworkPolicy é implementada pelo plugin de rede. Criar o recurso sem um controlador que a implemente não tem efeito, embora a API permaneça presente. Não é acusação contra produto ou administrador. Um objeto aceito pelo servidor de API prova somente a aceitação no plano de controle; não prova capacidade, configuração, saúde ou atividade do componente de plano de dados.

O tempo torna a conclusão ainda mais limitada. Kubernetes informa que uma NetworkPolicy criada será tratada eventualmente, mas a API não mostra o instante exato. A documentação também descreve visões levemente inconsistentes enquanto Pods ou políticas mudam. Se uma mudança afeta uma conexão existente, o efeito depende da implementação. Não são brechas; são razões para não exigir que uma fotografia de configuração conte uma execução que ela não preserva.

O escopo de protocolo é outro limite. NetworkPolicy é definida para conexões TCP, UDP e, opcionalmente, SCTP de camada 4. Para outros protocolos, o comportamento pode variar entre plugins. Uma fronteira aparente não deve virar afirmação universal sobre cada pacote, caminho hostNetwork, service mesh, criptografia, identidade de workload, autenticação, DNS, autorização de aplicação ou entrega. Cada superfície pede evidência própria.

Daniel Kade propõe um recibo de fluxo em cinco partes. Primeiro, a revisão de política: namespace, identidade do objeto, generation ou captura imutável, seletor, direção, regras e hora. Segundo, estado dos seletores e extremos: labels de Pod e Namespace, mapeamento de IP ou endpoint e instante de leitura. Terceiro, implementação de rede: capacidade declarada de NetworkPolicy, versão, configuração relevante e prova de saúde. Quarto, uma observação temporal de conexão com origem e destino como observados, protocolo, porta, direção, resultado, coletor e limites de visibilidade.

Quinto, um registro independente para identidade de workload, autorização, TLS, DNS, resposta de aplicação ou implantação. Detalhes sensíveis podem continuar protegidos sem fundir esses registros.

O método também descreve resultados comuns. Uma política correta pode coexistir com uma falha independente que impede a conexão. Um fluxo permitido nos dois sentidos ainda pode falhar em DNS, TLS, autenticação ou aplicação. A política pode ser aceita pela API antes de um plugin específico efetivá-la. Nada disso prova defeito ou incidente. Apenas mostra por que um manifesto não deve carregar sozinho a história inteira de um fluxo.

Fontes

  1. Kubernetes — Network Policies
  2. Kubernetes — Services, Load Balancing, and Networking
  3. Referência da API Kubernetes — NetworkPolicy v1