From 14efc9881b7def663ad8ab4688528f3762f80e86 Mon Sep 17 00:00:00 2001 From: Ricardo Katz Date: Fri, 2 Jul 2021 12:26:13 -0300 Subject: [PATCH] Add initial pt translation to network policy (#27331) * Translate networkpolicy to pt-br Signed-off-by: Ricardo Pchevuzinske Katz * Fix translation by reviewer suggestions * Add missing example files * Fix review --- .../concepts/services-networking/_index.md | 14 + .../services-networking/network-policies.md | 345 ++++++++++++++++++ .../network-policy-allow-all-egress.yaml | 11 + .../network-policy-allow-all-ingress.yaml | 11 + .../network-policy-default-deny-all.yaml | 10 + .../network-policy-default-deny-egress.yaml | 9 + .../network-policy-default-deny-ingress.yaml | 9 + 7 files changed, 409 insertions(+) create mode 100755 content/pt-br/docs/concepts/services-networking/_index.md create mode 100644 content/pt-br/docs/concepts/services-networking/network-policies.md create mode 100644 content/pt-br/examples/service/networking/network-policy-allow-all-egress.yaml create mode 100644 content/pt-br/examples/service/networking/network-policy-allow-all-ingress.yaml create mode 100644 content/pt-br/examples/service/networking/network-policy-default-deny-all.yaml create mode 100644 content/pt-br/examples/service/networking/network-policy-default-deny-egress.yaml create mode 100644 content/pt-br/examples/service/networking/network-policy-default-deny-ingress.yaml diff --git a/content/pt-br/docs/concepts/services-networking/_index.md b/content/pt-br/docs/concepts/services-networking/_index.md new file mode 100755 index 0000000000..cbe38ae33a --- /dev/null +++ b/content/pt-br/docs/concepts/services-networking/_index.md @@ -0,0 +1,14 @@ +--- +title: "Serviços, balanceamento de carga e conectividade" +weight: 60 +description: > + Conceitos e recursos por trás da conectividade no Kubernetes. +--- + +A conectividade do Kubernetes trata quatro preocupações: +- Contêineres em um Pod se comunicam via interface _loopback_. +- A conectividade do cluster provê a comunicação entre diferentes Pods. +- O recurso de _Service_ permite a você expor uma aplicação executando em um Pod, +de forma a ser alcançável de fora de seu cluster. +- Você também pode usar os _Services_ para publicar serviços de consumo interno do +seu cluster. diff --git a/content/pt-br/docs/concepts/services-networking/network-policies.md b/content/pt-br/docs/concepts/services-networking/network-policies.md new file mode 100644 index 0000000000..2c45902e40 --- /dev/null +++ b/content/pt-br/docs/concepts/services-networking/network-policies.md @@ -0,0 +1,345 @@ +--- +title: Políticas de rede +content_type: concept +weight: 50 +--- + + + +Se você deseja controlar o fluxo do tráfego de rede no nível do endereço IP ou de portas TCP e UDP +(camadas OSI 3 e 4) então você deve considerar usar Políticas de rede (`NetworkPolicies`) do Kubernetes para aplicações +no seu cluster. `NetworkPolicy` é um objeto focado em aplicações/experiência do desenvolvedor +que permite especificar como é permitido a um {{< glossary_tooltip text="pod" term_id="pod">}} +comunicar-se com várias "entidades" de rede. + +As entidades que um Pod pode se comunicar são identificadas através de uma combinação dos 3 +identificadores à seguir: + +1. Outros pods que são permitidos (exceção: um pod não pode bloquear a si próprio) +2. Namespaces que são permitidos +3. Blocos de IP (exceção: o tráfego de e para o nó que um Pod está executando sempre é permitido, +independentemente do endereço IP do Pod ou do Nó) + +Quando definimos uma política de rede baseada em pod ou namespace, utiliza-se um {{< glossary_tooltip text="selector" term_id="selector">}} +para especificar qual tráfego é permitido de e para o(s) Pod(s) que correspondem ao seletor. + +Quando uma política de redes baseada em IP é criada, nós definimos a política baseada em blocos de IP (faixas CIDR). + + +## Pré requisitos + +As políticas de rede são implementadas pelo [plugin de redes](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). Para usar +uma política de redes, você deve usar uma solução de redes que suporte o objeto `NetworkPolicy`. +A criação de um objeto `NetworkPolicy` sem um controlador que implemente essas regras não tem efeito. + +## Pods isolados e não isolados + +Por padrão, pods não são isolados; eles aceitam tráfego de qualquer origem. + +Os pods tornam-se isolados ao existir uma `NetworkPolicy` que selecione eles. Uma vez que +exista qualquer `NetworkPolicy` no namespace selecionando um pod em específico, aquele pod +irá rejeitar qualquer conexão não permitida por qualquer `NetworkPolicy`. (Outros pod no mesmo +namespace que não são selecionados por nenhuma outra `NetworkPolicy` irão continuar aceitando +todo tráfego de rede.) + +As políticas de rede não conflitam; elas são aditivas. Se qualquer política selecionar um pod, +o pod torna-se restrito ao que é permitido pela união das regras de entrada/saída de tráfego definidas +nas políticas. Assim, a ordem de avaliação não afeta o resultado da política. + +Para o fluxo de rede entre dois pods ser permitido, tanto a política de saída no pod de origem +e a política de entrada no pod de destino devem permitir o tráfego. Se a política de saída na +origem, ou a política de entrada no destino negar o tráfego, o tráfego será bloqueado. + +## O recurso NetworkPolicy {#networkpolicy-resource} + +Veja a referência [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) para uma definição completa do recurso. + +Uma `NetworkPolicy` de exemplo é similar ao abaixo: + +```yaml +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: test-network-policy + namespace: default +spec: + podSelector: + matchLabels: + role: db + policyTypes: + - Ingress + - Egress + ingress: + - from: + - ipBlock: + cidr: 172.17.0.0/16 + except: + - 172.17.1.0/24 + - namespaceSelector: + matchLabels: + project: myproject + - podSelector: + matchLabels: + role: frontend + ports: + - protocol: TCP + port: 6379 + egress: + - to: + - ipBlock: + cidr: 10.0.0.0/24 + ports: + - protocol: TCP + port: 5978 +``` + +{{< note >}} +Criar esse objeto no seu cluster não terá efeito a não ser que você escolha uma +solução de redes que suporte políticas de rede. +{{< /note >}} + +__Campos obrigatórios__: Assim como todas as outras configurações do Kubernetes, uma `NetworkPolicy` +necessita dos campos `apiVersion`, `kind` e `metadata`. Para maiores informações sobre +trabalhar com arquivos de configuração, veja +[Configurando containeres usando ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/), +e [Gerenciamento de objetos](/docs/concepts/overview/working-with-objects/object-management). + +__spec__: A [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) contém todas as informações necessárias +para definir uma política de redes em um namespace. + +__podSelector__: Cada `NetworkPolicy` inclui um `podSelector` que seleciona o grupo de pods +que a política se aplica. A política acima seleciona os pods com a _label_ "role=db". Um `podSelector` +vazio seleciona todos os pods no namespace. + +__policyTypes__: Cada `NetworkPolicy` inclui uma lista de `policyTypes` que pode incluir `Ingress`, +`Egress` ou ambos. O campo `policyTypes` indica se a política se aplica ao tráfego de entrada +com destino aos pods selecionados, o tráfego de saída com origem dos pods selecionados ou ambos. +Se nenhum `policyType` for definido então por padrão o tipo `Ingress` será sempre utilizado, e o +tipo `Egress` será configurado apenas se o objeto contiver alguma regra de saída. (campo `egress` a seguir). + +__ingress__: Cada `NetworkPolicy` pode incluir uma lista de regras de entrada permitidas através do campo `ingress`. +Cada regra permite o tráfego que corresponde simultaneamente às sessões `from` (de) e `ports` (portas). +A política de exemplo acima contém uma regra simples, que corresponde ao tráfego em uma única porta, +de uma das três origens definidas, sendo a primeira definida via `ipBlock`, a segunda via `namespaceSelector` e +a terceira via `podSelector`. + +__egress__: Cada política pode incluir uma lista de regras de regras de saída permitidas através do campo `egress`. +Cada regra permite o tráfego que corresponde simultaneamente às sessões `to` (para) e `ports` (portas). +A política de exemplo acima contém uma regra simples, que corresponde ao tráfego destinado a uma +porta em qualquer destino pertencente à faixa de IPs em `10.0.0.0/24`. + +Então a `NetworkPolicy` acima: + +1. Isola os pods no namespace "default" com a _label_ "role=db" para ambos os tráfegos de entrada +e saída (se eles ainda não estavam isolados) +2. (Regras de entrada/ingress) permite conexões para todos os pods no namespace "default" com a _label_ "role=db" na porta TCP 6379 de: + + * qualquer pod no namespace "default" com a _label_ "role=frontend" + * qualquer pod em um namespace que tenha a _label_ "project=myproject" (aqui cabe ressaltar que o namespace que deve ter a _label_ e não os pods dentro desse namespace) + * IPs dentro das faixas 172.17.0.0–172.17.0.255 e 172.17.2.0–172.17.255.255 (ex.:, toda 172.17.0.0/16 exceto 172.17.1.0/24) + +3. (Regras de saída/egress) permite conexões de qualquer pod no namespace "default" com a _label_ +"role=db" para a faixa de destino 10.0.0.0/24 na porta TCP 5978. + +Veja o tutorial [Declarando uma política de redes](/docs/tasks/administer-cluster/declare-network-policy/) para mais exemplos. + +## Comportamento dos seletores `to` e `from` + +Existem quatro tipos de seletores que podem ser especificados nas sessões `ingress.from` ou +`egress.to`: + +__podSelector__: Seleciona Pods no mesmo namespace que a política de rede foi criada, e que deve +ser permitido origens no tráfego de entrada ou destinos no tráfego de saída. + +__namespaceSelector__: Seleciona namespaces para o qual todos os Pods devem ser permitidos como +origens no caso de tráfego de entrada ou destino no tráfego de saída. + +__namespaceSelector__ *e* __podSelector__: Uma entrada `to`/`from` única que permite especificar +ambos `namespaceSelector` e `podSelector` e seleciona um conjunto de Pods dentro de um namespace. +Seja cuidadoso em utilizar a sintaxe YAML correta; essa política: + +```yaml + ... + ingress: + - from: + - namespaceSelector: + matchLabels: + user: alice + podSelector: + matchLabels: + role: client + ... +``` +contém um único elemento `from` permitindo conexões de Pods com a label `role=client` em +namespaces com a _label_ `user=alice`. Mas *essa* política: + +```yaml + ... + ingress: + - from: + - namespaceSelector: + matchLabels: + user: alice + - podSelector: + matchLabels: + role: client + ... +``` + +contém dois elementos no conjunto `from` e permite conexões de Pods no namespace local com +a _label_ `role=client`, *OU* de qualquer outro Pod em qualquer outro namespace que tenha +a label `user=alice`. + +Quando estiver em dúvida, utilize o comando `kubectl describe` para verificar como o +Kubernetes interpretou a política. + +__ipBlock__: Isso seleciona um conjunto particular de faixas de IP a serem permitidos como +origens no caso de entrada ou destinos no caso de saída. Devem ser considerados IPs externos +ao cluster, uma vez que os IPs dos Pods são efêmeros e imprevisíveis. + +Os mecanismos de entrada e saída do cluster geralmente requerem que os IPs de origem ou destino +sejam reescritos. Em casos em que isso aconteça, não é definido se deve acontecer antes ou +depois do processamento da `NetworkPolicy` que corresponde a esse tráfego, e o comportamento +pode ser diferente para cada plugin de rede, provedor de nuvem, implementação de `Service`, etc. + +No caso de tráfego de entrada, isso significa que em alguns casos você pode filtrar os pacotes +de entrada baseado no IP de origem atual, enquanto que em outros casos o IP de origem que +a `NetworkPolicy` atua pode ser o IP de um `LoadBalancer` ou do Nó em que o Pod está executando. + +No caso de tráfego de saída, isso significa que conexões de Pods para `Services` que são reescritos +para IPs externos ao cluster podem ou não estar sujeitos a políticas baseadas no campo `ipBlock`. + +## Políticas padrão + +Por padrão, se nenhuma política existir no namespace, então todo o tráfego de entrada e saída é +permitido de e para os pods nesse namespace. Os exemplos a seguir permitem a você mudar o +comportamento padrão nesse namespace. + +### Bloqueio padrão de todo tráfego de entrada + +Você pode criar uma política padrão de isolamento para um namespace criando um objeto `NetworkPolicy` +que seleciona todos os pods mas não permite o tráfego de entrada para esses pods. + +{{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}} + +Isso garante que mesmo pods que não são selecionados por nenhuma outra política de rede ainda +serão isolados. Essa política não muda o comportamento padrão de isolamento de tráfego de saída +nesse namespace. + +### Permitir por padrão todo tráfego de entrada + +Se você deseja permitir todo o tráfego de todos os pods em um namespace (mesmo que políticas que +sejam adicionadas faça com que alguns pods sejam tratados como "isolados"), você pode criar +uma política que permite explicitamente todo o tráfego naquele namespace. + +{{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}} + +### Bloqueio padrão de todo tráfego de saída + +Você pode criar uma política de isolamento de saída padrão para um namespace criando uma +política de redes que selecione todos os pods, mas não permita o tráfego de saída a partir +de nenhum desses pods. + +{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}} + +Isso garante que mesmo pods que não são selecionados por outra política de rede não seja permitido +tráfego de saída. Essa política não muda o comportamento padrão de tráfego de entrada. + +### Permitir por padrão todo tráfego de saída + +Caso você queira permitir todo o tráfego de todos os pods em um namespace (mesmo que políticas sejam +adicionadas e cause com que alguns pods sejam tratados como "isolados"), você pode criar uma +política explicita que permite todo o tráfego de saída no namespace. + +{{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}} + +### Bloqueio padrão de todo tráfego de entrada e saída + +Você pode criar uma política padrão em um namespace que previne todo o tráfego de entrada +E saída criando a política a seguir no namespace. + +{{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}} + +Isso garante que mesmo pods que não são selecionados por nenhuma outra política de redes não +possuam permissão de tráfego de entrada ou saída. + +## Selecionando uma faixa de portas + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +Ao escrever uma política de redes, você pode selecionar uma faixa de portas ao invés de uma +porta única, utilizando-se do campo `endPort` conforme a seguir: + +```yaml +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: multi-port-egress + namespace: default +spec: + podSelector: + matchLabels: + role: db + policyTypes: + - Egress + egress: + - to: + - ipBlock: + cidr: 10.0.0.0/24 + ports: + - protocol: TCP + port: 32000 + endPort: 32768 +``` + +A regra acima permite a qualquer Pod com a _label_ "role=db" no namespace `default` de se comunicar +com qualquer IP na faixa `10.0.0.0/24` através de protocolo TCP, desde que a porta de destino +esteja na faixa entre 32000 e 32768. + +As seguintes restrições aplicam-se ao se utilizar esse campo: + +* Por ser uma funcionalidade "alpha", ela é desativada por padrão. Para habilitar o campo `endPort` +no cluster, você (ou o seu administrador do cluster) deve habilitar o [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `NetworkPolicyEndPort` no `kube-apiserver` com a flag `--feature-gates=NetworkPolicyEndPort=true,...`. +* O valor de `endPort` deve ser igual ou maior ao valor do campo `port`. +* O campo `endPort` só pode ser definido se o campo `port` também for definido. +* Ambos os campos `port` e `endPort` devem ser números. + +{{< note >}} +Seu cluster deve utilizar um plugin {{< glossary_tooltip text="CNI" term_id="cni" >}} +que suporte o campo `endPort` na especificação da política de redes. +{{< /note >}} + +## Selecionando um Namespace pelo seu nome + +{{< feature-state state="beta" for_k8s_version="1.21" >}} + +A camada de gerenciamento do Kubernetes configura uma _label_ imutável `kubernetes.io/metadata.name` em +todos os namespaces, uma vez que o [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) esteja habilitado por padrão. +O valor dessa _label_ é o nome do namespace. + +Enquanto que um objeto `NetworkPolicy` não pode selecionar um namespace pelo seu nome através de +um campo específico, você pode utilizar essa _label_ padrão para selecionar um namespace pelo seu nome. + +## O que você não pode fazer com `NetworkPolicies` (ao menos por enquanto!) +Por enquanto no Kubernetes {{< skew latestVersion >}} as funcionalidades a seguir não existem +mas você pode conseguir implementar de forma alternativa utilizando componentes do Sistema Operacional +(como SELinux, OpenVSwitch, IPtables, etc) ou tecnologias da camada 7 OSI (Ingress controllers, implementações de service mesh) ou ainda _admission controllers_. +No caso do assunto "segurança de redes no Kubernetes" ser novo para você, vale notar que as +histórias de usuário a seguir ainda não podem ser implementadas: + +- Forçar o tráfego interno do cluster passar por um gateway comum (pode ser implementado via service mesh ou outros proxies) +- Qualquer coisa relacionada a TLS/mTLS (use um service mesh ou ingress controller para isso) +- Políticas específicas a nível do nó kubernetes (você pode utilizar as notações de IP CIDR para isso, mas não pode selecionar nós Kubernetes por suas identidades) +- Selecionar `Services` pelo seu nome (você pode, contudo, selecionar pods e namespaces por seus {{< glossary_tooltip text="labels" term_id="label" >}} o que torna-se uma solução de contorno viável). +- Criação ou gerenciamento +- Políticas padrão que são aplicadas a todos os namespaces e pods (existem alguns plugins externos do Kubernetes e projetos que podem fazer isso, e a comunidade está trabalhando nessa especificação). +- Ferramental de testes para validação de políticas de redes. +- Possibilidade de logar eventos de segurança de redes (conexões bloqueadas, aceitas). Existem plugins CNI que conseguem fazer isso à parte. +- Possibilidade de explicitamente negar políticas de rede (o modelo das `NetworkPolicies` são "negar por padrão e conforme a necessidade, deve-se adicionar regras que permitam o tráfego). +- Bloquear o tráfego que venha da interface de loopback/localhost ou que venham do nó em que o Pod se encontre. + +## {{% heading "whatsnext" %}} + + +- Veja o tutorial [Declarando políticas de redes](/docs/tasks/administer-cluster/declare-network-policy/) para mais exemplos. +- Veja mais [cenários comuns e exemplos](https://github.com/ahmetb/kubernetes-network-policy-recipes) de políticas de redes. diff --git a/content/pt-br/examples/service/networking/network-policy-allow-all-egress.yaml b/content/pt-br/examples/service/networking/network-policy-allow-all-egress.yaml new file mode 100644 index 0000000000..42b2a2a296 --- /dev/null +++ b/content/pt-br/examples/service/networking/network-policy-allow-all-egress.yaml @@ -0,0 +1,11 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: allow-all-egress +spec: + podSelector: {} + egress: + - {} + policyTypes: + - Egress diff --git a/content/pt-br/examples/service/networking/network-policy-allow-all-ingress.yaml b/content/pt-br/examples/service/networking/network-policy-allow-all-ingress.yaml new file mode 100644 index 0000000000..462912dae4 --- /dev/null +++ b/content/pt-br/examples/service/networking/network-policy-allow-all-ingress.yaml @@ -0,0 +1,11 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: allow-all-ingress +spec: + podSelector: {} + ingress: + - {} + policyTypes: + - Ingress diff --git a/content/pt-br/examples/service/networking/network-policy-default-deny-all.yaml b/content/pt-br/examples/service/networking/network-policy-default-deny-all.yaml new file mode 100644 index 0000000000..5c0086bd71 --- /dev/null +++ b/content/pt-br/examples/service/networking/network-policy-default-deny-all.yaml @@ -0,0 +1,10 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: default-deny-all +spec: + podSelector: {} + policyTypes: + - Ingress + - Egress diff --git a/content/pt-br/examples/service/networking/network-policy-default-deny-egress.yaml b/content/pt-br/examples/service/networking/network-policy-default-deny-egress.yaml new file mode 100644 index 0000000000..a4659e1417 --- /dev/null +++ b/content/pt-br/examples/service/networking/network-policy-default-deny-egress.yaml @@ -0,0 +1,9 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: default-deny-egress +spec: + podSelector: {} + policyTypes: + - Egress diff --git a/content/pt-br/examples/service/networking/network-policy-default-deny-ingress.yaml b/content/pt-br/examples/service/networking/network-policy-default-deny-ingress.yaml new file mode 100644 index 0000000000..e823802487 --- /dev/null +++ b/content/pt-br/examples/service/networking/network-policy-default-deny-ingress.yaml @@ -0,0 +1,9 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: default-deny-ingress +spec: + podSelector: {} + policyTypes: + - Ingress