[ad_1]
Os pods do Kubernetes são livres para se comunicar uns com os outros por padrão. Isso representa um risco de segurança quando seu cluster é usado para vários aplicativos ou computadores. Mau comportamento ou acesso mal-intencionado em um pod pode direcionar o tráfego para os outros pods em seu cluster.
Este artigo ensinará como evitar esse cenário configurando políticas de rede. Essas regras permitem que você controle os fluxos de tráfego de um pod para outro no nível do endereço IP (camada OSI 3 ou 4). Você pode definir com precisão as fontes de entrada e saída permitidas para cada Pod.
Como criar uma política de rede
As políticas de rede são criadas adicionando NetworkPolicy
objetos para seu cluster. Cada política define os pods aos quais se aplica e uma ou mais regras de entrada e saída. Aqui está um manifesto político básico:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: network-policy namespace: app spec: podSelector: matchLabels: component: database policyTypes: - Ingress - Egress ingress: - from: - podSelector: matchLabels: component: api egress: - to: - podSelector: matchLabels: component: api
Esta política de rede se aplica a qualquer pod com um component: database
etiqueta no app
namespaces Define que o tráfego de entrada (entrada) e de saída (saída) só é permitido de e para pods com um component: api
etiqueta. Quaisquer solicitações originadas de outros pods, como component: web-frontend
será bloqueado.
As políticas de rede podem ser aplicadas como qualquer outro objeto usando Kubectl. Eles entrarão em vigor imediatamente após sua criação. Você pode adicionar a política de rede antes de iniciar os pods selecionados.
$ kubectl apply -f policy.yaml networkingpolicy.networking.k8s.io/network-policy created
Como funcionam as políticas de rede
As políticas de rede são implementadas pelo plug-in de rede ativo do seu cluster. Suas políticas não terão efeito se seu plug-in não for compatível com o recurso. As opções mais populares, como Calico e Cilium, vêm com o suporte à política de rede ativado.
Quando uma política de rede é aplicada a um pod, o plug-in inspeciona seu tráfego para verificar se atende aos requisitos da política. Qualquer conexão que não atenda aos critérios será rejeitada. O pod que tentou iniciar a conexão descobrirá que o host remoto está inacessível porque estava tentando acessar um recurso bloqueado por uma regra de saída ou porque um pod remoto recusou a conexão de entrada usando uma regra de entrada.
Uma conexão bem-sucedida entre dois pods só pode ser estabelecida quando as políticas de rede em ambas as coisas deles permite. A conexão pode ser proibida por uma regra de saída no pod inicial ou uma regra de entrada no destino.
As políticas de rede são sempre aditivos nas naturezas. Quando várias políticas selecionam o mesmo pod, a lista de fontes de entrada e saída permitidas será a combinação de todas as políticas.
Exemplos de política de rede
As políticas de rede oferecem suporte a muitas opções diferentes para personalizar os pods para os quais eles apontam e os tipos de conexão permitidos. Os exemplos a seguir mostram vários casos de uso comuns.
Aplique uma política a cada pod no namespace, permitindo apenas o tráfego de entrada de um bloco de endereço IP específico
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: network-policy namespace: app spec: podSelector: {} policyTypes: - Ingress ingress: - from: - ipBlock: cidr: 172.17.0.0/16
O vazio podSelector
block significa que todos os pods no namespace são direcionados pela política. a ipBlock
A regra restringe o tráfego de entrada para pods com um endereço IP no intervalo especificado. O tráfego de saída não é bloqueado.
Permita o tráfego de entrada de um bloco de endereços IP, mas exclua alguns IPs específicos
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: network-policy namespace: app spec: podSelector: {} policyTypes: - Ingress ingress: - from: - ipBlock: cidr: 172.17.0.0/16 except: - 172.17.0.1/24 - 172.17.0.2/24 - 172.17.0.3/24
ipBlock
as regras suportam um except
campo para excluir o tráfego que se origina ou é direcionado para endereços IP específicos.
Permitir tráfego de entrada de todos os pods no namespace, mas apenas de uma porta específica
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: network-policy namespace: app spec: podSelector: {} policyTypes: - Ingress ingress: - from: - podSelector: {} ports: - protocol: TCP port: 443
a ports
O campo está disponível nas regras de entrada e saída. Define as portas das quais o tráfego pode ser recebido e enviado. Opcionalmente, você pode especificar um intervalo de portas, como 3000 – 3500, definindo o endPort
campo (3500) mais port
(3000).
Permitir tráfego de pods com uma tag específica que existe em um namespace diferente
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: network-policy namespace: database spec: podSelector: {} policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: application: demo-app podSelector: matchLabels: component: database
A política declara que qualquer pod é marcado component: database
pode alcançar todos os pods no database
namespace, se o seu próprio namespace estiver marcado demo-app
.
Você pode permitir o tráfego todo o mundo Pods em um namespace externo criando uma regra que inclui apenas um namespaceSelector
campo.
Permitir explicitamente todo o tráfego
Às vezes, você pode querer permitir explicitamente todo o tráfego de um determinado tipo dentro de um namespace. Inclua o tipo em sua política, mas forneça um seletor de pod vazio sem regras:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: network-policy namespace: app spec: podSelector: {} policyTypes: - Ingress - Egress ingress: - {} egress: - {}
Todos os pods no namespace são livres para se comunicar, como se não houvesse política. Criar a política de qualquer maneira permite que você indique suas intenções para outros usuários no cluster. Eles podem questionar a presença de um namespace com redes irrestritas em um cluster protegido.
Quando usar políticas de rede
As políticas de rede devem ser criadas para cada um dos namespaces e pods em seu cluster. Isso isola melhor seus pods e permite que você controle o fluxo de tráfego.
Tente tornar suas políticas o mais granulares possível. Expandir o acesso de forma muito ampla, como permitir acesso em todos os pods em um namespace, deixa você em risco se um de seus contêineres for comprometido. Considere o uso de seletores precisos para identificar controles remotos de entrada e saída individuais para pods sensíveis, como serviços de autenticação, bancos de dados e controladores de pagamento.
O Kubernetes não habilita nenhuma política de rede por padrão que possa permitir a ocorrência de descuidos, mesmo que você pretenda que todos os pods sejam protegidos por uma política. Você pode atenuar esse risco adicionando uma política geral aos seus namespaces. Esta política seleciona cada pod no namespace e aplica uma regra que proíbe toda comunicação de rede:
apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all namespace: app spec: podSelector: {} policyTypes: - Ingress - Egress
As políticas de rede são sempre limitadas a namespaces, portanto, você precisará criar um catchall separado para cada um.
Resumo
O Kubernetes permite que todos os pods em seu cluster se comuniquem entre si. Isso é muito permissivo para aplicativos do mundo real executados em clusters multiuso. As políticas de rede resolvem esse problema fornecendo um sistema semelhante a um firewall para gerenciar as fontes de entrada e os destinos de saída que cada pod aceita.
É uma boa prática definir uma política de rede em todos os seus pods. Isso protegerá seu cluster para que apenas fluxos de tráfego legítimos sejam permitidos. No entanto, as políticas de rede são apenas uma parte da segurança do Kubernetes: outros mecanismos de proteção, como contextos de segurança RBAC e Pod, também são ferramentas essenciais para proteger seu ambiente.
[ad_2]