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:
podSelector : define los pods afectados por esta política (objetivos) - obligatorio;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;ingress : define el tráfico entrante permitido a los pods de destino - opcional;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:
- Service Mesh sidecar- . Istio .
- CNI , Kubernetes.
- Tufin Orca Kubernetes.
Tufin Orca Kubernetes ( , ).
Conclusión
Kubernetes , . , - . .
, , .
PD del traductor
Lea también en nuestro blog: