Introducción a las políticas de red de Kubernetes para profesionales de la seguridad



Nota perev. : El autor del art√≠culo, Reuven Harrison, tiene m√°s de 20 a√Īos de experiencia en desarrollo de software, y hoy es el director t√©cnico y cofundador de Tufin, una empresa que crea soluciones de gesti√≥n de pol√≠ticas de seguridad. Considerando las pol√≠ticas de red de Kubernetes como una herramienta lo suficientemente poderosa para la segmentaci√≥n de red en un cl√ļster, cree que no son tan f√°ciles de aplicar en la pr√°ctica. Este material (bastante voluminoso) est√° dise√Īado para mejorar el conocimiento de los especialistas en este tema y ayudarlos a crear las configuraciones necesarias.

Hoy en día, muchas empresas eligen cada vez más a Kubernetes para ejecutar sus aplicaciones. El interés en este software es tan alto que algunos llaman a Kubernetes "el nuevo sistema operativo del centro de datos". Gradualmente, Kubernetes (o k8s) comienza a ser percibido como una parte crítica del negocio, lo que requiere la organización de procesos comerciales maduros, incluida la seguridad de la red.

Para los profesionales de seguridad que están desconcertados al trabajar con Kubernetes, la política predeterminada de esta plataforma puede ser un verdadero descubrimiento: permitirlo todo.

Esta guía lo ayudará a comprender la estructura interna de las políticas de red; Comprenda cómo difieren de las reglas para los firewalls normales. También se describirán algunas dificultades y se darán recomendaciones que ayudarán a proteger las aplicaciones en Kubernetes.

Políticas de red de Kubernetes


El mecanismo de política de red de Kubernetes le permite controlar la interacción de las aplicaciones implementadas en la plataforma a nivel de red (la tercera en el modelo OSI). Las políticas de red carecen de algunas de las características avanzadas de los firewalls modernos, como el monitoreo de nivel 7 de OSI y la detección de amenazas, pero proporcionan un nivel básico de seguridad de red, que es un buen punto de partida.

Las políticas de red controlan las comunicaciones entre pods


Las cargas de trabajo de Kubernetes se distribuyen entre pods que consisten en uno o más contenedores desplegados juntos. Kubernetes asigna a cada pod una dirección IP accesible desde otros pods. Las políticas de red de Kubernetes establecen permisos para grupos de pods de la misma manera que los grupos de seguridad en la nube se usan para controlar el acceso a las instancias de máquinas virtuales.

Definición de políticas de red


Al igual que otros recursos de Kubernetes, las políticas de red se establecen en YAML. En el siguiente ejemplo, el balance tiene acceso a postgres :

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.postgres namespace: default spec: podSelector: matchLabels: app: postgres ingress: - from: - podSelector: matchLabels: app: balance policyTypes: - Ingress 



( Nota : esta captura de pantalla, como todas las posteriores similares, no se creó con las herramientas nativas de Kubernetes, sino con la herramienta Tufin Orca, desarrollada por el autor del artículo original y mencionada al final del artículo).

La definici√≥n de su propia pol√≠tica de red requerir√° conocimientos b√°sicos de YAML. Este lenguaje se basa en la sangr√≠a (especificada por espacios, no por pesta√Īas). Un elemento sangrado pertenece al elemento sangrado m√°s cercano sobre √©l. Un nuevo elemento de la lista comienza con un gui√≥n, todos los dem√°s elementos son clave-valor .

Habiendo descrito la pol√≠tica en YAML, use kubectl para crearla en el cl√ļster:

 kubectl create -f policy.yaml 

Especificación de política de red


La especificación de política de red de Kubernetes incluye cuatro elementos:

  1. podSelector : define los pods afectados por esta política (objetivos) - obligatorio;
  2. policyTypes : indica qué tipos de políticas se incluyen en esto: ingreso y / o salida - opcional, sin embargo, le recomiendo que lo registre explícitamente en todos los casos;
  3. ingress : define el tr√°fico entrante permitido a los pods de destino - opcional;
  4. egress : define el tr√°fico saliente permitido desde los pods de destino - opcional.

Un ejemplo prestado del sitio web de Kubernetes (reemplacé el role con la app ) muestra cómo se usan los cuatro elementos:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy namespace: default spec: podSelector: # <<< matchLabels: app: 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 




Tenga en cuenta que los cuatro elementos son opcionales. Solo se podSelector , se pueden usar otros par√°metros seg√ļn se desee.

Si omite policyTypes , la política se interpretará de la siguiente manera:

  • Por defecto, se supone que define el lado de ingreso. Si la pol√≠tica no indica expl√≠citamente esto, el sistema considerar√° que todo el tr√°fico est√° prohibido.
  • El comportamiento en el lado de salida estar√° determinado por la presencia o ausencia del par√°metro de salida correspondiente.

Para evitar errores, recomiendo siempre especificar explícitamente policyTypes .

De acuerdo con la lógica anterior, si se omiten los egress ingress y / o egress , la política prohibirá todo el tráfico (ver "Regla de eliminación" a continuación).

La política predeterminada es permitir


Si no se definen políticas, Kubernetes permite de forma predeterminada todo el tráfico. Todos los pods son libres de intercambiar información entre ellos. Desde el punto de vista de la seguridad, esto puede parecer contradictorio, pero recuerde que Kubernetes fue creado originalmente por los desarrolladores para garantizar la interoperabilidad de las aplicaciones. Las políticas de red se agregaron más tarde.

Espacios de nombres


Los espacios de nombres son un mecanismo colaborativo de Kubernetes. Est√°n dise√Īados para aislar entornos l√≥gicos entre s√≠, mientras que el intercambio de datos entre espacios est√° permitido de forma predeterminada.

Como la mayoría de los componentes de Kubernetes, las políticas de red residen en un espacio de nombres específico. En el bloque de metadata , puede especificar a qué espacio pertenece la política:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy namespace: my-namespace # <<< spec: ... 

Si el espacio de nombres no está escrito explícitamente en los metadatos, el sistema usará el espacio de nombres especificado en kubectl (por defecto, namespace=default ):

 kubectl apply -n my-namespace -f namespace.yaml 

Recomiendo especificar expl√≠citamente un espacio de nombres a menos que est√© escribiendo una pol√≠tica destinada a m√ļltiples espacios de nombres a la vez.

El elemento principal podSelector en una política seleccionará pods del espacio de nombres al que pertenece la política (se le niega el acceso a pods de otro espacio de nombres).

Del mismo modo, podSelectors en bloques de entrada y salida pueden seleccionar pods solo de su espacio de nombres, a menos que, por supuesto, los combine con namespaceSelector (esto se discutirá en la sección "Filtrado por espacio de nombres y pods") .

Reglas de nomenclatura de políticas


Los nombres de pol√≠ticas son √ļnicos dentro de un √ļnico espacio de nombres. No puede haber dos pol√≠ticas con el mismo nombre en un espacio, pero puede haber pol√≠ticas con el mismo nombre en espacios diferentes. Esto es √ļtil cuando desea volver a aplicar la misma pol√≠tica en varios espacios.

Me gusta especialmente una forma de nombrar. Consiste en combinar el nombre del espacio de nombres con los pods de destino. Por ejemplo:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.postgres # <<< namespace: default spec: podSelector: matchLabels: app: postgres ingress: - from: - podSelector: matchLabels: app: admin policyTypes: - Ingress 



Etiquetas


Se pueden adjuntar etiquetas personalizadas a objetos de Kubernetes, como pods y espacios de nombres. Las etiquetas son el equivalente de las etiquetas en la nube. Las políticas de red de Kubernetes usan etiquetas para seleccionar los pods a los que se aplican:

 podSelector: matchLabels: role: db 

... o los espacios de nombres a los que se aplican. En este ejemplo, se seleccionan todos los pods en los espacios de nombres con las etiquetas correspondientes:

 namespaceSelector: matchLabels: project: myproject 

Una advertencia: cuando use namespaceSelector aseg√ļrese de que los namespaceSelector que seleccione contengan la etiqueta que desea . Tenga en cuenta que los espacios de nombres integrados como default y kube-system no contienen etiquetas por defecto.

Puede agregar una etiqueta al espacio de la siguiente manera:

 kubectl label namespace default namespace=default 

En este caso, el espacio de nombres en la sección de metadata debe referirse al nombre real del espacio y no a la etiqueta:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy namespace: default # <<< spec: ... 

Origen y Destino


Las políticas para firewalls consisten en reglas con orígenes y destinos. Las políticas de red de Kubernetes se definen para este propósito: un conjunto de pods a los que se aplican, y luego establecen reglas para el tráfico entrante (entrada) y / o saliente (salida). En nuestro ejemplo, el objetivo de la política será todos los pods en el espacio de nombres default con una etiqueta con la clave de la app y el valor db :

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: test-network-policy namespace: default spec: podSelector: matchLabels: app: 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 




La subsección de ingress en esta política abre el tráfico entrante a los pods de destino. En otras palabras, el ingreso es la fuente, y el objetivo es el destinatario apropiado. Del mismo modo, la salida es el objetivo, y el objetivo es su fuente.



Esto es equivalente a dos reglas para el firewall: Ingress ‚Üí Target; Objetivo ‚Üí Egreso.

Egress y DNS (¬°importante!)


Al limitar el tráfico saliente, preste especial atención al DNS : Kubernetes utiliza este servicio para asignar servicios a direcciones IP. Por ejemplo, la siguiente política no funcionará porque no permitió que la aplicación de balance acceda a DNS:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.balance namespace: default spec: podSelector: matchLabels: app: balance egress: - to: - podSelector: matchLabels: app: postgres policyTypes: - Egress 



Puede solucionarlo abriendo el acceso al servicio DNS:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.balance namespace: default spec: podSelector: matchLabels: app: balance egress: - to: - podSelector: matchLabels: app: postgres - to: # <<< ports: # <<< - protocol: UDP # <<< port: 53 # <<< policyTypes: - Egress 



El √ļltimo elemento to est√° vac√≠o y, por lo tanto, selecciona indirectamente todos los pods en todos los espacios de nombres , lo que permite que el balance env√≠e consultas DNS al servicio Kubernetes correspondiente (generalmente funciona en el espacio del kube-system ).

Este enfoque funciona, pero es demasiado permisivo e inseguro , ya que le permite dirigir consultas DNS fuera del cl√ļster.

Puedes mejorarlo en tres pasos consecutivos.

1. Permita consultas DNS solo dentro del cl√ļster agregando namespaceSelector :

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.balance namespace: default spec: podSelector: matchLabels: app: balance egress: - to: - podSelector: matchLabels: app: postgres - to: - namespaceSelector: {} # <<< ports: - protocol: UDP port: 53 policyTypes: - Egress 



2. Permitir consultas DNS solo en el espacio de nombres del kube-system .

Para hacer esto, agregue una etiqueta al kubectl label namespace kube-system namespace=kube-system kube-system : kubectl label namespace kube-system namespace=kube-system - y regístrelo en la política usando namespaceSelector :

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.balance namespace: default spec: podSelector: matchLabels: app: balance egress: - to: - podSelector: matchLabels: app: postgres - to: - namespaceSelector: # <<< matchLabels: # <<< namespace: kube-system # <<< ports: - protocol: UDP port: 53 policyTypes: - Egress 



3. Los paranoides pueden ir más allá y limitar las consultas DNS a un servicio DNS específico en kube-system . En la sección "Filtrar por espacios de nombres y pods", explicaremos cómo lograr esto.

Otra opción es resolver DNS a nivel de espacio de nombres. En este caso, no será necesario abrirlo para cada servicio:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.dns namespace: default spec: podSelector: {} # <<< egress: - to: - namespaceSelector: {} ports: - protocol: UDP port: 53 policyTypes: - Egress 

Un podSelector vacío selecciona todos los pods en el espacio de nombres.



Primer partido y orden de reglas


En los firewalls comunes, la acción ("Permitir" o "Denegar") para un paquete está determinada por la primera regla que cumple. En Kubernetes, el orden de las políticas es irrelevante.

De manera predeterminada, cuando no se establecen políticas, se permiten las comunicaciones entre pods y pueden intercambiar información libremente. Tan pronto como comience a formular políticas, cada grupo afectado por al menos una de ellas se aisla de acuerdo con la disyunción (OR lógico) de todas las políticas que lo han elegido. Las cápsulas no afectadas por ninguna política permanecen abiertas.

Puede cambiar este comportamiento utilizando la regla de eliminación.

Regla de pelado (denegar)


Las políticas de firewall generalmente prohíben cualquier tráfico explícitamente no autorizado.

Kubernetes no tiene una acción de denegación , sin embargo, se puede lograr un efecto similar con una política regular (permitida) seleccionando un grupo vacío de pods de origen (ingreso):

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all namespace: default spec: podSelector: {} policyTypes: - Ingress 



Esta política selecciona todos los pods en el espacio de nombres y deja la entrada indefinida, bloqueando todo el tráfico entrante.

Del mismo modo, puede limitar todo el tr√°fico saliente desde el espacio de nombres:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: deny-all-egress namespace: default spec: podSelector: {} policyTypes: - Egress 



Tenga en cuenta que cualquier política adicional que permita el tráfico a los pods en el espacio de nombres tendrá prioridad sobre esta regla (similar a agregar una regla de permiso sobre una regla de denegación en la configuración del firewall).

Permitir todo (Any-Any-Any-Allow)


Para crear una política Permitir todo, debe agregar la política prohibitiva anterior con un elemento de ingress vacío:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all namespace: default spec: podSelector: {} ingress: # <<< - {} # <<< policyTypes: - Ingress 



Permite el acceso desde todos los pods en todos los espacios de nombres (y todas las IP) a cualquier pod en el espacio de nombres default . Este comportamiento está habilitado de forma predeterminada, por lo que generalmente no es necesario definirlo adicionalmente. Sin embargo, a veces puede ser necesario desactivar temporalmente algunos permisos específicos para diagnosticar el problema.

La regla se puede restringir y permitir el acceso solo a un conjunto específico de pods ( app:balance ) en el espacio de nombres default :

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all-to-balance namespace: default spec: podSelector: matchLabels: app: balance ingress: - {} policyTypes: - Ingress 



La siguiente pol√≠tica permite todo el tr√°fico de entrada y salida, incluido el acceso a cualquier IP fuera del cl√ļster:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-all spec: podSelector: {} ingress: - {} egress: - {} policyTypes: - Ingress - Egress 




Combinando m√ļltiples pol√≠ticas


Las políticas se combinan utilizando OR lógico en tres niveles; Los permisos de cada pod se establecen de acuerdo con la disyunción de todas las políticas que lo afectan:

1. En los campos from y to , puede definir tres tipos de elementos (todos se combinan mediante OR):

  • namespaceSelector : selecciona todo el espacio de nombres;
  • podSelector : selecciona pods;
  • ipBlock : selecciona una subred.

Al mismo tiempo, el n√ļmero de elementos (incluso el mismo) en las subsecciones from / to no est√° limitado. Todos ellos se combinar√°n por OR l√≥gico.

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.postgres namespace: default spec: ingress: - from: - podSelector: matchLabels: app: indexer - podSelector: matchLabels: app: admin podSelector: matchLabels: app: postgres policyTypes: - Ingress 



2. Dentro de la política, la sección de ingress puede tener muchos elementos (combinados por OR lógico). Del mismo modo, la sección de egress puede incluir muchos elementos (también unidos por una cláusula):

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.postgres namespace: default spec: ingress: - from: - podSelector: matchLabels: app: indexer - from: - podSelector: matchLabels: app: admin podSelector: matchLabels: app: postgres policyTypes: - Ingress 



3. Varias políticas también se combinan mediante OR lógico

Pero cuando se combinan, hay una limitaci√≥n que Chris Cooney se√Īal√≥ : Kubernetes solo puede combinar pol√≠ticas con diferentes policyTypes pol√≠ticas ( Ingress o Egress ). Las pol√≠ticas que definen la entrada (o salida) se sobrescribir√°n entre s√≠.

La relación entre espacios de nombres


Por defecto, se permite el intercambio de información entre espacios de nombres. Esto se puede cambiar utilizando una política prohibitiva que restringe el tráfico saliente y / o entrante en el espacio de nombres (consulte "Regla de eliminación" arriba).

Al bloquear el acceso al espacio de nombres (consulte "Regla de eliminación" más arriba), puede hacer excepciones a la política restrictiva permitiendo conexiones desde un espacio de nombres específico usando namespaceSelector :

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: database.postgres namespace: database spec: podSelector: matchLabels: app: postgres ingress: - from: - namespaceSelector: # <<< matchLabels: namespace: default policyTypes: - Ingress 



Como resultado, todos los pods en el espacio de nombres default tendr√°n acceso a los pods postgres en el espacio de nombres de la database . Pero, ¬Ņqu√© postgres si desea abrir el acceso a postgres solo a pods espec√≠ficos en el espacio de nombres default ?

Filtrar por espacios de nombres y pods


Kubernetes versión 1.11 y superior le permite combinar los operadores namespaceSelector y podSelector utilizando el I. lógico. Se ve así:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: database.postgres namespace: database spec: podSelector: matchLabels: app: postgres ingress: - from: - namespaceSelector: matchLabels: namespace: default podSelector: # <<< matchLabels: app: admin policyTypes: - Ingress 



¬ŅPor qu√© se interpreta como AND en lugar del OR habitual?

Tenga en cuenta que podSelector no comienza con un guión. En YAML, esto significa que podSelector y el namespaceSelector delante de él hacen referencia al mismo elemento de la lista. Por lo tanto, se combinan por el yo lógico.

Agregar un guión delante de podSelector dará como resultado un nuevo elemento de lista que se combinará con el anterior namespaceSelector utilizando un OR lógico.

Para seleccionar pods con una etiqueta específica en todos los espacios de nombres , ingrese un namespaceSelector vacío.

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: database.postgres namespace: database spec: podSelector: matchLabels: app: postgres ingress: - from: - namespaceSelector: {} podSelector: matchLabels: app: admin policyTypes: - Ingress 



M√ļltiples etiquetas se combinan con AND


Las reglas para un firewall con muchos objetos (hosts, redes, grupos) se combinan mediante un OR lógico. La siguiente regla funcionará si la fuente del paquete coincide con Host_1 O Host_2 :

 | Source | Destination | Service | Action | | ----------------------------------------| | Host_1 | Subnet_A | HTTPS | Allow | | Host_2 | | | | | ----------------------------------------| 

Por el contrario, en Kubernetes, varias etiquetas en podSelector o namespaceSelector se combinan por lógica I. Por ejemplo, la siguiente regla seleccionará pods que tengan ambas etiquetas, role=db AND version=v2 :

 podSelector: matchLabels: role: db version: v2 

La misma lógica se aplica a todos los tipos de operadores: selectores de objetivos de políticas, selectores de pod y selectores de espacio de nombres.

Subredes y direcciones IP (IPBlocks)


Los cortafuegos utilizan VLAN, direcciones IP y subredes para segmentar una red.

En Kubernetes, las direcciones IP se asignan a los pods automáticamente y pueden cambiar con frecuencia, por lo que las etiquetas se utilizan para seleccionar pods y espacios de nombres en las políticas de red.

ipBlocks ( ipBlocks ) se utilizan para controlar las conexiones externas (norte-sur) de entrada (entrada) o de salida (salida). Por ejemplo, esta política da acceso a todos los pods del espacio de nombres default al servicio DNS de Google:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: egress-dns namespace: default spec: podSelector: {} policyTypes: - Egress egress: - to: - ipBlock: cidr: 8.8.8.8/32 ports: - protocol: UDP port: 53 



El selector de pod vacío en este ejemplo significa "seleccionar todos los pod en el espacio de nombres".

Esta pol√≠tica proporciona acceso solo a 8.8.8.8; se deniega el acceso a cualquier otra IP. Por lo tanto, en esencia, bloque√≥ el acceso al servicio DNS interno de Kubernetes. Si a√ļn desea abrirlo, especif√≠quelo expl√≠citamente.

Por ipBlocks general, ipBlocks y podSelectors son mutuamente excluyentes, ya que las direcciones IP internas de los pods no se usan en ipBlocks . Al especificar pods IP internos , en realidad permitirá conexiones a / desde pods con estas direcciones. En la práctica, no sabrá qué dirección IP usar, razón por la cual no deben usarse para seleccionar pods.

Como contraejemplo, la siguiente política incluye todas las IP y, por lo tanto, permite el acceso a todos los demás pods:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: egress-any namespace: default spec: podSelector: {} policyTypes: - Egress egress: - to: - ipBlock: cidr: 0.0.0.0/0 



Puede abrir el acceso solo a IP externas excluyendo las direcciones IP internas de los pods. Por ejemplo, si la subred de su pod es 10.16.0.0/14:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: egress-any namespace: default spec: podSelector: {} policyTypes: - Egress egress: - to: - ipBlock: cidr: 0.0.0.0/0 except: - 10.16.0.0/14 



Puertos y Protocolos


Por lo general, los pods escuchan en un puerto. Esto significa que simplemente puede omitir los n√ļmeros de puerto en las pol√≠ticas y dejar todo como predeterminado. Sin embargo, se recomienda que las pol√≠ticas se hagan lo m√°s restrictivas posible, por lo que en algunos casos a√ļn puede especificar puertos:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.postgres namespace: default spec: ingress: - from: - podSelector: matchLabels: app: indexer - podSelector: matchLabels: app: admin ports: # <<< - port: 443 # <<< protocol: TCP # <<< - port: 80 # <<< protocol: TCP # <<< podSelector: matchLabels: app: postgres policyTypes: - Ingress 



Observe que el selector de ports aplica a todos los elementos en el bloque to o from que contiene. Para especificar diferentes puertos para diferentes conjuntos de elementos, divida la ingress o la egress en varias subsecciones con ay from y enumere sus puertos en cada uno:

 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default.postgres namespace: default spec: ingress: - from: - podSelector: matchLabels: app: indexer ports: # <<< - port: 443 # <<< protocol: TCP # <<< - from: - podSelector: matchLabels: app: admin ports: # <<< - port: 80 # <<< protocol: TCP # <<< podSelector: matchLabels: app: postgres policyTypes: - Ingress 



Los puertos predeterminados funcionan:

  • Si omite por completo la definici√≥n de puertos, esto significa todos los protocolos y todos los puertos;
  • Si omite la definici√≥n del protocolo, significa TCP;
  • Si omite la definici√≥n de un puerto, esto significa todos los puertos.

Práctica recomendada: no confíe en los valores predeterminados, especifique lo que necesita explícitamente.

Tenga en cuenta que es necesario usar puertos de pod, no servicios (m√°s sobre esto en el siguiente p√°rrafo).

¬ŅSe definen pol√≠ticas para pods o servicios?


Por lo general, los pods en Kubernetes se contactan entre sí a través de un servicio: un equilibrador de carga virtual que redirige el tráfico a los pods que implementan el servicio. Puede pensar que las políticas de red controlan el acceso a los servicios, pero esto no es así. Las políticas de red de Kubernetes funcionan con puertos de pod, no con servicios.

, 80- , 8080 pod', 8080.

: ( pod') .

Service Mesh (, . Istio ‚ÄĒ . .) .

Ingress, Egress?


‚ÄĒ , pod pod' , ( egress-), pod ( , , ingress-).

, .

pod- egress -, . pod'- . pod - , (egress) .

pod'- , ingress -, . pod'-. pod - , (ingress) .

. ¬ęStateful Stateless¬Ľ .


Kubernetes . , , .


Kubernetes (DNS) egress. , IP- ( aws.com).


. Kubernetes . kubectl Kubernetes , , . Kubernetes . :

 kubernetes get networkpolicy <policy-name> -o yaml 

, Kubernetes .


Kubernetes , API-, , Container Networking Interface (CNI). Kubernetes CNI . CNI , Kubernetes, ( ‚ÄĒ . .) , , CNI .

, Kubernetes , CNI.

Stateful Stateless?


CNI Kubernetes, , (, Calico Linux conntrack). pod' TCP- . Kubernetes, (statefulness).


Kubernetes:

  1. Service Mesh sidecar- . Istio .
  2. CNI , Kubernetes.
  3. Tufin Orca Kubernetes.

Tufin Orca Kubernetes ( , ).



Conclusión


Kubernetes , . , - . .

, , .

PD del traductor


Lea también en nuestro blog:

Source: https://habr.com/ru/post/443190/


All Articles