{"id":32641,"date":"2019-10-31T21:48:11","date_gmt":"2019-10-31T18:48:11","guid":{"rendered":"https:\/\/prohoster.info\/blog\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti\/"},"modified":"2019-10-31T21:48:11","modified_gmt":"2019-10-31T18:48:11","slug":"vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti","title":{"rendered":"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p><img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a\" src=\"\/wp-content\/uploads\/2019\/04\/6972a1e1385463b1fcc723c09036a565.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i><b>Nota do tradutor.<\/b>: O autor do artigo \u2014 Reuven Harrison \u2014 tem mais de 20 anos de experi\u00eancia em desenvolvimento de software e, atualmente, \u00e9 diretor t\u00e9cnico e cofundador da Tufin, que cria solu\u00e7\u00f5es para gerenciamento de pol\u00edticas de seguran\u00e7a. Ao considerar as pol\u00edticas de rede do Kubernetes como uma ferramenta poderosa para segmenta\u00e7\u00e3o de rede em clustes, ele tamb\u00e9m acredita que n\u00e3o s\u00e3o t\u00e3o f\u00e1ceis de aplicar na pr\u00e1tica. Este material (bastante extenso) destina-se a aumentar a conscientiza\u00e7\u00e3o dos profissionais sobre o assunto e ajud\u00e1-los na cria\u00e7\u00e3o das configura\u00e7\u00f5es necess\u00e1rias.<\/i><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<p>Hoje, muitas empresas est\u00e3o cada vez mais optando pelo Kubernetes para executar suas aplica\u00e7\u00f5es. O interesse por este software \u00e9 t\u00e3o grande que alguns o chamam de \"novo sistema operacional para data centers\". Gradualmente, o Kubernetes (ou k8s) come\u00e7a a ser visto como uma parte cr\u00edtica do neg\u00f3cio, que requer a organiza\u00e7\u00e3o de processos de neg\u00f3cios maduros, incluindo a garantia de seguran\u00e7a de rede.<\/p>\n<p>Para os profissionais de seguran\u00e7a que est\u00e3o perplexos com o trabalho no Kubernetes, uma verdadeira revela\u00e7\u00e3o pode ser a pol\u00edtica padr\u00e3o dessa plataforma: permitir tudo.<\/p>\n<p>Este guia ajudar\u00e1 a entender a estrutura interna das pol\u00edticas de rede; compreender\u00e1 como elas diferem das regras para firewalls comuns. Tamb\u00e9m ser\u00e3o discutidas algumas armadilhas e fornecidas recomenda\u00e7\u00f5es que ajudar\u00e3o a proteger as aplica\u00e7\u00f5es no Kubernetes.<\/p>\n<h2>Pol\u00edticas de Rede do Kubernetes<\/h2>\n<p>\nO mecanismo de pol\u00edticas de rede do Kubernetes permite gerenciar a intera\u00e7\u00e3o das aplica\u00e7\u00f5es implantadas na plataforma em n\u00edvel de rede (o terceiro na modelo OSI). As pol\u00edticas de rede carecem de algumas funcionalidades avan\u00e7adas dos firewalls modernos, como controle no n\u00edvel 7 do OSI e detec\u00e7\u00e3o de amea\u00e7as, no entanto, elas proporcionam um n\u00edvel b\u00e1sico de seguran\u00e7a de rede, que serve como um bom ponto de partida.<\/p>\n<h2>As pol\u00edticas de rede controlam as comunica\u00e7\u00f5es entre os pods<\/h2>\n<p>\nAs cargas de trabalho no Kubernetes s\u00e3o distribu\u00eddas entre pods, que consistem em um ou mais cont\u00eaineres implantados em conjunto. O Kubernetes atribui a cada pod um endere\u00e7o IP acess\u00edvel a partir de outros pods. As pol\u00edticas de rede do Kubernetes definem os direitos de acesso para grupos de pods, da mesma forma que os grupos de seguran\u00e7a na nuvem s\u00e3o usados para gerenciar o acesso \u00e0s inst\u00e2ncias de m\u00e1quinas virtuais.<\/p>\n<h2>Defini\u00e7\u00e3o de pol\u00edticas de rede<\/h2>\n<p>\nAssim como outros recursos do Kubernetes, as pol\u00edticas de rede s\u00e3o definidas na linguagem YAML. No exemplo abaixo, o aplicativo <code>balance<\/code> obt\u00e9m acesso a <code>postgres<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.postgres\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: postgres\n  ingress:\n  - from:\n    - podSelector:\n        matchLabels:\n          app: balance\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a\" src=\"\/wp-content\/uploads\/2019\/04\/ff5857af2641e62558b035bab9c413dc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>(<b>Nota do tradutor.<\/b>: esta captura de tela, assim como todas as seguintes semelhantes, foi criada n\u00e3o com ferramentas nativas do Kubernetes, mas com a ferramenta Tufin Orca, desenvolvida pela empresa do autor do artigo original, mencionada no final do material.)<\/i><\/p>\n<p>Para definir sua pr\u00f3pria pol\u00edtica de rede, voc\u00ea precisar\u00e1 de conhecimentos b\u00e1sicos de YAML. Esta linguagem \u00e9 baseada em recuos (definidos por espa\u00e7os, e n\u00e3o por tabula\u00e7\u00f5es). Um elemento com recuo pertence ao elemento mais pr\u00f3ximo acima com recuo. Um novo item de lista come\u00e7a com um h\u00edfen; todos os outros itens t\u00eam a forma <i>chave-valor<\/i>.<\/p>\n<p>Ap\u00f3s descrever a pol\u00edtica em YAML, use <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/reference\/kubectl\/kubectl\/\">kubectl<\/a><\/noindex>, para cri\u00e1-la no cluster:<\/p>\n<pre><code class=\"bash\">kubectl create -f policy.yaml<\/code><\/pre>\n<p><\/p>\n<h2>Especifica\u00e7\u00e3o da pol\u00edtica de rede<\/h2>\n<p>\nA especifica\u00e7\u00e3o da pol\u00edtica de rede do Kubernetes consiste em quatro elementos:<\/p>\n<ol>\n<li> <code>podSelector<\/code>: define os pods afetados por esta pol\u00edtica (alvos) \u2014 obrigat\u00f3rio;<\/li>\n<li> <code>policyTypes<\/code>: indica quais tipos de pol\u00edticas est\u00e3o inclu\u00eddos nela: ingress e\/ou egress \u2014 opcional, mas recomendo que seja explicitamente descrito em todos os casos;<\/li>\n<li> <code>ingress<\/code>: define o tr\u00e1fego <b>de entrada<\/b> o tr\u00e1fego para os pods alvo \u2014 opcional;<\/li>\n<li> <code>egress<\/code>: define o tr\u00e1fego <b>tr\u00e1fego<\/b> o tr\u00e1fego dos pods alvo \u2014 opcional.<\/li>\n<\/ol>\n<p>\nO exemplo, retirado do site do Kubernetes (substitu\u00ed <code>role<\/code> para <code>app<\/code>), mostra como todos os quatro elementos s\u00e3o utilizados:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: test-network-policy\n  namespace: default\nspec:\n  podSelector:    # &lt;&lt;&lt;&lt;\n    matchLabels:\n      app: db\n  policyTypes:    # &lt;&lt;&lt;&lt;\n  - Ingress\n  - Egress\n  ingress:        # &lt;&lt;&lt;&lt;\n  - from:\n    - ipBlock:\n        cidr: 172.17.0.0\/16\n        except:\n        - 172.17.1.0\/24\n    - namespaceSelector:\n        matchLabels:\n          project: myproject\n    - podSelector:\n        matchLabels:\n          role: frontend\n    ports:\n    - protocol: TCP\n      port: 6379\n  egress:         # &lt;&lt;&lt;&lt;\n  - to:\n    - ipBlock:\n        cidr: 10.0.0.0\/24\n    ports:\n    - protocol: TCP\n      port: 5978<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a\" src=\"\/wp-content\/uploads\/2019\/04\/f01e748410564756d6272095093e52e2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a\" src=\"\/wp-content\/uploads\/2019\/04\/997282073ee6b5c4d6b7af45cdc11295.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nObserve que n\u00e3o \u00e9 necess\u00e1rio incluir todos os quatro elementos. Apenas <code>podSelector<\/code>os demais par\u00e2metros podem ser usados \u00e0 vontade.<\/p>\n<p>Se voc\u00ea omitir <code>policyTypes<\/code>, a pol\u00edtica ser\u00e1 interpretada como:<\/p>\n<ul>\n<li> Por padr\u00e3o, presume-se que ela define a parte de ingress. Se n\u00e3o houver indica\u00e7\u00f5es expl\u00edcitas a esse respeito na pol\u00edtica, o sistema considerar\u00e1 que todo o tr\u00e1fego est\u00e1 proibido.<\/li>\n<li> O comportamento na parte de egress ser\u00e1 determinado pela presen\u00e7a ou aus\u00eancia do par\u00e2metro egress correspondente.<\/li>\n<\/ul>\n<p>\nPara evitar erros, recomendo <b>sempre especificar de forma expl\u00edcita. <code>policyTypes<\/code><\/b>.<\/p>\n<p>De acordo com a l\u00f3gica acima, caso os par\u00e2metros <code>ingress<\/code> e\/ou <code>egress<\/code> sejam omitidos, a pol\u00edtica proibir\u00e1 todo o tr\u00e1fego (veja \"Regra de limpeza\" abaixo).<\/p>\n<h2>A pol\u00edtica padr\u00e3o \u00e9 permitir<\/h2>\n<p>\nSe as pol\u00edticas n\u00e3o forem definidas, o Kubernetes, por padr\u00e3o, permite todo o tr\u00e1fego. Todos os pods podem se comunicar livremente entre si. Do ponto de vista de seguran\u00e7a, isso pode parecer il\u00f3gico, mas lembre-se de que o Kubernetes foi criado por desenvolvedores com o objetivo de facilitar a intera\u00e7\u00e3o entre aplicativos. As pol\u00edticas de rede foram adicionadas posteriormente.<\/p>\n<h2>Namespaces<\/h2>\n<p>\nNamespaces (Espa\u00e7os de Nomes) s\u00e3o um mecanismo de trabalho colaborativo do Kubernetes. Eles s\u00e3o destinados a isolar ambientes l\u00f3gicos uns dos outros, permitindo que a troca de dados entre namespaces seja, por padr\u00e3o, permitida.<\/p>\n<p>Como a maioria dos componentes do Kubernetes, as pol\u00edticas de rede habitam em um namespace espec\u00edfico. No bloco <code>metadata<\/code> \u00e9 poss\u00edvel especificar a qual espa\u00e7o pertence a pol\u00edtica:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: test-network-policy\n  namespace: my-namespace  # &lt;&lt;&lt;&lt;\nspec:\n...<\/code><\/pre>\n<p>\nSe o namespace nas metadados n\u00e3o estiver explicitamente especificado, o sistema usar\u00e1 o namespace indicado no kubectl (por padr\u00e3o <code>namespace=default<\/code>):<\/p>\n<pre><code class=\"bash\">kubectl apply -n my-namespace -f namespace.yaml<\/code><\/pre>\n<p>\nRecomendo <b>especificar o namespace de forma expl\u00edcita.<\/b>, a menos que voc\u00ea esteja escrevendo uma pol\u00edtica destinada a v\u00e1rios namespaces de uma s\u00f3 vez.<\/p>\n<p><b>Principal<\/b> elemento <code>podSelector<\/code> na pol\u00edtica, os pods ser\u00e3o selecionados do espa\u00e7o de nomes ao qual a pol\u00edtica pertence (ele n\u00e3o tem acesso aos pods de outro espa\u00e7o de nomes).<\/p>\n<p>Da mesma forma, os podSelectors <b>nos blocos ingress e egress<\/b> podem selecionar pods apenas do seu pr\u00f3prio namespace, a menos que voc\u00ea os combine usando <code>namespaceSelector<\/code> (sobre isso ser\u00e1 discutido na se\u00e7\u00e3o \"Filtrar por espa\u00e7os de nomes e pods\").<\/p>\n<h2>Regras de nomenclatura de pol\u00edticas<\/h2>\n<p>\nOs nomes das pol\u00edticas s\u00e3o \u00fanicos dentro de um \u00fanico namespace. N\u00e3o pode haver duas pol\u00edticas com o mesmo nome em um namespace, mas pode haver pol\u00edticas com nomes id\u00eanticos em namespaces diferentes. Isso \u00e9 conveniente quando voc\u00ea deseja reaplicar a mesma pol\u00edtica em v\u00e1rios namespaces.<\/p>\n<p>Uma das maneiras de nomear que eu particularmente gosto envolve combinar o nome do namespace com os pods-alvo. Por exemplo:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.postgres  # &lt;&lt;&lt;\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: postgres\n  ingress:\n  - from:\n    - podSelector:\n        matchLabels:\n          app: admin\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a\" src=\"\/wp-content\/uploads\/2019\/04\/18318c320d6e37eeb01c51f251550639.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>R\u00f3tulos<\/h2>\n<p>\nA objetos Kubernetes, como pods e namespaces, podem ser anexados r\u00f3tulos personalizados. R\u00f3tulos (<i>labels<\/i> \u2014 tags) s\u00e3o equivalentes a tags na nuvem. As pol\u00edticas de rede do Kubernetes usam r\u00f3tulos para selecionar <b>pods<\/b>, aos quais se aplicam:<\/p>\n<pre><code class=\"plaintext\">podSelector:\n  matchLabels:\n    role: db<\/code><\/pre>\n<p>\n\u2026 ou <b>namespaces<\/b>, aos quais s\u00e3o aplicados. Neste exemplo, todos os pods nos espa\u00e7os de nomes com os r\u00f3tulos correspondentes s\u00e3o selecionados:<\/p>\n<pre><code class=\"plaintext\">namespaceSelector:\n  matchLabels:\n    project: myproject<\/code><\/pre>\n<p>\nUma advert\u00eancia: ao usar <code>namespaceSelector<\/code> <b>verifique se os namespaces selecionados cont\u00eam o r\u00f3tulo necess\u00e1rio<\/b>. Lembre-se de que namespaces incorporados, como <code>padr\u00e3o<\/code> e <code>kube-system<\/code>, por padr\u00e3o, n\u00e3o cont\u00eam r\u00f3tulos.<\/p>\n<p>Para adicionar um r\u00f3tulo a um namespace, voc\u00ea pode fazer da seguinte forma:<\/p>\n<pre><code class=\"bash\">kubectl label namespace default namespace=default<\/code><\/pre>\n<p>\nNesse caso, o namespace na se\u00e7\u00e3o <code>metadata<\/code> deve referir-se ao nome real do namespace, e n\u00e3o ao r\u00f3tulo:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: test-network-policy\n  namespace: default   # &lt;&lt;&lt;\nspec:\n...<\/code><\/pre>\n<p><\/p>\n<h2>Fonte e destinat\u00e1rio<\/h2>\n<p>\nAs pol\u00edticas para firewalls consistem em regras com fontes e destinat\u00e1rios. As pol\u00edticas de rede do Kubernetes s\u00e3o definidas para o alvo \u2014 um conjunto de pods aos quais se aplicam, e em seguida estabelecem regras para tr\u00e1fego de entrada (ingress) e\/ou tr\u00e1fego de sa\u00edda (egress). Em nosso exemplo, o alvo da pol\u00edtica ser\u00e1 todos os pods no espa\u00e7o de nomes <code>padr\u00e3o<\/code> com r\u00f3tulo com a chave <code>app<\/code> e valor <code>db<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: test-network-policy\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: db   # &lt;&lt;&lt;\n  policyTypes:\n  - Ingress\n  - Egress\n  ingress:\n  - from:\n    - ipBlock:\n        cidr: 172.17.0.0\/16\n        except:\n        - 172.17.1.0\/24\n    - namespaceSelector:\n        matchLabels:\n          project: myproject\n    - podSelector:\n        matchLabels:\n          role: frontend\n    ports:\n    - protocol: TCP\n      port: 6379\n  egress:\n  - to:\n    - ipBlock:\n        cidr: 10.0.0.0\/24\n    ports:\n    - protocol: TCP\n      port: 5978<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a\" src=\"\/wp-content\/uploads\/2019\/04\/5fcb3f78e26ae1ed5635541ad69ef69f.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a\" src=\"\/wp-content\/uploads\/2019\/04\/c753f559ecc3ba54f8b55e29851428c4.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nSe\u00e7\u00e3o <code>ingress<\/code> nesta pol\u00edtica abre o tr\u00e1fego de entrada para os pods de destino. Em outras palavras, ingress atua como fonte, e o objetivo \u2014 como destinat\u00e1rio correspondente. Da mesma forma, egress \u00e9 o destinat\u00e1rio, e o objetivo \u2014 sua fonte.<\/p>\n<p><img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a\" src=\"\/wp-content\/uploads\/2019\/04\/a0d865de57a7620849074424770832cd.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<i>Isso \u00e9 equivalente a duas regras para o firewall: Ingress \u2192 Objetivo; Objetivo \u2192 Egress.<\/i><\/p>\n<h2>Egress e DNS (importante!)<\/h2>\n<p>\nAo restringir o tr\u00e1fego de sa\u00edda, <b>preste especial aten\u00e7\u00e3o ao DNS<\/b> \u2014 Kubernetes utiliza este servi\u00e7o para mapear servi\u00e7os a endere\u00e7os IP. Por exemplo, a seguinte pol\u00edtica n\u00e3o funcionar\u00e1, pois voc\u00ea n\u00e3o permitiu que a aplica\u00e7\u00e3o <code>balance<\/code> acessasse o DNS:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.balance\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: balance\n  egress:\n  - to:\n    - podSelector:\n        matchLabels:\n          app: postgres\n  policyTypes:\n  - Egress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a\" src=\"\/wp-content\/uploads\/2019\/04\/5857a44cc5e06de708f0d3b5b0f49628.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nCorrigi-la pode ser feito liberando o acesso ao servi\u00e7o DNS:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.balance\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: balance\n  egress:\n  - to:\n    - podSelector:\n        matchLabels:\n          app: postgres\n  - to:               # &lt;&lt;&lt;\n    ports:            # &lt;&lt;&lt;\n    - protocol: UDP   # &lt;&lt;&lt;\n      port: 53        # &lt;&lt;&lt;\n  policyTypes:\n  - Egress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a\" src=\"\/wp-content\/uploads\/2019\/04\/a396bb2ae94fca94c3b62aef2cb07552.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nO \u00faltimo elemento <code>para<\/code> \u2014 vazio, e portanto escolhe indiretamente <b>todos os pods em todos os espa\u00e7os de nomes<\/b>, permitindo <code>balance<\/code> enviar consultas DNS ao servi\u00e7o Kubernetes correspondente (geralmente executado no namespace <code>kube-system<\/code>).<\/p>\n<p>Essa abordagem funciona, no entanto, \u00e9 <b>excessivamente permissiva e insegura<\/b>, pois permite direcionar consultas DNS para fora do cluster.<\/p>\n<p>Melhor\u00e1-la pode ser feito em tr\u00eas etapas sequenciais.<\/p>\n<p>1. Permitir consultas DNS apenas <b>dentro<\/b> do cluster, adicionando <code>namespaceSelector<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.balance\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: balance\n  egress:\n  - to:\n    - podSelector:\n        matchLabels:\n          app: postgres\n  - to:\n    - namespaceSelector: {} # &lt;&lt;&lt;\n    ports:\n    - protocol: UDP\n      port: 53\n  policyTypes:\n  - Egress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a\" src=\"\/wp-content\/uploads\/2019\/04\/5920a043229676e0780d691d302c5ade.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n2. Permitir consultas DNS apenas no namespace <code>kube-system<\/code>.<\/p>\n<p>Para isso, \u00e9 necess\u00e1rio adicionar um r\u00f3tulo ao namespace <code>kube-system<\/code>: <code>kubectl label namespace kube-system namespace=kube-system<\/code> \u2014 e registr\u00e1-lo na pol\u00edtica com <code>namespaceSelector<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.balance\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: balance\n  egress:\n  - to:\n    - podSelector:\n        matchLabels:\n          app: postgres\n  - to:\n    - namespaceSelector:         # &lt;&lt;&lt;\n        matchLabels:             # &lt;&lt;&lt;\n          namespace: kube-system # &lt;&lt;&lt;\n    ports:\n    - protocol: UDP\n      port: 53\n  policyTypes:\n  - Egress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a\" src=\"\/wp-content\/uploads\/2019\/04\/2a1dd0975c58e6d277baffc7c3ac6e48.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n3. Os paran\u00f3icos podem ir ainda mais longe e restringir consultas DNS a um servi\u00e7o DNS espec\u00edfico em <code>kube-system<\/code>. Na se\u00e7\u00e3o \"Filtrar por espa\u00e7os de nomes e pods\" ser\u00e1 explicado como conseguir isso.<\/p>\n<p>Outra op\u00e7\u00e3o \u00e9 permitir DNS no n\u00edvel do namespace. Nesse caso, n\u00e3o ser\u00e1 necess\u00e1rio abrir para cada servi\u00e7o:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.dns\n  namespace: default\nspec:\n  podSelector: {} # &lt;&lt;&lt;\n  egress:\n  - to:\n    - namespaceSelector: {}\n    ports:\n    - protocol: UDP\n      port: 53\n  policyTypes:\n  - Egress<\/code><\/pre>\n<p>\nVazio <code>podSelector<\/code> seleciona todos os pods no namespace.<\/p>\n<p><img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a\" src=\"\/wp-content\/uploads\/2019\/04\/5d6b627b69da980477b3910fbf4de6c1.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>A primeira correspond\u00eancia e a ordem das regras<\/h2>\n<p>\nEm firewalls comuns, a a\u00e7\u00e3o (\"Permitir\" ou \"Negar\") em rela\u00e7\u00e3o a um pacote \u00e9 determinada pela primeira regra que ele satisfaz. <b>No Kubernetes, a ordem das pol\u00edticas n\u00e3o importa.<\/b><\/p>\n<p>Por padr\u00e3o, quando as pol\u00edticas n\u00e3o s\u00e3o definidas, as comunica\u00e7\u00f5es entre os pods s\u00e3o permitidas e eles podem trocar informa\u00e7\u00f5es livremente. Assim que voc\u00ea come\u00e7a a formular pol\u00edticas, cada pod afetado por pelo menos uma delas se torna isolado de acordo com a disjun\u00e7\u00e3o (l\u00f3gica OU) de todas as pol\u00edticas que o escolheram. Pods n\u00e3o afetados por nenhuma pol\u00edtica permanecem abertos.<\/p>\n<p>Esse comportamento pode ser alterado com uma regra de limpeza.<\/p>\n<h2>Regra de limpeza (\"Negar\")<\/h2>\n<p>\nAs pol\u00edticas de firewall normalmente negam qualquer tr\u00e1fego que n\u00e3o seja explicitamente permitido.<\/p>\n<p><b>No Kubernetes, n\u00e3o existe a a\u00e7\u00e3o \"negar\" (deny)<\/b>, no entanto, um efeito semelhante pode ser alcan\u00e7ado com uma pol\u00edtica comum (permitiva), selecionando um grupo vazio de pods-fonte (ingress):<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: deny-all\n  namespace: default\nspec:\n  podSelector: {}\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a\" src=\"\/wp-content\/uploads\/2019\/04\/8b3ced50ec5a1de70940d53f467966fe.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEsta pol\u00edtica seleciona todos os pods no espa\u00e7o de nomes e deixa o ingress indefinido, proibindo todo o tr\u00e1fego de entrada.<\/p>\n<p>De maneira semelhante, voc\u00ea pode restringir todo o tr\u00e1fego de sa\u00edda do namespace:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: deny-all-egress\n  namespace: default\nspec:\n  podSelector: {}\n  policyTypes:\n  - Egress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a\" src=\"\/wp-content\/uploads\/2019\/04\/be22e11efef0098f2665331c09d748f2.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nConsidere que <b>quaisquer pol\u00edticas adicionais que permitam tr\u00e1fego para os pods no espa\u00e7o de nomes ter\u00e3o prioridade sobre esta regra<\/b> (semelhante a adicionar uma regra de permiss\u00e3o antes de uma proibi\u00e7\u00e3o na configura\u00e7\u00e3o do firewall).<\/p>\n<h2>Permitir tudo (Any-Any-Any-Allow)<\/h2>\n<p>\nPara criar uma pol\u00edtica \"Permitir tudo\", \u00e9 necess\u00e1rio complementar a pol\u00edtica de proibi\u00e7\u00e3o acima com um elemento vazio <code>ingress<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: allow-all\n  namespace: default\nspec:\n  podSelector: {}\n  ingress: # &lt;&lt;&lt;\n  - {}     # &lt;&lt;&lt;\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a\" src=\"\/wp-content\/uploads\/2019\/04\/7322351493211388fe772b8dc270108d.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nIsso abre o acesso de <b>todos os pods em todos os espa\u00e7os de nomes (e todos os IPs) para qualquer pod no espa\u00e7o de nomes <code>padr\u00e3o<\/code><\/b>. Comportamento semelhante est\u00e1 habilitado por padr\u00e3o, portanto, geralmente n\u00e3o \u00e9 necess\u00e1rio defini-lo adicionalmente. No entanto, \u00e0s vezes pode ser necess\u00e1rio desativar temporariamente algumas permiss\u00f5es espec\u00edficas para diagnosticar um problema.<\/p>\n<p>A regra pode ser restringida e permitir acesso apenas a <b>um conjunto espec\u00edfico de pods<\/b> (<code>app:balance<\/code>) no namespace <code>padr\u00e3o<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: allow-all-to-balance\n  namespace: default\nspec:\n  podSelector:\n    matchLabels:\n      app: balance\n  ingress: \n  - {}\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a\" src=\"\/wp-content\/uploads\/2019\/04\/d8c9cb85003f489acec815d1c2b53497.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nA pol\u00edtica seguinte permite todo o tr\u00e1fego de entrada (ingress) e sa\u00edda (egress), incluindo acesso a qualquer IP fora do cluster:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: allow-all\nspec:\n  podSelector: {}\n  ingress:\n  - {}\n  egress:\n  - {}\n  policyTypes:\n  - Ingress\n  - Egress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a\" src=\"\/wp-content\/uploads\/2019\/04\/2477f18d3d228f80bc5169d9ec3be2fc.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a\" src=\"\/wp-content\/uploads\/2019\/04\/3502b892713cdac8850e812b2eff3ea3.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>A combina\u00e7\u00e3o de v\u00e1rias pol\u00edticas<\/h2>\n<p>\nAs pol\u00edticas s\u00e3o combinadas usando um operador l\u00f3gico OU em tr\u00eas n\u00edveis; as permiss\u00f5es de cada pod s\u00e3o determinadas pela disjun\u00e7\u00e3o de todas as pol\u00edticas que o afetam:<\/p>\n<p>1. Nos campos <code>Harvard University<\/code> e <code>para<\/code> podem ser definidos tr\u00eas tipos de elementos (todos combinados usando OU):<\/p>\n<ul>\n<li> <code>namespaceSelector<\/code> \u2014 seleciona o namespace inteiro;<\/li>\n<li> <code>podSelector<\/code> \u2014 seleciona pods;<\/li>\n<li> <code>ipBlock<\/code> \u2014 seleciona uma sub-rede.<\/li>\n<\/ul>\n<p>\nNesse caso, o n\u00famero de elementos (mesmo que iguais) nas subdivis\u00f5es <code>Harvard University<\/code>\/<code>para<\/code> n\u00e3o \u00e9 limitado. Todos eles ser\u00e3o combinados logicamente por OU.<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.postgres\n  namespace: default\nspec:\n  ingress:\n  - from:\n    - podSelector:\n        matchLabels:\n          app: indexer\n    - podSelector:\n        matchLabels:\n          app: admin\n  podSelector:\n    matchLabels:\n      app: postgres\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a\" src=\"\/wp-content\/uploads\/2019\/04\/717e745720f39260a8508fb2b2bb6f65.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n2. Dentro da pol\u00edtica, a se\u00e7\u00e3o <code>ingress<\/code> pode conter m\u00faltiplos elementos <code>Harvard University<\/code> (que s\u00e3o combinados com um OU l\u00f3gico). Da mesma forma, a se\u00e7\u00e3o <code>egress<\/code> pode incluir muitos elementos <code>para<\/code> (tamb\u00e9m combinados por disjun\u00e7\u00e3o):<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.postgres\n  namespace: default\nspec:\n  ingress:\n  - from:\n    - podSelector:\n        matchLabels:\n          app: indexer\n  - from:\n    - podSelector:\n        matchLabels:\n          app: admin\n  podSelector:\n    matchLabels:\n      app: postgres\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a\" src=\"\/wp-content\/uploads\/2019\/04\/b579e1f4b97acd92fb38cd6703aa1983.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n3. Diferentes pol\u00edticas tamb\u00e9m s\u00e3o combinadas com um OU l\u00f3gico<\/p>\n<p>Mas ao combin\u00e1-las, existe uma limita\u00e7\u00e3o \u00e0 qual <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/sainsburys-engineering\/considerations-with-k8s-networkpolicy-cee7eacf5469\">referiu<\/a><\/noindex> <noindex><a rel=\"nofollow\" href=\"https:\/\/medium.com\/@chriscooney\">Chris Cooney<\/a><\/noindex>: o Kubernetes pode combinar pol\u00edticas apenas com diferentes <code>policyTypes<\/code> (<code>Ingress<\/code> ou <code>Egress<\/code>). Pol\u00edticas que definem ingress (ou egress) ir\u00e3o sobrescrever umas \u00e0s outras.<\/p>\n<h2>V\u00ednculo entre namespaces<\/h2>\n<p>\nPor padr\u00e3o, a comunica\u00e7\u00e3o entre namespaces \u00e9 permitida. Isso pode ser alterado por meio de uma pol\u00edtica restritiva que limita o tr\u00e1fego de entrada e\/ou sa\u00edda para um namespace (veja \"Regra de limpeza\" acima).<\/p>\n<p>Ao bloquear o acesso a um namespace (veja \"Regra de limpeza\" acima), voc\u00ea pode fazer exce\u00e7\u00f5es \u00e0 pol\u00edtica restritiva, permitindo conex\u00f5es de um namespace espec\u00edfico atrav\u00e9s de <code>namespaceSelector<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: database.postgres\n  namespace: database\nspec:\n  podSelector:\n    matchLabels:\n      app: postgres\n  ingress:\n  - from:\n    - namespaceSelector: # &gt;&gt;&gt;\n        matchLabels:\n          namespace: default\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a\" src=\"\/wp-content\/uploads\/2019\/04\/5a3d2baed1ff9b813ef0651fe500ad8a.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nComo resultado, todos os pods no namespace <code>padr\u00e3o<\/code> ter\u00e3o acesso aos pods <code>postgres<\/code> no namespace <code>database<\/code>. Mas e se voc\u00ea quiser abrir acesso apenas a <code>postgres<\/code> apenas a pods espec\u00edficos no espa\u00e7o de nomes <code>padr\u00e3o<\/code>?<\/p>\n<h2>Filtro por espa\u00e7os de nomes e pods<\/h2>\n<p>\nKubernetes vers\u00e3o 1.11 e superior permite combinar operadores <code>namespaceSelector<\/code> e <code>podSelector<\/code> usando um E l\u00f3gico. Isso se parece com o seguinte:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: database.postgres\n  namespace: database\nspec:\n  podSelector:\n    matchLabels:\n      app: postgres\n  ingress:\n  - from:\n    - namespaceSelector:\n        matchLabels:\n          namespace: default\n      podSelector: # &gt;&gt;&gt;\n        matchLabels:\n          app: admin\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a\" src=\"\/wp-content\/uploads\/2019\/04\/e933e449d9f9c10505e45930d1477b2c.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nPor que isso \u00e9 interpretado como E em vez do esperado OU?<\/p>\n<p>Observe que <code>podSelector<\/code> n\u00e3o come\u00e7a com um h\u00edfen. No YAML, isso significa que <code>podSelector<\/code> e o que est\u00e1 antes dele <code>namespaceSelector<\/code> pertencem ao mesmo elemento da lista. Portanto, eles s\u00e3o combinados com um E.<\/p>\n<p>Adicionar um h\u00edfen antes de <code>podSelector<\/code> levar\u00e1 \u00e0 cria\u00e7\u00e3o de um novo item de lista que ser\u00e1 combinado com o anterior <code>namespaceSelector<\/code> usando a l\u00f3gica OU.<\/p>\n<p>Para selecionar pods com um r\u00f3tulo espec\u00edfico <b>em todos os namespaces<\/b>, digite vazio <code>namespaceSelector<\/code>:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: database.postgres\n  namespace: database\nspec:\n  podSelector:\n    matchLabels:\n      app: postgres\n  ingress:\n  - from:\n    - namespaceSelector: {}\n      podSelector:\n        matchLabels:\n          app: admin\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a\" src=\"\/wp-content\/uploads\/2019\/04\/e79e4a8067fa254f85fa8be105c3ad34.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>V\u00e1rios r\u00f3tulos s\u00e3o combinados com E<\/h2>\n<p>\nRegras de firewall com m\u00faltiplos objetos (hosts, redes, grupos) s\u00e3o combinadas usando a l\u00f3gica OU. A pr\u00f3xima regra ser\u00e1 aplicada se a origem do pacote coincidir com <code>Host_1<\/code> OU <code>Host_2<\/code>:<\/p>\n<pre><code class=\"plaintext\">| Fonte | Destino | Servi\u00e7o | A\u00e7\u00e3o |\n| ----------------------------------------|\n| Host_1 | Subnet_A    | HTTPS   | Permitir  |\n| Host_2 |             |         |        |\n| ----------------------------------------|<\/code><\/pre>\n<p>\nPor outro lado, no Kubernetes, diferentes r\u00f3tulos em <code>podSelector<\/code> ou <code>namespaceSelector<\/code> s\u00e3o combinados com a l\u00f3gica E. Por exemplo, a pr\u00f3xima regra selecionar\u00e1 os pods que possuem ambos os r\u00f3tulos, <code>role=db<\/code> eu posso usar <code>version=v2<\/code>:<\/p>\n<pre><code class=\"plaintext\">podSelector:\n  matchLabels:\n    role: db\n    version: v2<\/code><\/pre>\n<p>\nA mesma l\u00f3gica se aplica a todos os tipos de operadores: seletores de objetivos de pol\u00edticas, seletores de pods e seletores de espa\u00e7os de nomes.<\/p>\n<h2>Sub-redes e endere\u00e7os IP (IPBlocks)<\/h2>\n<p>\nPara segmenta\u00e7\u00e3o de rede, os firewalls usam VLANs, endere\u00e7os IP e sub-redes.<\/p>\n<p>No Kubernetes, os endere\u00e7os IP s\u00e3o atribu\u00eddos automaticamente aos pods e podem mudar com frequ\u00eancia, por isso, para selecionar pods e espa\u00e7os de nomes nas pol\u00edticas de rede, s\u00e3o usados r\u00f3tulos.<\/p>\n<p>Sub-redes (<code>ipBlocks<\/code>) s\u00e3o usados ao gerenciar conex\u00f5es externas (North-South) de entrada (ingress) ou de sa\u00edda (egress). Por exemplo, esta pol\u00edtica abre para todos os pods no espa\u00e7o de nomes <code>padr\u00e3o<\/code> acessam o servi\u00e7o DNS do Google:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: egress-dns\n  namespace: default\nspec:\n  podSelector: {}\n  policyTypes:\n  - Egress\n  egress:\n  - to:\n    - ipBlock:\n        cidr: 8.8.8.8\/32\n    ports:\n    - protocol: UDP\n      port: 53<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a\" src=\"\/wp-content\/uploads\/2019\/04\/42e1194e28331e667a094f19c88e0934.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nUm seletor de pods vazio neste exemplo significa 'selecionar todos os pods no espa\u00e7o de nomes'.<\/p>\n<p>Esta pol\u00edtica apenas permite acesso a 8.8.8.8; o acesso a qualquer outro IP \u00e9 negado. Basicamente, voc\u00ea bloqueou o acesso ao servi\u00e7o DNS interno do Kubernetes. Se voc\u00ea quiser abri-lo, especifique isso explicitamente.<\/p>\n<p>Normalmente <code>ipBlocks<\/code> e <code>podSelectors<\/code> s\u00e3o mutuamente exclusivos, pois os endere\u00e7os IP internos dos pods n\u00e3o s\u00e3o utilizados em <code>ipBlocks<\/code>. Ao especificar <b>endere\u00e7os IP internos dos pods<\/b>, voc\u00ea efetivamente permitir\u00e1 conex\u00f5es para\/de pods com esses endere\u00e7os. Na pr\u00e1tica, voc\u00ea n\u00e3o saber\u00e1 qual endere\u00e7o IP usar, por isso n\u00e3o deve ser aplicado para selecionar pods.<\/p>\n<p>Como um contraexemplo, a seguinte pol\u00edtica inclui todos os IPs e, portanto, permite acesso a todos os outros pods:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: egress-any\n  namespace: default\nspec:\n  podSelector: {}\n  policyTypes:\n  - Egress\n  egress:\n  - to:\n    - ipBlock:\n        cidr: 0.0.0.0\/0<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a\" src=\"\/wp-content\/uploads\/2019\/04\/d99dfdead1c96b071b1643cb5c572878.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nVoc\u00ea pode abrir o acesso apenas a IPs externos, excluindo os endere\u00e7os IP internos dos pods. Por exemplo, se a sub-rede do seu pod for 10.16.0.0\/14:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: egress-any\n  namespace: default\nspec:\n  podSelector: {}\n  policyTypes:\n  - Egress\n  egress:\n  - to:\n    - ipBlock:\n        cidr: 0.0.0.0\/0\n        except:\n        - 10.16.0.0\/14<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a\" src=\"\/wp-content\/uploads\/2019\/04\/b157cfe0f1cd4677cf0defd9fdfa8a13.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h2>Portas e protocolos<\/h2>\n<p>\nNormalmente, os pods escutam uma porta. Isso significa que voc\u00ea pode simplesmente n\u00e3o especificar os n\u00fameros das portas nas pol\u00edticas e deixar tudo como padr\u00e3o. No entanto, as pol\u00edticas devem ser o mais restritivas poss\u00edvel, portanto, em alguns casos, ainda \u00e9 poss\u00edvel especificar portas:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.postgres\n  namespace: default\nspec:\n  ingress:\n  - from:\n    - podSelector:\n        matchLabels:\n          app: indexer\n    - podSelector:\n        matchLabels:\n          app: admin\n    ports:             # &lt;&lt;&lt;\n      - port: 443      # &lt;&lt;&lt;\n        protocol: TCP  # &lt;&lt;&lt;\n      - port: 80       # &lt;&lt;&lt;\n        protocol: TCP  # &lt;&lt;&lt;\n  podSelector:\n    matchLabels:\n      app: postgres\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a\" src=\"\/wp-content\/uploads\/2019\/04\/4c778cd46c54e2ae0f4527ffa9e1e740.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nObserve que o seletor <code>ports<\/code> se aplica a todos os elementos no bloco <code>para<\/code> ou <code>Harvard University<\/code>, no qual est\u00e1 contido. Para especificar portas diferentes para diferentes conjuntos de elementos, divida <code>ingress<\/code> ou <code>egress<\/code> em v\u00e1rios subblocos com <code>para<\/code> ou <code>Harvard University<\/code> e, em cada um, escreva suas pr\u00f3prias portas:<\/p>\n<pre><code class=\"plaintext\">apiVersion: networking.k8s.io\/v1\nkind: NetworkPolicy\nmetadata:\n  name: default.postgres\n  namespace: default\nspec:\n  ingress:\n  - from:\n    - podSelector:\n        matchLabels:\n          app: indexer\n    ports:             # &lt;&lt;&lt;\n     - port: 443       # &lt;&lt;&lt;\n       protocol: TCP   # &lt;&lt;&lt;\n  - from:\n    - podSelector:\n        matchLabels:\n          app: admin\n    ports:             # &lt;&lt;&lt;\n     - port: 80        # &lt;&lt;&lt;\n       protocol: TCP   # &lt;&lt;&lt;\n  podSelector:\n    matchLabels:\n      app: postgres\n  policyTypes:\n  - Ingress<\/code><\/pre>\n<p>\n<img decoding=\"async\" alt=\"Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para especialistas em seguran\u00e7a\" src=\"\/wp-content\/uploads\/2019\/04\/b9ac1d8af491e992cac0be184005a278.png\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nFuncionamento das portas por padr\u00e3o:<\/p>\n<ul>\n<li> Se voc\u00ea omitir completamente a defini\u00e7\u00e3o de portas (<code>ports<\/code>), isso significa todos os protocolos e todas as portas;<\/li>\n<li> Se voc\u00ea omitir a defini\u00e7\u00e3o do protocolo (<code>protocol<\/code>), isso significa TCP;<\/li>\n<li> Se voc\u00ea omitir a defini\u00e7\u00e3o da porta (<code>port<\/code>), isso significa todas as portas.<\/li>\n<\/ul>\n<p>\nMelhor pr\u00e1tica: n\u00e3o confie nos valores padr\u00e3o, especifique o que voc\u00ea precisa explicitamente.<\/p>\n<p>Observe que voc\u00ea deve usar as portas dos pods, e n\u00e3o dos servi\u00e7os (mais detalhes no pr\u00f3ximo par\u00e1grafo).<\/p>\n<h2>As pol\u00edticas s\u00e3o definidas para pods ou servi\u00e7os?<\/h2>\n<p>\nGeralmente, os pods no Kubernetes se comunicam entre si atrav\u00e9s de um servi\u00e7o \u2014 um balanceador de carga virtual que redireciona o tr\u00e1fego para os pods que implementam o servi\u00e7o. Pode-se pensar que as pol\u00edticas de rede controlam o acesso aos servi\u00e7os, mas isso n\u00e3o \u00e9 verdade. <b>As pol\u00edticas de rede do Kubernetes funcionam com as portas dos pods, e n\u00e3o com as dos servi\u00e7os.<\/b><\/p>\n<p>Por exemplo, se um servi\u00e7o escuta na porta 80, mas redireciona o tr\u00e1fego para a porta 8080 de seus pods, a pol\u00edtica de rede deve especificar exatamente a 8080.<\/p>\n<p>Esse mecanismo deve ser considerado sub\u00f3timo: ao alterar a configura\u00e7\u00e3o interna do servi\u00e7o (cujas portas os pods escutam), ser\u00e1 necess\u00e1rio atualizar as pol\u00edticas de rede.<\/p>\n<p>Uma nova abordagem arquitetural usando Service Mesh <i>(por exemplo, veja sobre Istio abaixo \u2014 nota do tradutor)<\/i> resolve essa quest\u00e3o.<\/p>\n<h2>\u00c9 necess\u00e1rio definir tanto o Ingress quanto o Egress?<\/h2>\n<p>\nA resposta curta \u00e9 sim; para que o pod A possa se conectar ao pod B, \u00e9 necess\u00e1rio permitir que ele estabele\u00e7a uma conex\u00e3o de sa\u00edda (para isso, \u00e9 preciso configurar a pol\u00edtica de egress), e o pod B deve ter a capacidade de aceitar uma conex\u00e3o de entrada (para isso, logicamente, \u00e9 necess\u00e1ria uma pol\u00edtica de ingress).<\/p>\n<p>No entanto, na pr\u00e1tica, pode-se confiar na pol\u00edtica padr\u00e3o, que permite conex\u00f5es em uma ou ambas as dire\u00e7\u00f5es.<\/p>\n<p>Se um determinado pod<b>fonte<\/b> for selecionado por uma ou mais <b>egress<\/b>-pol\u00edticas, as restri\u00e7\u00f5es aplic\u00e1veis a ele ser\u00e3o determinadas por sua disjun\u00e7\u00e3o. Nesse caso, ser\u00e1 necess\u00e1rio permitir explicitamente a conex\u00e3o com o pod<b>-destinat\u00e1rio<\/b>. Se o pod n\u00e3o for selecionado por nenhuma pol\u00edtica, seu tr\u00e1fego de sa\u00edda (egress) \u00e9 permitido por padr\u00e3o.<\/p>\n<p>De maneira semelhante, o destino do pod-<b>-destinat\u00e1rio<\/b>, selecionado por uma ou mais <b>ingress<\/b>-pol\u00edticas ser\u00e1 determinado pela sua disjun\u00e7\u00e3o. Nesse caso, \u00e9 necess\u00e1rio permitir explicitamente que ele receba tr\u00e1fego do pod de origem. Se o pod n\u00e3o for selecionado por alguma pol\u00edtica, todo o tr\u00e1fego de entrada (ingress) para ele \u00e9 permitido por padr\u00e3o.<\/p>\n<p>Veja a se\u00e7\u00e3o \"Stateful ou Stateless\" abaixo.<\/p>\n<h2>Logs<\/h2>\n<p>\nAs pol\u00edticas de rede do Kubernetes n\u00e3o conseguem registrar o tr\u00e1fego. Isso dificulta a determina\u00e7\u00e3o se a pol\u00edtica est\u00e1 funcionando corretamente e complica bastante a an\u00e1lise na \u00e1rea de seguran\u00e7a.<\/p>\n<h2>Controle do tr\u00e1fego para servi\u00e7os externos<\/h2>\n<p>\nAs pol\u00edticas de rede do Kubernetes n\u00e3o permitem especificar um nome de dom\u00ednio completo (DNS) nas se\u00e7\u00f5es de egress. Este fato causa consider\u00e1vel inconveniente ao tentar restringir o tr\u00e1fego para destinos externos sem um endere\u00e7o IP fixo (como aws.com).<\/p>\n<h2>Verifica\u00e7\u00e3o de Pol\u00edtica<\/h2>\n<p>\nOs firewalls ir\u00e3o alert\u00e1-lo ou at\u00e9 mesmo se recusar\u00e3o a aceitar uma pol\u00edtica incorreta. O Kubernetes tamb\u00e9m realiza alguma verifica\u00e7\u00e3o. Ao definir uma pol\u00edtica de rede atrav\u00e9s do kubectl, o Kubernetes pode afirmar que est\u00e1 incorreta e se recusar a aceit\u00e1-la. Em outros casos, o Kubernetes aceitar\u00e1 a pol\u00edtica e a completar\u00e1 com detalhes faltantes. Eles podem ser visualizados com o comando:<\/p>\n<pre><code class=\"plaintext\">kubernetes get networkpolicy  -o yaml<\/code><\/pre>\n<p>\nTenha em mente que o sistema de verifica\u00e7\u00e3o do Kubernetes n\u00e3o \u00e9 infal\u00edvel e pode deixar passar alguns tipos de erros.<\/p>\n<h2>Execu\u00e7\u00e3o<\/h2>\n<p>\nO Kubernetes n\u00e3o implementa as pol\u00edticas de rede por conta pr\u00f3pria, mas \u00e9 apenas um gateway de API, transferindo o trabalho de controle para o sistema subjacente chamado Container Networking Interface (CNI). Definir pol\u00edticas em um cluster Kubernetes sem atribuir um CNI apropriado \u00e9 semelhante a criar pol\u00edticas em um servidor de firewall sem instal\u00e1-las posteriormente nos firewalls. Voc\u00ea deve garantir que haja um CNI adequado ou, em ambientes Kubernetes hospedados na nuvem, <i>(a lista de provedores pode ser consultada <noindex>aqui<\/noindex> \u2014 nota do tradutor)<\/i>, acionar as pol\u00edticas de rede que estabelecer\u00e3o o CNI por voc\u00ea.<\/p>\n<p>Observe que o Kubernetes n\u00e3o o alertar\u00e1 se voc\u00ea definir uma pol\u00edtica de rede sem um CNI auxiliar apropriado.<\/p>\n<h3>Stateful ou Stateless?<\/h3>\n<p>\nTodos os CNIs do Kubernetes com os quais me deparei armazenam estados (por exemplo, o Calico usa o Linux conntrack). Isso permite que um pod receba respostas de uma conex\u00e3o TCP iniciada por ele, sem a necessidade de reestabelec\u00ea-la. No entanto, n\u00e3o estou ciente de um padr\u00e3o do Kubernetes que garanta a manuten\u00e7\u00e3o de estado.<\/p>\n<h2>Gerenciamento avan\u00e7ado de pol\u00edticas de seguran\u00e7a<\/h2>\n<p>\nAqui est\u00e3o algumas maneiras de aumentar a efic\u00e1cia na execu\u00e7\u00e3o de pol\u00edticas de seguran\u00e7a no Kubernetes:<\/p>\n<ol>\n<li> O padr\u00e3o arquitet\u00f4nico Service Mesh usa cont\u00eaineres sidecar para garantir telemetria detalhada e controle do tr\u00e1fego em n\u00edvel de servi\u00e7o. Como exemplo, podemos citar <noindex><a rel=\"nofollow\" href=\"https:\/\/istio.io\/\">Istio<\/a><\/noindex>.<\/li>\n<li> Alguns fornecedores de CNI aprimoraram suas ferramentas para que fossem al\u00e9m das pol\u00edticas de rede do Kubernetes.<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/www.tufin.com\/products\/tufin-orca\">Tufin Orca<\/a><\/noindex> oferece visibilidade e automa\u00e7\u00e3o das pol\u00edticas de rede do Kubernetes.<\/li>\n<\/ol>\n<p>\nO pacote Tufin Orca gerencia as pol\u00edticas de rede do Kubernetes (e serve como fonte das capturas de tela apresentadas acima).<\/p>\n<h2>Informa\u00e7\u00f5es adicionais<\/h2>\n<p><\/p>\n<ul>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/ahmetb\/kubernetes-network-policy-recipes\">Exemplos de pol\u00edticas de rede, elaborados por Ahmet Alp Balkan do GKE<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/kubernetes.io\/docs\/concepts\/services-networking\/network-policies\/\">Documenta\u00e7\u00e3o do site oficial do Kubernetes<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/sookocheff.com\/post\/kubernetes\/understanding-kubernetes-networking-model\/\">Guia sobre o modelo de rede do Kubernetes<\/a><\/noindex>;<\/li>\n<li> <noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/Tufin\/test-network-policies\">Script para verificar pol\u00edticas de rede<\/a><\/noindex>.<\/li>\n<\/ul>\n<p><\/p>\n<h2>Conclus\u00e3o<\/h2>\n<p>\nAs pol\u00edticas de rede do Kubernetes oferecem um bom conjunto de ferramentas para segmentar clusters, mas s\u00e3o intuitivamente confusas e apresentam muitas sutilezas. Acredito que devido a essa complexidade, as pol\u00edticas de muitos clusters existentes cont\u00eam erros. Poss\u00edveis solu\u00e7\u00f5es para esse problema incluem a automa\u00e7\u00e3o das defini\u00e7\u00f5es de pol\u00edticas ou a aplica\u00e7\u00e3o de outras ferramentas de segmenta\u00e7\u00e3o.<\/p>\n<p>Espero que este guia ajude a esclarecer algumas quest\u00f5es e resolver problemas que voc\u00ea possa encontrar.<\/p>\n<h2>P.S. do tradutor<\/h2>\n<p>\nConfira tamb\u00e9m em nosso blog:<\/p>\n<ul>\n<li> \u00abDe Volta aos Microservi\u00e7os com Istio\u00bb: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/438426\/\">parte 1 (introdu\u00e7\u00e3o aos principais recursos)<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/440378\/\">parte 2 (roteamento, gerenciamento de tr\u00e1fego)<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/443668\/\">parte 3 (seguran\u00e7a)<\/a><\/noindex>;<\/li>\n<li> \u00abGuia ilustrado para a estrutura da rede no Kubernetes\u00bb: <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/346304\/\">partes 1 e 2 (modelo de rede, redes sobrepostas)<\/a><\/noindex>, <noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/433382\/\">parte 3 (servi\u00e7os e gerenciamento de tr\u00e1fego)<\/a><\/noindex>;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/440504\/\">Docker e Kubernetes em ambientes exigentes em termos de seguran\u00e7a<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/436300\/\">9 melhores pr\u00e1ticas para garantir a seguran\u00e7a no Kubernetes<\/a><\/noindex>\u00bb;<\/li>\n<li> \u00ab<noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/417905\/\">11 maneiras de (n\u00e3o) se tornar uma v\u00edtima de hacking no Kubernetes<\/a><\/noindex>\u00bb.<\/li>\n<\/ul>\n<p>Fonte: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/flant\/blog\/443190\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u043c. \u043f\u0435\u0440\u0435\u0432.: \u0410\u0432\u0442\u043e\u0440 \u0441\u0442\u0430\u0442\u044c\u0438 \u2014 Reuven Harrison \u2014 \u0438\u043c\u0435\u0435\u0442 \u0431\u043e\u043b\u0435\u0435 20 \u043b\u0435\u0442 \u043e\u043f\u044b\u0442\u0430 \u0432 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0435 \u043f\u0440\u043e\u0433\u0440\u0430\u043c\u043c\u043d\u043e\u0433\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0435\u043d\u0438\u044f, \u0430 \u043d\u0430 \u0441\u0435\u0433\u043e\u0434\u043d\u044f\u0448\u043d\u0438\u0439 \u0434\u0435\u043d\u044c \u044f\u0432\u043b\u044f\u0435\u0442\u0441\u044f \u0442\u0435\u0445\u043d\u0438\u0447\u0435\u0441\u043a\u0438\u043c \u0434\u0438\u0440\u0435\u043a\u0442\u043e\u0440\u043e\u043c \u0438 \u0441\u043e\u0443\u0447\u0440\u0435\u0434\u0438\u0442\u0435\u043b\u0435\u043c \u043a\u043e\u043c\u043f\u0430\u043d\u0438\u0438 Tufin, \u0441\u043e\u0437\u0434\u0430\u044e\u0449\u0435\u0439 \u0440\u0435\u0448\u0435\u043d\u0438\u044f \u0434\u043b\u044f \u0443\u043f\u0440\u0430\u0432\u043b\u0435\u043d\u0438\u044f \u043f\u043e\u043b\u0438\u0442\u0438\u043a\u0430\u043c\u0438 \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438. \u0420\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u044f \u0441\u0435\u0442\u0435\u0432\u044b\u0435 \u043f\u043e\u043b\u0438\u0442\u0438\u043a\u0438 Kubernetes \u043a\u0430\u043a \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u043c\u043e\u0449\u043d\u043e\u0435 \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u043e \u0434\u043b\u044f \u0441\u0435\u0433\u043c\u0435\u043d\u0442\u0430\u0446\u0438\u0438 \u0441\u0435\u0442\u0438 \u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0435, \u043e\u043d \u0432 \u0442\u043e \u0436\u0435 \u0432\u0440\u0435\u043c\u044f \u0441\u0447\u0438\u0442\u0430\u0435\u0442, \u0447\u0442\u043e \u043e\u043d\u0438 [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":24432,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-32641","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.3 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"pt_PT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 \u0441\u0435\u0442\u0435\u0432\u044b\u0435 \u043f\u043e\u043b\u0438\u0442\u0438\u043a\u0438 Kubernetes \u0434\u043b\u044f \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u043e\u0432 \u043f\u043e \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u043c.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:48:11+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2019-10-31T18:48:11+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Introdu\u00e7\u00e3o \u00e0s pol\u00edticas de rede do Kubernetes para profissionais de seguran\u00e7a | ProHoster","description":"Nota.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 \u0441\u0435\u0442\u0435\u0432\u044b\u0435 \u043f\u043e\u043b\u0438\u0442\u0438\u043a\u0438 Kubernetes \u0434\u043b\u044f \u0441\u043f\u0435\u0446\u0438\u0430\u043b\u0438\u0441\u0442\u043e\u0432 \u043f\u043e \u0431\u0435\u0437\u043e\u043f\u0430\u0441\u043d\u043e\u0441\u0442\u0438 | ProHoster","og:description":"\u041f\u0440\u0438\u043c.","og:url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/vvedenie-v-setevye-politiki-kubernetes-dlya-spetsialistov-po-bezopasnosti","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:48:11+00:00","article:modified_time":"2019-10-31T18:48:11+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"32641","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 11:53:20","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:55:23","updated":"2026-01-21 11:53:20","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/32641","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=32641"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/32641\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/24432"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=32641"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=32641"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=32641"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}