Texto e documentos
Números e cálculo
Dados e formatos
Segurança
Desenvolvimento e DevOps
Inteligência Artificial
Finanças
Saúde & Bem-estar
Produtividade
Jogos & Entretenimento
Multimédia e design
Empresa
Guia de utilização
O que é

Cola os teus manifestos do Kubernetes (ou a saída de kubectl get pods,netpol,svc,ns -A -o yaml, ou de helm template) e calcula que pod se pode ligar a qual, de acordo com as suas NetworkPolicies, com a porta. Clica numa célula para ver porquê: que política isola cada lado e que regra o deixa passar. Além disso, avisa do que não leva a lado nenhum: Services sem pods, ConfigMaps ou Secrets que faltam, políticas que não selecionam nada.

As regras que quase toda a gente confunde

Um pod que nenhuma política seleciona NÃO está isolado: chega-lhe tudo. Para que uma ligação passe, têm de a permitir o egress da origem E o ingress do destino. Sem policyTypes, a política afeta sempre o ingress, e o egress só se tiver secção egress. E namespaceSelector com podSelector no MESMO elemento é «e»; em elementos separados, «ou».

Pod Security Standards

Para cada carga, o nível mais alto que cumpre (baseline ou restricted) e o que lhe falta para o seguinte, com as regras do admission controller oficial do Kubernetes 1.37. Se um namespace declara pod-security.kubernetes.io/enforce, avisa das cargas que esse namespace REJEITARIA ao criá-las, o que é uma falha silenciosa: o Deployment é criado e os seus pods não. Contrastado com os 4537 casos de teste do próprio controlador e com a sua biblioteca sobre mais de 700 cargas reais.

O que um pod comprometido poderia fazer

Se também colas os teus Role, ClusterRole e bindings, cada carga mostra o que a sua ServiceAccount pode fazer a partir da lista de riscos de escalada do guia oficial do Kubernetes (ler secrets, criar pods, exec, nodes/proxy, escalate, bind, impersonate…), em que âmbito e que binding o concede. E se o token está montado no pod: sem token, comprometer o pod não dá essas permissões. Usa o mesmo motor que o Laboratório de acessos. Não avalia resourceNames: uma permissão sobre UM secret aparece como «ler secrets», sobrestima-se mas não se esconde.

Validação face ao esquema

Verifica cada objeto face ao esquema OFICIAL da versão de Kubernetes que escolheres (da 1.33 à 1.37): campos que não existem, com o que provavelmente querias escrever, tipos errados (um «80» entre aspas onde devia ir um número), obrigatórios que faltam e apiVersion retiradas, com a versão em que desapareceram e para qual migrar. O esquema só é descarregado ao validar e só o dessa versão: cerca de 9 KB. Comparado com o kubeconform em modo estrito sobre mais de mil manifestos, reais e com erros injetados.

Até que ponto confiar?

Segue a especificação oficial de NetworkPolicy, e o seu resultado foi comparado com o netpol-analyzer (np-guard) em mais de uma centena de cenários do seu próprio repositório. O que NÃO calcula: as políticas próprias de cada CNI (CiliumNetworkPolicy, Calico), AdminNetworkPolicy, nem o tráfego a partir do próprio nó, que passa sempre. Se o teu CNI não aplicar NetworkPolicy, nenhuma delas faz nada.

Alcance de rede no KubernetesO pod A chega ao B? NetworkPolicy, portas e referências quebradas
Alcance de rede no KubernetesO pod A chega ao B? De acordo com as tuas NetworkPolicies, com a porta e o porquê. 100 % no teu navegador
Não é enviado nem guardado em lado nenhum: pode conter Secrets