From b2034013f8db61d16958f08667008c493fb8afc7 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Sun, 3 Jul 2022 18:22:08 +0200 Subject: [PATCH 01/52] [es] Localize NetworkPolicies Signed-off-by: Nicolas Quiceno B --- .../services-networking/network-policies.md | 288 ++++++++++++++++++ .../network-policy-allow-all-egress.yaml | 11 + .../network-policy-allow-all-ingress.yaml | 11 + .../network-policy-default-deny-all.yaml | 10 + .../network-policy-default-deny-egress.yaml | 9 + .../network-policy-default-deny-ingress.yaml | 9 + .../service/networking/networkpolicy.yaml | 35 +++ 7 files changed, 373 insertions(+) create mode 100644 content/es/docs/concepts/services-networking/network-policies.md create mode 100644 content/es/examples/service/networking/network-policy-allow-all-egress.yaml create mode 100644 content/es/examples/service/networking/network-policy-allow-all-ingress.yaml create mode 100644 content/es/examples/service/networking/network-policy-default-deny-all.yaml create mode 100644 content/es/examples/service/networking/network-policy-default-deny-egress.yaml create mode 100644 content/es/examples/service/networking/network-policy-default-deny-ingress.yaml create mode 100644 content/es/examples/service/networking/networkpolicy.yaml diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md new file mode 100644 index 0000000000..11b08ddb2c --- /dev/null +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -0,0 +1,288 @@ +--- +reviewers: +- raelga +- electrocucaracha +title: Políticas de red (Network Policies) +content_type: concept +weight: 50 +--- + + + +Si quieres controlar el tráfico de red a nivel de dirección IP o de puerto (capa OSI 3 o 4), puedes considerar el uso de Kubernetes NetworkPolicies para las aplicaciones que corren en tu clúster. Las NetworkPolicies son una estructura enfocada en las aplicaciones que permite establecer cómo un {{< glossary_tooltip text="pod" term_id="pod">}} puede comunicarse con otras "entidades" (utilizamos la palabra "entidad" para evitar sobrecargar términos más comunes como "Endpoint" o "Service", que tienen connotaciones específicas de Kubernetes) a través de la red. Las NetworkPolicies se aplican a uno o ambos extremos de la conexión a un Pod, sin afectar a otras conexiones. + +Las entidades con las que un Pod puede comunicarse son de una combinación de estos 3 tipos: + +1. Otros pods permitidos (excepción: un pod no puede bloquear el acceso a sí mismo) +2. Namespaces permitidos +3. Bloqueos de IP (excepción: el tráfico hacia y desde el nodo donde se ejecuta un Pod siempre está permitido, independientemente de la dirección IP del Pod o del nodo) + +Cuando se define una NetworkPolicy basada en pods o espacios de nombres, se utiliza un {{< glossary_tooltip text="selector" term_id="selector">}} para especificar qué tráfico se permite desde y hacia los Pod(s) que coinciden con el selector. + +Por otro lado, cuando se crean NetworkPolicies basadas en IP, se definen políticas basadas en bloques de IP (rangos CIDR). + + + +## Prerrequisitos + +Las políticas de red son implementadas por el [plugin de red](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). Para usar políticas de red, debes estar utilizando una solución de red que soporte NetworkPolicy. Crear un recurso NetworkPolicy sin un controlador que lo habilite no tendrá ningún efecto. + + +## Dos Tipos de Aislamiento de Pod + +Hay dos tipos de aislamiento para un pod: el aislamiento para la salida y el aislamiento para la entrada. Estos se refieren a las conexiones que pueden establecerse. El término "Aislamiento" en el contexto de este documento no es absoluto, sino que significa "se aplican algunas restricciones". La alternativa, "no aislado para $dirección", significa que no se aplican restricciones en la dirección descrita. Los dos tipos de aislamiento (o no) se declaran independientemente, y ambos son relevantes para una conexión de un pod a otro. + +Por defecto, un pod no está aislado para la salida; todas las conexiones salientes están permitidas. Un pod está aislado para la salida si hay alguna NetworkPolicy con "Egress" en su `policyTypes` que seleccione el pod; decimos que tal política se aplica al pod para la salida. Cuando un pod está aislado para la salida, las únicas conexiones permitidas desde el pod son las permitidas por la lista `egress` de las NetworkPolicy que se aplique al pod para la salida. Los valores de esas listas `egress` se combinan de forma aditiva. + +Por defecto, un pod no está aislado para la entrada; todas las conexiones entrantes están permitidas. Un pod está aislado para la entrada si hay alguna NetworkPolicy con "Ingress" en su `policyTypes` que seleccione el pod; decimos que tal política se aplica al pod para la entrada. Cuando un pod está aislado para la entrada, las únicas conexiones permitidas en el pod son las del nodo del pod y las permitidas por la lista `ingress` de alguna NetworkPolicy que se aplique al pod para la entrada. Los valores de esas listas de direcciones se combinan de forma aditiva. + +Las políticas de red no entran en conflicto; son aditivas. Si alguna política o políticas se aplican a un pod para una dirección determinada, las conexiones permitidas en esa dirección desde ese pod es la unión de lo que permiten las políticas aplicables. Por tanto, el orden de evaluación no afecta al resultado de la política. + +Para que se permita una conexión desde un pod de origen a un pod de destino, tanto la política de salida del pod de origen como la de entrada del pod de destino deben permitir la conexión. Si cualquiera de los dos lados no permite la conexión, ésta no se producirá. + + +## El Recurso NetworkPolicy {#networkpolicy-resource} + +Ver la referencia [NetworkPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#networkpolicy-v1-networking-k8s-io) para una definición completa del recurso. + +Un ejemplo de NetworkPolicy pudiera ser este: + +{{< codenew file="service/networking/networkpolicy.yaml" >}} + +{{< note >}} +Enviar esto al API Server de su clúster no tendrá ningún efecto a menos que su solución de red tenga soporte de políticas de red. +{{< /note >}} + +__Campos Obligatorios__: Como con todos los otras configuraciones de Kubernetes, una NetworkPolicy +necesita los campos `apiVersion`, `kind`, y `metadata`. Para obtener información general +sobre cómo funcionan esos ficheros de configuración, mirar +[Configurar un Pod para usar un ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/), +y [Gestión de Objetos](/docs/concepts/overview/working-with-objects/object-management). + +__spec__: NetworkPolicy [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) contiene toda la información necesaria para definir una política de red dado un Namespace. + +__podSelector__: Cada NetworkPolicy incluye un `podSelector` el cual selecciona el grupo de Pods en los cuales aplica la política. La política de ejemplo selecciona pods con el label "role=db". Un `podSelector` vacío selecciona todos los Pods en un Namespace. + +__policyTypes__: Cada NetworkPolicy incluye una lista de `policyTypes` la cual puede incluir `Ingress`, `Egress`, o ambas. Los campos `policyTypes` indican si la política aplica o no aplica al tráfico de entrada hacia el Pod seleccionado, el tráfico de salida desde el Pods seleccionado, o ambos. Si no se especifican `policyTypes` en una NetworkPolicy el valor `Ingress` será siempre aplicado por defecto y `Egress` será aplicado si la NetworkPolicy contiene alguna regla de salida. + +__ingress__: Cada NetworkPolicy puede incluir una lista de reglas `ingress` permitidas. Cada regla permite el tráfico con que se corresponda a ambos valores de las secciones de `from` y `ports`. La política de ejemplo contiene una única regla, la cual se corresponde con el tráfico sobre un solo puerto, desde uno de los tres orígenes definidos, el primero especificado por el valor `ipBlock`, el segundo especificado por el valor `namespaceSelector` y el tercero especificado por el `podSelector`. + +__egress__: Cada NetworkPolicy puede incluir una lista de reglas de `egress` permitidas. Cada regla permite el tráfico con que se corresponda a ambos valores de las secciones de `to` and `ports`. La política de ejemplo contiene una única regla, la cual se corresponde con el tráfico en un único puerto para cualquier destino en el rango de IPs `10.0.0.0/24`. + +Por lo tanto, la NetworkPolicy de ejemplo: + +1. Aísla los pods "role=db" en el "default" namespace para ambos tipos de tráfico ingress y egress (si ellos no están aún aislados) +2. (Reglas Ingress) permite la coneccion hacia todos los pods en el "default" namespace con el label "role=db" en el puerto TCP 6379 desde los siguientes orígenes: + + * cualquier pod en el "default" namespace con el label "role=frontend" + * cualquier pod en un namespace con el label "project=myproject" + * La dirección IP en los rangos 172.17.0.0–172.17.0.255 y 172.17.2.0–172.17.255.255 (por ejemplo, todo el rango de IPs de 172.17.0.0/16 con excepción del 172.17.1.0/24) +3. (Egress rules) permite coneccion desde cualquier pods en el "default" namespace con el label "role=db" hacia CIDR 10.0.0.0/24 en el puerto TCP 5978 + +Ver el recorrido de [Declarar Network Policy](/docs/tasks/administer-clúster/declare-network-policy/) para más ejemplos. + + +## Comportamiento de los selectores `to` y `from` + +Existen cuatro tipos de selectores que pueden ser especificados en una sección de `ingress` `from` or en una sección de `egress` `to`: + +__podSelector__: Este selector selecciona Pods específicos en el mismo espacio de nombres que la NetworkPolicy para permitir el tráfico como fuente de entrada o destino de salida. + +__namespaceSelector__: Este selector selecciona espacios de nombres específicos para permitir el tráfico como fuente de entrada o destino de salida. + +__namespaceSelector__ *y* __podSelector__: Una única entrada `to`/`from` que especifique tanto `namespaceSelector` como `podSelector` selecciona Pods específicos dentro de espacios de nombres específicos. Tenga cuidado de utilizar la sintaxis YAML correcta. A continuación se muestra un ejemplo de esta política: + +```yaml + ... + ingress: + - from: + - namespaceSelector: + matchLabels: + user: alice + podSelector: + matchLabels: + role: client + ... +``` + +contiene un único elemento `from` permitiendo conexiones desde los Pods con el label `role=client` en nombres de espacio con el label `user=alice`. Por el contrario, *esta* política: + +```yaml + ... + ingress: + - from: + - namespaceSelector: + matchLabels: + user: alice + - podSelector: + matchLabels: + role: client + ... +``` + + +contiene dos elementos en el array `from`, y permite conecciones desde Pods en el local Namespace con el label `role=client`, *o* desde cualquier Pod en cualquier nombre de espacio con el label `user=alice`. + +En caso de duda, utilice `kubectl describe` para ver cómo Kubernetes ha interpretado la política. + + + +__ipBlock__: Este selector selecciona rangos CIDR de IP específicos para permitirlas como fuentes de entrada o destinos de salida. Estas IPs deben ser externas al clúster, ya que las IPs de Pod son efímeras e impredecibles. + +Los mecanismos de entrada y salida del clúster a menudo requieren reescribir la IP de origen o destino +de los paquetes. En los casos en los que esto ocurre, no está definido si esto ocurre antes o +después del procesamiento de NetworkPolicy, y el comportamiento puede ser diferente para diferentes +combinaciones de plugin de red, proveedor de nube, implementación de `Service`, etc. + +En el caso de la entrada, esto significa que en algunos casos se pueden filtrar paquetes +entrantes basándose en la IP de origen real, mientras que en otros casos, la "IP de origen" sobre la que actúa la +la NetworkPolicy actúa puede ser la IP de un `LoadBalancer` o la IP de Nodo donde este el Pod involucrado, etc. + +Para la salida, esto significa que las conexiones de los pods a las IPs de `Service` que se reescriben a +IPs externas al clúster pueden o no estar sujetas a políticas basadas en `ipBlock`. + + +## Políticas por defecto + +Por defecto, si no existen políticas en un espacio de nombres, se permite todo el tráfico de entrada y salida hacia y desde los pods de ese espacio de nombres. Los siguientes ejemplos muestran cómo cambiar el comportamiento por defecto en ese espacio de nombres. + + +### Denegar todo el tráfico de entrada por defecto + +Puedes crear una política que "por defecto" aisle a un espacio de nombres del tráfico de entrada con la creación de una política que seleccione todos los Pods del espacio de nombres pero no permite ningún tráfico de entrada en esos Pods. + +{{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}} + +Esto asegura que incluso los Pods que no están seleccionados por ninguna otra NetworkPolicy también serán aislados del tráfico de entrada. Esta política no afecta el aislamiento en el tráfico de salida desde cualquier Pods. + + +### Permitir todo el tráfico de entrada + +Si tu quieres permitir todo el tráfico de entrada a todos los Pods en un nombre de espacio, puedes crear una política que explícitamente permita eso. + +{{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}} + +Con esta política en curso, ninguna política o políticas adicionales pueden hacer que se deniegue cualquier conexión entrante a esos pods. Esta política no tiene efecto sobre el aislamiento del tráfico de salida de cualquier pod. + + +### Denegar por defecto todo el tráfico de salida + +Puedes crear una política que "por defecto" aisle el tráfico de salida para un espacio de nombres, creando una NetworkPolicy que seleccione todos los pods pero que no permita ningún tráfico de salida desde esos pods. + +{{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}} + +Esto asegura que incluso los pods que no son seleccionados por ninguna otra NetworkPolicy no tendrán permitido el tráfico de salida. Esta política no cambia el comportamiento de aislamiento para el tráfico de entrada de ningún pod. + + +### Permitir todo el tráfico de salida + +Si quieres permitir todas las conexiones desde todos los pods de un espacio de nombres, puede crear una política que permita explícitamente todas las conexiones salientes de los pods de ese espacio de nombres. + +{{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}} + +Con esta política en vigor, ninguna política o políticas adicionales pueden hacer que se deniegue cualquier conexión de salida desde esos pods. Esta política no tiene efecto sobre el aislamiento para el tráfico de entrada a cualquier pod. + + +### Denegar por defecto todo el tráfico de entrada y de salida + +Puede crear una política que "por defecto" en un espacio de nombres impida todo el tráfico de entrada Y de salida creando la siguiente NetworkPolicy en ese espacio de nombres. + +{{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}} + +Esto asegura que incluso los pods que no son seleccionados por ninguna otra NetworkPolicy no tendrán permitido el tráfico de entrada o salida. + + +## Soporte a SCTP + +{{< feature-state for_k8s_version="v1.20" state="stable" >}} + +Como característica estable, está activada por defecto. Para deshabilitar SCTP a nivel de clúster, usted (o el administrador de su clúster) tiene que deshabilitar la [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `SCTPSupport` para el API Server con el flag `--feature-gates=SCTPSupport=false,...`. +Cuando esta feature gate está habilitada, puede establecer el campo `protocol` de una NetworkPolicy como `SCTP`. + +{{< note >}} +Debes utilizar un plugin de {{< glossary_tooltip text="CNI" term_id="cni" >}} que soporte el protocolo SCTP NetworkPolicies. +{{< /note >}} + + +## Apuntar a un rango de puertos + +{{< feature-state for_k8s_version="v1.22" state="beta" >}} + +Cuando se escribe una NetworkPolicy, se puede apuntar a un rango de puertos en lugar de un solo puerto. + +Esto se puede lograr con el uso del campo `endPort`, como el siguiente ejemplo: + +```yaml +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: multi-port-egress + namespace: default +spec: + podSelector: + matchLabels: + role: db + policyTypes: + - Egress + egress: + - to: + - ipBlock: + cidr: 10.0.0.0/24 + ports: + - protocol: TCP + port: 32000 + endPort: 32768 +``` + +La regla anterior permite que cualquier Pod con la etiqueta `role=db` en el espacio de nombres `default` se comunique +con cualquier IP dentro del rango `10.0.0.0/24` sobre el protocolo TCP, siempre que el puerto +esté entre el rango 32000 y 32768. + +Se aplican las siguientes restricciones al utilizar este campo: +* Como característica en estado beta, está activada por defecto. Para desactivar el campo `endPort` a nivel de clúster, usted (o su administrador de clúster) debe desactivar la [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `NetworkPolicyEndPort` +en el API Server con el flag `--feature-gates=NetworkPolicyEndPort=false,...`. +* El campo `endPort` debe ser igual o mayor que el campo `port`. +* Sólo se puede definir `endPort` si también se define `port`. +* Ambos puertos deben ser numéricos. + + +{{< note >}} +Su clúster debe utilizar un plugin de {{< glossary_tooltip text="CNI" term_id="cni" >}} que +soporte el campo `endPort` en las especificaciones de NetworkPolicy. +Si su [plugin de red](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) +no soporta el campo `endPort` y usted especifica una NetworkPolicy que use este campo, +la política se aplicará sólo para el campo `port`. +{{< /note >}} + + +## Como apuntar a un Namespace usando su nombre + +{{< feature-state for_k8s_version="1.22" state="stable" >}} + +El plano de control de Kubernetes establece una etiqueta inmutable `kubernetes.io/metadata.name` en todos los +espacios de nombre, siempre que se haya habilitado la [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `NamespaceDefaultLabelName`. +El valor de la etiqueta es el nombre del espacio de nombres. + +Aunque NetworkPolicy no puede apuntar a un espacio de nombres por su nombre con algún campo de objeto, puede utilizar la etiqueta estandarizada para apuntar a un espacio de nombres específico. + + + ## Que no puedes hacer con políticas de red (al menos, no aún) + +A día de hoy, en Kubernetes {{< skew currentVersion >}}, la siguiente funcionalidad no existe en la API de NetworkPolicy, pero es posible que se puedan implementar soluciones mediante componentes del sistema operativo (como SELinux, OpenVSwitch, IPTables, etc.) o tecnologías de capa 7 (Ingress controllers, implementaciones de Service Mesh) o controladores de admisión. En caso de que seas nuevo en la seguridad de la red en Kubernetes, vale la pena señalar que las siguientes historias de usuario no pueden (todavía) ser implementadas usando la API NetworkPolicy. + +- Forzar que el tráfico interno del clúster pase por una puerta de enlace común (esto se puede implementar con una malla de servicios u otro proxy). +- Cualquier cosa relacionada con TLS (se puede implementar con una malla de servicios o un Ingress controllers para esto). +- Políticas específicas de los nodos (se puede utilizar la notación CIDR para esto, pero no se puede apuntar a los nodos por sus identidades Kubernetes específicamente). +- Apuntar a los servicios por su nombre (sin embargo, puede orientar los pods o los espacios de nombres por su {{< glossary_tooltip text="labels" term_id="label" >}}, lo que suele ser una solución viable). +- Creación o gestión de "solicitudes de políticas" que son atendidas por un tercero. +- Políticas que por defecto son aplicadas a todos los espacios de nombres o pods (hay algunas distribuciones y proyectos de Kubernetes de terceros que pueden hacer esto). +- Consulta avanzada de políticas y herramientas de accesibilidad. +- La capacidad de registrar los eventos de seguridad de la red (por ejemplo, las conexiones bloqueadas o aceptadas). +- La capacidad de negar explícitamente las políticas (actualmente el modelo para NetworkPolicies es negar por defecto, con sólo la capacidad de añadir reglas de permitir). +- La capacidad de impedir el tráfico entrante de Loopback o de Host (actualmente los Pods no pueden bloquear el acceso al host local, ni tienen la capacidad de bloquear el acceso desde su nodo residente). + + +## {{% heading "whatsnext" %}} + +- Leer el recorrido de como [Declarar de Políticas de Red](/docs/tasks/administer-clúster/declare-network-policy/) para ver más ejemplos. +- Ver más [recetas](https://github.com/ahmetb/kubernetes-network-policy-recipes) de escenarios comunes habilitados por los recursos de las NetworkPolicy. diff --git a/content/es/examples/service/networking/network-policy-allow-all-egress.yaml b/content/es/examples/service/networking/network-policy-allow-all-egress.yaml new file mode 100644 index 0000000000..42b2a2a296 --- /dev/null +++ b/content/es/examples/service/networking/network-policy-allow-all-egress.yaml @@ -0,0 +1,11 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: allow-all-egress +spec: + podSelector: {} + egress: + - {} + policyTypes: + - Egress diff --git a/content/es/examples/service/networking/network-policy-allow-all-ingress.yaml b/content/es/examples/service/networking/network-policy-allow-all-ingress.yaml new file mode 100644 index 0000000000..462912dae4 --- /dev/null +++ b/content/es/examples/service/networking/network-policy-allow-all-ingress.yaml @@ -0,0 +1,11 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: allow-all-ingress +spec: + podSelector: {} + ingress: + - {} + policyTypes: + - Ingress diff --git a/content/es/examples/service/networking/network-policy-default-deny-all.yaml b/content/es/examples/service/networking/network-policy-default-deny-all.yaml new file mode 100644 index 0000000000..5c0086bd71 --- /dev/null +++ b/content/es/examples/service/networking/network-policy-default-deny-all.yaml @@ -0,0 +1,10 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: default-deny-all +spec: + podSelector: {} + policyTypes: + - Ingress + - Egress diff --git a/content/es/examples/service/networking/network-policy-default-deny-egress.yaml b/content/es/examples/service/networking/network-policy-default-deny-egress.yaml new file mode 100644 index 0000000000..a4659e1417 --- /dev/null +++ b/content/es/examples/service/networking/network-policy-default-deny-egress.yaml @@ -0,0 +1,9 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: default-deny-egress +spec: + podSelector: {} + policyTypes: + - Egress diff --git a/content/es/examples/service/networking/network-policy-default-deny-ingress.yaml b/content/es/examples/service/networking/network-policy-default-deny-ingress.yaml new file mode 100644 index 0000000000..e823802487 --- /dev/null +++ b/content/es/examples/service/networking/network-policy-default-deny-ingress.yaml @@ -0,0 +1,9 @@ +--- +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: default-deny-ingress +spec: + podSelector: {} + policyTypes: + - Ingress diff --git a/content/es/examples/service/networking/networkpolicy.yaml b/content/es/examples/service/networking/networkpolicy.yaml new file mode 100644 index 0000000000..e91eed2f67 --- /dev/null +++ b/content/es/examples/service/networking/networkpolicy.yaml @@ -0,0 +1,35 @@ +apiVersion: networking.k8s.io/v1 +kind: NetworkPolicy +metadata: + name: test-network-policy + namespace: default +spec: + podSelector: + matchLabels: + role: db + policyTypes: + - Ingress + - Egress + ingress: + - from: + - ipBlock: + cidr: 172.17.0.0/16 + except: + - 172.17.1.0/24 + - namespaceSelector: + matchLabels: + project: myproject + - podSelector: + matchLabels: + role: frontend + ports: + - protocol: TCP + port: 6379 + egress: + - to: + - ipBlock: + cidr: 10.0.0.0/24 + ports: + - protocol: TCP + port: 5978 + From 857d3cd9f4be98e5dbd78e6cc7da1a03de8f7349 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:13:57 +0200 Subject: [PATCH 02/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 11b08ddb2c..47a0efcf89 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -9,7 +9,7 @@ weight: 50 -Si quieres controlar el tráfico de red a nivel de dirección IP o de puerto (capa OSI 3 o 4), puedes considerar el uso de Kubernetes NetworkPolicies para las aplicaciones que corren en tu clúster. Las NetworkPolicies son una estructura enfocada en las aplicaciones que permite establecer cómo un {{< glossary_tooltip text="pod" term_id="pod">}} puede comunicarse con otras "entidades" (utilizamos la palabra "entidad" para evitar sobrecargar términos más comunes como "Endpoint" o "Service", que tienen connotaciones específicas de Kubernetes) a través de la red. Las NetworkPolicies se aplican a uno o ambos extremos de la conexión a un Pod, sin afectar a otras conexiones. +Si quieres controlar el tráfico de red a nivel de dirección IP o puerto (capa OSI 3 o 4), puedes considerar el uso de Kubernetes NetworkPolicies para las aplicaciones que corren en tu clúster. Las NetworkPolicies son una estructura enfocada en las aplicaciones que permite establecer cómo un {{< glossary_tooltip text="Pod" term_id="pod">}} puede comunicarse con otras "entidades" (utilizamos la palabra "entidad" para evitar sobrecargar términos más comunes como "Endpoint" o "Service", que tienen connotaciones específicas de Kubernetes) a través de la red. Las NetworkPolicies se aplican a uno o ambos extremos de la conexión a un Pod, sin afectar a otras conexiones. Las entidades con las que un Pod puede comunicarse son de una combinación de estos 3 tipos: From ee2f62ce72cb0c73d5ee99154e68dbf472780920 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:14:12 +0200 Subject: [PATCH 03/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 47a0efcf89..0dd4ab2f43 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -13,7 +13,7 @@ Si quieres controlar el tráfico de red a nivel de dirección IP o puerto (capa Las entidades con las que un Pod puede comunicarse son de una combinación de estos 3 tipos: -1. Otros pods permitidos (excepción: un pod no puede bloquear el acceso a sí mismo) +1. Otros Pods permitidos (excepción: un Pod no puede bloquear el acceso a sí mismo) 2. Namespaces permitidos 3. Bloqueos de IP (excepción: el tráfico hacia y desde el nodo donde se ejecuta un Pod siempre está permitido, independientemente de la dirección IP del Pod o del nodo) From b8f3bfee17550bb1ad0e326a5d6dc29a83795820 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:15:26 +0200 Subject: [PATCH 04/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 0dd4ab2f43..c0fb4bd2b9 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -17,7 +17,7 @@ Las entidades con las que un Pod puede comunicarse son de una combinación de es 2. Namespaces permitidos 3. Bloqueos de IP (excepción: el tráfico hacia y desde el nodo donde se ejecuta un Pod siempre está permitido, independientemente de la dirección IP del Pod o del nodo) -Cuando se define una NetworkPolicy basada en pods o espacios de nombres, se utiliza un {{< glossary_tooltip text="selector" term_id="selector">}} para especificar qué tráfico se permite desde y hacia los Pod(s) que coinciden con el selector. +Cuando se define una NetworkPolicy basada en Pods o Namespaces, se utiliza un {{< glossary_tooltip text="Selector" term_id="selector">}} para especificar qué tráfico se permite desde y hacia los Pod(s) que coinciden con el selector. Por otro lado, cuando se crean NetworkPolicies basadas en IP, se definen políticas basadas en bloques de IP (rangos CIDR). From daa869f777010c2ae5f32bfc9b643ac999cf924e Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:16:45 +0200 Subject: [PATCH 05/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index c0fb4bd2b9..8c25d57a60 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -30,7 +30,7 @@ Las políticas de red son implementadas por el [plugin de red](/docs/concepts/ex ## Dos Tipos de Aislamiento de Pod -Hay dos tipos de aislamiento para un pod: el aislamiento para la salida y el aislamiento para la entrada. Estos se refieren a las conexiones que pueden establecerse. El término "Aislamiento" en el contexto de este documento no es absoluto, sino que significa "se aplican algunas restricciones". La alternativa, "no aislado para $dirección", significa que no se aplican restricciones en la dirección descrita. Los dos tipos de aislamiento (o no) se declaran independientemente, y ambos son relevantes para una conexión de un pod a otro. +Hay dos tipos de aislamiento para un Pod: el aislamiento para la salida y el aislamiento para la entrada. Estos se refieren a las conexiones que pueden establecerse. El término "Aislamiento" en el contexto de este documento no es absoluto, sino que significa "se aplican algunas restricciones". La alternativa, "no aislado para $dirección", significa que no se aplican restricciones en la dirección descrita. Los dos tipos de aislamiento (o no) se declaran independientemente, y ambos son relevantes para una conexión de un Pod a otro. Por defecto, un pod no está aislado para la salida; todas las conexiones salientes están permitidas. Un pod está aislado para la salida si hay alguna NetworkPolicy con "Egress" en su `policyTypes` que seleccione el pod; decimos que tal política se aplica al pod para la salida. Cuando un pod está aislado para la salida, las únicas conexiones permitidas desde el pod son las permitidas por la lista `egress` de las NetworkPolicy que se aplique al pod para la salida. Los valores de esas listas `egress` se combinan de forma aditiva. From 1ac66aed0e1dbbe5b412ba0deeb3bcb6ca25309c Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:17:15 +0200 Subject: [PATCH 06/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 8c25d57a60..95788f8ae5 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -32,7 +32,7 @@ Las políticas de red son implementadas por el [plugin de red](/docs/concepts/ex Hay dos tipos de aislamiento para un Pod: el aislamiento para la salida y el aislamiento para la entrada. Estos se refieren a las conexiones que pueden establecerse. El término "Aislamiento" en el contexto de este documento no es absoluto, sino que significa "se aplican algunas restricciones". La alternativa, "no aislado para $dirección", significa que no se aplican restricciones en la dirección descrita. Los dos tipos de aislamiento (o no) se declaran independientemente, y ambos son relevantes para una conexión de un Pod a otro. -Por defecto, un pod no está aislado para la salida; todas las conexiones salientes están permitidas. Un pod está aislado para la salida si hay alguna NetworkPolicy con "Egress" en su `policyTypes` que seleccione el pod; decimos que tal política se aplica al pod para la salida. Cuando un pod está aislado para la salida, las únicas conexiones permitidas desde el pod son las permitidas por la lista `egress` de las NetworkPolicy que se aplique al pod para la salida. Los valores de esas listas `egress` se combinan de forma aditiva. +Por defecto, un Pod no está aislado para la salida; todas las conexiones salientes están permitidas. Un Pod está aislado para la salida si hay alguna NetworkPolicy con "Egress" en su `policyTypes` que seleccione el Pod; decimos que tal política se aplica al Pod para la salida. Cuando un Pod está aislado para la salida, las únicas conexiones permitidas desde el Pod son las permitidas por la lista `egress` de las NetworkPolicy que se aplique al Pod para la salida. Los valores de esas listas `egress` se combinan de forma aditiva. Por defecto, un pod no está aislado para la entrada; todas las conexiones entrantes están permitidas. Un pod está aislado para la entrada si hay alguna NetworkPolicy con "Ingress" en su `policyTypes` que seleccione el pod; decimos que tal política se aplica al pod para la entrada. Cuando un pod está aislado para la entrada, las únicas conexiones permitidas en el pod son las del nodo del pod y las permitidas por la lista `ingress` de alguna NetworkPolicy que se aplique al pod para la entrada. Los valores de esas listas de direcciones se combinan de forma aditiva. From 0e24924790720b1c2bc467b72ae00c5660ebe59d Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:18:24 +0200 Subject: [PATCH 07/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 95788f8ae5..e0f08dc5ea 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -273,7 +273,7 @@ A día de hoy, en Kubernetes {{< skew currentVersion >}}, la siguiente funcional - Forzar que el tráfico interno del clúster pase por una puerta de enlace común (esto se puede implementar con una malla de servicios u otro proxy). - Cualquier cosa relacionada con TLS (se puede implementar con una malla de servicios o un Ingress controllers para esto). - Políticas específicas de los nodos (se puede utilizar la notación CIDR para esto, pero no se puede apuntar a los nodos por sus identidades Kubernetes específicamente). -- Apuntar a los servicios por su nombre (sin embargo, puede orientar los pods o los espacios de nombres por su {{< glossary_tooltip text="labels" term_id="label" >}}, lo que suele ser una solución viable). +- Apuntar Services por nombre (sin embargo, puede orientar los Pods o los Namespaces por su {{< glossary_tooltip text="labels" term_id="label" >}}, lo que suele ser una solución viable). - Creación o gestión de "solicitudes de políticas" que son atendidas por un tercero. - Políticas que por defecto son aplicadas a todos los espacios de nombres o pods (hay algunas distribuciones y proyectos de Kubernetes de terceros que pueden hacer esto). - Consulta avanzada de políticas y herramientas de accesibilidad. From c6a9eefd9bf8621bf7e30d59219ad199cb24b6dd Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:18:44 +0200 Subject: [PATCH 08/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index e0f08dc5ea..7215ceca64 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -34,7 +34,7 @@ Hay dos tipos de aislamiento para un Pod: el aislamiento para la salida y el ais Por defecto, un Pod no está aislado para la salida; todas las conexiones salientes están permitidas. Un Pod está aislado para la salida si hay alguna NetworkPolicy con "Egress" en su `policyTypes` que seleccione el Pod; decimos que tal política se aplica al Pod para la salida. Cuando un Pod está aislado para la salida, las únicas conexiones permitidas desde el Pod son las permitidas por la lista `egress` de las NetworkPolicy que se aplique al Pod para la salida. Los valores de esas listas `egress` se combinan de forma aditiva. -Por defecto, un pod no está aislado para la entrada; todas las conexiones entrantes están permitidas. Un pod está aislado para la entrada si hay alguna NetworkPolicy con "Ingress" en su `policyTypes` que seleccione el pod; decimos que tal política se aplica al pod para la entrada. Cuando un pod está aislado para la entrada, las únicas conexiones permitidas en el pod son las del nodo del pod y las permitidas por la lista `ingress` de alguna NetworkPolicy que se aplique al pod para la entrada. Los valores de esas listas de direcciones se combinan de forma aditiva. +Por defecto, un Pod no está aislado para la entrada; todas las conexiones entrantes están permitidas. Un Pod está aislado para la entrada si hay alguna NetworkPolicy con "Ingress" en su `policyTypes` que seleccione el Pod; decimos que tal política se aplica al Pod para la entrada. Cuando un Pod está aislado para la entrada, las únicas conexiones permitidas en el Pod son las del nodo del Pod y las permitidas por la lista `ingress` de alguna NetworkPolicy que se aplique al pod para la entrada. Los valores de esas listas de direcciones se combinan de forma aditiva. Las políticas de red no entran en conflicto; son aditivas. Si alguna política o políticas se aplican a un pod para una dirección determinada, las conexiones permitidas en esa dirección desde ese pod es la unión de lo que permiten las políticas aplicables. Por tanto, el orden de evaluación no afecta al resultado de la política. From 2e523e2bed40f5243a19b231a5583350809a79fc Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:19:00 +0200 Subject: [PATCH 09/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 7215ceca64..3c39a24be1 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -275,7 +275,7 @@ A día de hoy, en Kubernetes {{< skew currentVersion >}}, la siguiente funcional - Políticas específicas de los nodos (se puede utilizar la notación CIDR para esto, pero no se puede apuntar a los nodos por sus identidades Kubernetes específicamente). - Apuntar Services por nombre (sin embargo, puede orientar los Pods o los Namespaces por su {{< glossary_tooltip text="labels" term_id="label" >}}, lo que suele ser una solución viable). - Creación o gestión de "solicitudes de políticas" que son atendidas por un tercero. -- Políticas que por defecto son aplicadas a todos los espacios de nombres o pods (hay algunas distribuciones y proyectos de Kubernetes de terceros que pueden hacer esto). +- Políticas que por defecto son aplicadas a todos los Namespaces o Pods (hay algunas distribuciones y proyectos de Kubernetes de terceros que pueden hacer esto). - Consulta avanzada de políticas y herramientas de accesibilidad. - La capacidad de registrar los eventos de seguridad de la red (por ejemplo, las conexiones bloqueadas o aceptadas). - La capacidad de negar explícitamente las políticas (actualmente el modelo para NetworkPolicies es negar por defecto, con sólo la capacidad de añadir reglas de permitir). From 85bdd1824c5a4c8dae3db90782c5672fdce38975 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:19:16 +0200 Subject: [PATCH 10/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 3c39a24be1..336bab6022 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -284,5 +284,5 @@ A día de hoy, en Kubernetes {{< skew currentVersion >}}, la siguiente funcional ## {{% heading "whatsnext" %}} -- Leer el recorrido de como [Declarar de Políticas de Red](/docs/tasks/administer-clúster/declare-network-policy/) para ver más ejemplos. +- Leer el artículo de como [Declarar de Políticas de Red](/docs/tasks/administer-clúster/declare-network-policy/) para ver más ejemplos. - Ver más [recetas](https://github.com/ahmetb/kubernetes-network-policy-recipes) de escenarios comunes habilitados por los recursos de las NetworkPolicy. From 01204d6462df5ecae7b2ec438073b4f1982dac8c Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:20:45 +0200 Subject: [PATCH 11/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 336bab6022..e95800fa61 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -63,7 +63,7 @@ __spec__: NetworkPolicy [spec](https://github.com/kubernetes/community/blob/mast __podSelector__: Cada NetworkPolicy incluye un `podSelector` el cual selecciona el grupo de Pods en los cuales aplica la política. La política de ejemplo selecciona pods con el label "role=db". Un `podSelector` vacío selecciona todos los Pods en un Namespace. -__policyTypes__: Cada NetworkPolicy incluye una lista de `policyTypes` la cual puede incluir `Ingress`, `Egress`, o ambas. Los campos `policyTypes` indican si la política aplica o no aplica al tráfico de entrada hacia el Pod seleccionado, el tráfico de salida desde el Pods seleccionado, o ambos. Si no se especifican `policyTypes` en una NetworkPolicy el valor `Ingress` será siempre aplicado por defecto y `Egress` será aplicado si la NetworkPolicy contiene alguna regla de salida. +__policyTypes__: Cada NetworkPolicy incluye una lista de `policyTypes` la cual puede incluir `Ingress`, `Egress`, o ambas. Los campos `policyTypes` indican si la política aplica o no al tráfico de entrada hacia el Pod seleccionado, el tráfico de salida desde el Pod seleccionado, o ambos. Si no se especifican `policyTypes` en una NetworkPolicy el valor `Ingress` será siempre aplicado por defecto y `Egress` será aplicado si la NetworkPolicy contiene alguna regla de salida. __ingress__: Cada NetworkPolicy puede incluir una lista de reglas `ingress` permitidas. Cada regla permite el tráfico con que se corresponda a ambos valores de las secciones de `from` y `ports`. La política de ejemplo contiene una única regla, la cual se corresponde con el tráfico sobre un solo puerto, desde uno de los tres orígenes definidos, el primero especificado por el valor `ipBlock`, el segundo especificado por el valor `namespaceSelector` y el tercero especificado por el `podSelector`. From 35d04e8e7bc5c9000c5a08a862c69a6cf5f7e6bb Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:21:30 +0200 Subject: [PATCH 12/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index e95800fa61..0f270426e3 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -65,7 +65,7 @@ __podSelector__: Cada NetworkPolicy incluye un `podSelector` el cual selecciona __policyTypes__: Cada NetworkPolicy incluye una lista de `policyTypes` la cual puede incluir `Ingress`, `Egress`, o ambas. Los campos `policyTypes` indican si la política aplica o no al tráfico de entrada hacia el Pod seleccionado, el tráfico de salida desde el Pod seleccionado, o ambos. Si no se especifican `policyTypes` en una NetworkPolicy el valor `Ingress` será siempre aplicado por defecto y `Egress` será aplicado si la NetworkPolicy contiene alguna regla de salida. -__ingress__: Cada NetworkPolicy puede incluir una lista de reglas `ingress` permitidas. Cada regla permite el tráfico con que se corresponda a ambos valores de las secciones de `from` y `ports`. La política de ejemplo contiene una única regla, la cual se corresponde con el tráfico sobre un solo puerto, desde uno de los tres orígenes definidos, el primero especificado por el valor `ipBlock`, el segundo especificado por el valor `namespaceSelector` y el tercero especificado por el `podSelector`. +__ingress__: Cada NetworkPolicy puede incluir una lista de reglas `ingress` permitidas. Cada regla permite el tráfico con que se relaciona a ambos valores de las secciones de `from` y `ports`. La política de ejemplo contiene una única regla, la cual se relaciona con el tráfico sobre un solo puerto, desde uno de los tres orígenes definidos, el primero especificado por el valor `ipBlock`, el segundo especificado por el valor `namespaceSelector` y el tercero especificado por el `podSelector`. __egress__: Cada NetworkPolicy puede incluir una lista de reglas de `egress` permitidas. Cada regla permite el tráfico con que se corresponda a ambos valores de las secciones de `to` and `ports`. La política de ejemplo contiene una única regla, la cual se corresponde con el tráfico en un único puerto para cualquier destino en el rango de IPs `10.0.0.0/24`. From 0134ba9aef49ca8b5b83a6e33012e3db58e04d27 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:22:22 +0200 Subject: [PATCH 13/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 0f270426e3..e61299f17f 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -72,7 +72,7 @@ __egress__: Cada NetworkPolicy puede incluir una lista de reglas de `egress` per Por lo tanto, la NetworkPolicy de ejemplo: 1. Aísla los pods "role=db" en el "default" namespace para ambos tipos de tráfico ingress y egress (si ellos no están aún aislados) -2. (Reglas Ingress) permite la coneccion hacia todos los pods en el "default" namespace con el label "role=db" en el puerto TCP 6379 desde los siguientes orígenes: +2. (Reglas Ingress) permite la conexión hacia todos los Pods en el Namespace "default" con el label "role=db" en el puerto TCP 6379 desde los siguientes orígenes: * cualquier pod en el "default" namespace con el label "role=frontend" * cualquier pod en un namespace con el label "project=myproject" From 5d5dae0e67e280090e463fcae82762db3c8fbaf9 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:24:21 +0200 Subject: [PATCH 14/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index e61299f17f..6464aa874e 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -77,7 +77,7 @@ Por lo tanto, la NetworkPolicy de ejemplo: * cualquier pod en el "default" namespace con el label "role=frontend" * cualquier pod en un namespace con el label "project=myproject" * La dirección IP en los rangos 172.17.0.0–172.17.0.255 y 172.17.2.0–172.17.255.255 (por ejemplo, todo el rango de IPs de 172.17.0.0/16 con excepción del 172.17.1.0/24) -3. (Egress rules) permite coneccion desde cualquier pods en el "default" namespace con el label "role=db" hacia CIDR 10.0.0.0/24 en el puerto TCP 5978 +3. (Egress rules) permite conexión desde cualquier Pod en el Namespace "default" con el label "role=db" hacia CIDR 10.0.0.0/24 en el puerto TCP 5978 Ver el recorrido de [Declarar Network Policy](/docs/tasks/administer-clúster/declare-network-policy/) para más ejemplos. From 64630d9e6dcbc4ea0811141e0d22718f022de2d9 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:24:48 +0200 Subject: [PATCH 15/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 6464aa874e..e38fe92cbe 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -36,7 +36,7 @@ Por defecto, un Pod no está aislado para la salida; todas las conexiones salien Por defecto, un Pod no está aislado para la entrada; todas las conexiones entrantes están permitidas. Un Pod está aislado para la entrada si hay alguna NetworkPolicy con "Ingress" en su `policyTypes` que seleccione el Pod; decimos que tal política se aplica al Pod para la entrada. Cuando un Pod está aislado para la entrada, las únicas conexiones permitidas en el Pod son las del nodo del Pod y las permitidas por la lista `ingress` de alguna NetworkPolicy que se aplique al pod para la entrada. Los valores de esas listas de direcciones se combinan de forma aditiva. -Las políticas de red no entran en conflicto; son aditivas. Si alguna política o políticas se aplican a un pod para una dirección determinada, las conexiones permitidas en esa dirección desde ese pod es la unión de lo que permiten las políticas aplicables. Por tanto, el orden de evaluación no afecta al resultado de la política. +Las políticas de red no entran en conflicto; son aditivas. Si alguna política(s) se aplica a un Pod para una dirección determinada, las conexiones permitidas en esa dirección desde ese Pod es la unión de lo que permiten las políticas aplicables. Por tanto, el orden de evaluación no afecta al resultado de la política. Para que se permita una conexión desde un pod de origen a un pod de destino, tanto la política de salida del pod de origen como la de entrada del pod de destino deben permitir la conexión. Si cualquiera de los dos lados no permite la conexión, ésta no se producirá. From fb0f5538ecdab2fc11087b498b356d3e87313281 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:25:59 +0200 Subject: [PATCH 16/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index e38fe92cbe..b00891a031 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -84,7 +84,7 @@ Ver el recorrido de [Declarar Network Policy](/docs/tasks/administer-clúster/de ## Comportamiento de los selectores `to` y `from` -Existen cuatro tipos de selectores que pueden ser especificados en una sección de `ingress` `from` or en una sección de `egress` `to`: +Existen cuatro tipos de selectores que pueden ser especificados en una sección de `ingress` `from` o en una sección de `egress` `to`: __podSelector__: Este selector selecciona Pods específicos en el mismo espacio de nombres que la NetworkPolicy para permitir el tráfico como fuente de entrada o destino de salida. From 9b64965df5b07e88bc7d2c15210078f2e8691266 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:26:30 +0200 Subject: [PATCH 17/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index b00891a031..da4f5bd34f 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -86,7 +86,7 @@ Ver el recorrido de [Declarar Network Policy](/docs/tasks/administer-clúster/de Existen cuatro tipos de selectores que pueden ser especificados en una sección de `ingress` `from` o en una sección de `egress` `to`: -__podSelector__: Este selector selecciona Pods específicos en el mismo espacio de nombres que la NetworkPolicy para permitir el tráfico como fuente de entrada o destino de salida. +__podSelector__: Este selector selecciona Pods específicos en el mismo Namespace que la NetworkPolicy para permitir el tráfico como origen de entrada o destino de salida. __namespaceSelector__: Este selector selecciona espacios de nombres específicos para permitir el tráfico como fuente de entrada o destino de salida. From f40c943666e82cc9c3c2a0207ee102e47320ef2b Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:27:46 +0200 Subject: [PATCH 18/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index da4f5bd34f..e8f8ff3547 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -121,7 +121,7 @@ contiene un único elemento `from` permitiendo conexiones desde los Pods con el ``` -contiene dos elementos en el array `from`, y permite conecciones desde Pods en el local Namespace con el label `role=client`, *o* desde cualquier Pod en cualquier nombre de espacio con el label `user=alice`. +contiene dos elementos en el array `from`, y permite conexiones desde Pods en el Namespace local con el label `role=client`, *o* desde cualquier Pod en cualquier Namespace con el label `user=alice`. En caso de duda, utilice `kubectl describe` para ver cómo Kubernetes ha interpretado la política. From 03e830908f96d01c07ebb794517628f85c49b614 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:28:16 +0200 Subject: [PATCH 19/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index e8f8ff3547..1440e40b1f 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -88,7 +88,7 @@ Existen cuatro tipos de selectores que pueden ser especificados en una sección __podSelector__: Este selector selecciona Pods específicos en el mismo Namespace que la NetworkPolicy para permitir el tráfico como origen de entrada o destino de salida. -__namespaceSelector__: Este selector selecciona espacios de nombres específicos para permitir el tráfico como fuente de entrada o destino de salida. +__namespaceSelector__: Este selector selecciona Namespaces específicos para permitir el tráfico como origen de entrada o destino de salida. __namespaceSelector__ *y* __podSelector__: Una única entrada `to`/`from` que especifique tanto `namespaceSelector` como `podSelector` selecciona Pods específicos dentro de espacios de nombres específicos. Tenga cuidado de utilizar la sintaxis YAML correcta. A continuación se muestra un ejemplo de esta política: From 4efa38eae2e4a0c411bf465c8f2c2455e4ad9ac4 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:29:07 +0200 Subject: [PATCH 20/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 1440e40b1f..e4384ab139 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -136,7 +136,7 @@ combinaciones de plugin de red, proveedor de nube, implementación de `Service`, En el caso de la entrada, esto significa que en algunos casos se pueden filtrar paquetes entrantes basándose en la IP de origen real, mientras que en otros casos, la "IP de origen" sobre la que actúa la -la NetworkPolicy actúa puede ser la IP de un `LoadBalancer` o la IP de Nodo donde este el Pod involucrado, etc. +la NetworkPolicy actúa puede ser la IP de un `LoadBalancer` o la IP del Nodo donde este el Pod involucrado, etc. Para la salida, esto significa que las conexiones de los pods a las IPs de `Service` que se reescriben a IPs externas al clúster pueden o no estar sujetas a políticas basadas en `ipBlock`. From e67145b6f88a37aac2f2f28c85e10f4acabdf14c Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:30:51 +0200 Subject: [PATCH 21/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index e4384ab139..554c699ddb 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -171,7 +171,7 @@ Puedes crear una política que "por defecto" aisle el tráfico de salida para un {{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}} -Esto asegura que incluso los pods que no son seleccionados por ninguna otra NetworkPolicy no tendrán permitido el tráfico de salida. Esta política no cambia el comportamiento de aislamiento para el tráfico de entrada de ningún pod. +Esto asegura que incluso los Pods que no son seleccionados por ninguna otra NetworkPolicy no tengan permitido el tráfico de salida. Esta política no cambia el comportamiento de aislamiento para el tráfico de entrada de ningún Pod. ### Permitir todo el tráfico de salida From 51b34624a69fa352d0c45051c6e23c86aac0dca3 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:31:40 +0200 Subject: [PATCH 22/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 554c699ddb..97c9787aa3 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -127,7 +127,7 @@ En caso de duda, utilice `kubectl describe` para ver cómo Kubernetes ha interpr -__ipBlock__: Este selector selecciona rangos CIDR de IP específicos para permitirlas como fuentes de entrada o destinos de salida. Estas IPs deben ser externas al clúster, ya que las IPs de Pod son efímeras e impredecibles. +__ipBlock__: Este selector selecciona rangos CIDR de IP específicos para permitirlas como origen de entrada o destino de salida. Estas IPs deben ser externas al clúster, ya que las IPs de Pod son efímeras e impredecibles. Los mecanismos de entrada y salida del clúster a menudo requieren reescribir la IP de origen o destino de los paquetes. En los casos en los que esto ocurre, no está definido si esto ocurre antes o From b566c26791c0eabdb8e001351cb5fa7653e8090e Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:33:00 +0200 Subject: [PATCH 23/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 97c9787aa3..5fc9481d00 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -176,7 +176,7 @@ Esto asegura que incluso los Pods que no son seleccionados por ninguna otra Netw ### Permitir todo el tráfico de salida -Si quieres permitir todas las conexiones desde todos los pods de un espacio de nombres, puede crear una política que permita explícitamente todas las conexiones salientes de los pods de ese espacio de nombres. +Si quieres permitir todas las conexiones desde todos los Pods de un Namespace, puedes crear una política que permita explícitamente todas las conexiones salientes de los Pods de ese Namespace. {{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}} From 7d520bb8cc5d233473e5f3917136752fda5aa086 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:34:58 +0200 Subject: [PATCH 24/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 5fc9481d00..b4d46ca0d6 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -162,7 +162,7 @@ Si tu quieres permitir todo el tráfico de entrada a todos los Pods en un nombre {{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}} -Con esta política en curso, ninguna política o políticas adicionales pueden hacer que se deniegue cualquier conexión entrante a esos pods. Esta política no tiene efecto sobre el aislamiento del tráfico de salida de cualquier pod. +Con esta política en curso, ninguna política(s) adicional puede hacer que se niegue cualquier conexión entrante a esos Pods. Esta política no tiene efecto sobre el aislamiento del tráfico de salida de cualquier Pod. ### Denegar por defecto todo el tráfico de salida From 95ba0520f5e1b064ef5a0961216324ec4c74a67f Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:35:34 +0200 Subject: [PATCH 25/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index b4d46ca0d6..c4c6dde58d 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -79,7 +79,7 @@ Por lo tanto, la NetworkPolicy de ejemplo: * La dirección IP en los rangos 172.17.0.0–172.17.0.255 y 172.17.2.0–172.17.255.255 (por ejemplo, todo el rango de IPs de 172.17.0.0/16 con excepción del 172.17.1.0/24) 3. (Egress rules) permite conexión desde cualquier Pod en el Namespace "default" con el label "role=db" hacia CIDR 10.0.0.0/24 en el puerto TCP 5978 -Ver el recorrido de [Declarar Network Policy](/docs/tasks/administer-clúster/declare-network-policy/) para más ejemplos. +Ver el artículo de [Declarar Network Policy](/docs/tasks/administer-clúster/declare-network-policy/) para más ejemplos. ## Comportamiento de los selectores `to` y `from` From 680992ad6f4accd26d911431ca38755973a39cca Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:36:51 +0200 Subject: [PATCH 26/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index c4c6dde58d..9aafe2869a 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -180,7 +180,7 @@ Si quieres permitir todas las conexiones desde todos los Pods de un Namespace, p {{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}} -Con esta política en vigor, ninguna política o políticas adicionales pueden hacer que se deniegue cualquier conexión de salida desde esos pods. Esta política no tiene efecto sobre el aislamiento para el tráfico de entrada a cualquier pod. +Con esta política en vigor, ninguna política(s) adicional puede hacer que se niegue cualquier conexión de salida desde esos Pods. Esta política no tiene efecto sobre el aislamiento para el tráfico de entrada a cualquier Pod. ### Denegar por defecto todo el tráfico de entrada y de salida From 78392f41dfa653ed435f389b2c8d495accbfc13a Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:42:11 +0200 Subject: [PATCH 27/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 9aafe2869a..579103571c 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -71,7 +71,7 @@ __egress__: Cada NetworkPolicy puede incluir una lista de reglas de `egress` per Por lo tanto, la NetworkPolicy de ejemplo: -1. Aísla los pods "role=db" en el "default" namespace para ambos tipos de tráfico ingress y egress (si ellos no están aún aislados) +1. Aísla los Pods "role=db" en el Namespace "default" para ambos tipos de tráfico ingress y egress (si ellos no están aún aislados) 2. (Reglas Ingress) permite la conexión hacia todos los Pods en el Namespace "default" con el label "role=db" en el puerto TCP 6379 desde los siguientes orígenes: * cualquier pod en el "default" namespace con el label "role=frontend" From 38b1d07f7d929fb48212cd4c57bb2fab3a99d07f Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:42:28 +0200 Subject: [PATCH 28/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 579103571c..37a66e74c7 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -38,7 +38,7 @@ Por defecto, un Pod no está aislado para la entrada; todas las conexiones entra Las políticas de red no entran en conflicto; son aditivas. Si alguna política(s) se aplica a un Pod para una dirección determinada, las conexiones permitidas en esa dirección desde ese Pod es la unión de lo que permiten las políticas aplicables. Por tanto, el orden de evaluación no afecta al resultado de la política. -Para que se permita una conexión desde un pod de origen a un pod de destino, tanto la política de salida del pod de origen como la de entrada del pod de destino deben permitir la conexión. Si cualquiera de los dos lados no permite la conexión, ésta no se producirá. +Para que se permita una conexión desde un Pod de origen a un Pod de destino, tanto la política de salida del Pod de origen como la de entrada del Pod de destino deben permitir la conexión. Si cualquiera de los dos lados no permite la conexión, ésta no se producirá. ## El Recurso NetworkPolicy {#networkpolicy-resource} From 6d0197bcf9296087b53d2f650d7b282355421734 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:43:09 +0200 Subject: [PATCH 29/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 37a66e74c7..81e827bf4c 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -61,7 +61,7 @@ y [Gestión de Objetos](/docs/concepts/overview/working-with-objects/object-mana __spec__: NetworkPolicy [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) contiene toda la información necesaria para definir una política de red dado un Namespace. -__podSelector__: Cada NetworkPolicy incluye un `podSelector` el cual selecciona el grupo de Pods en los cuales aplica la política. La política de ejemplo selecciona pods con el label "role=db". Un `podSelector` vacío selecciona todos los Pods en un Namespace. +__podSelector__: Cada NetworkPolicy incluye un `podSelector` el cual selecciona el grupo de Pods en los cuales aplica la política. La política de ejemplo selecciona Pods con el label "role=db". Un `podSelector` vacío selecciona todos los Pods en un Namespace. __policyTypes__: Cada NetworkPolicy incluye una lista de `policyTypes` la cual puede incluir `Ingress`, `Egress`, o ambas. Los campos `policyTypes` indican si la política aplica o no al tráfico de entrada hacia el Pod seleccionado, el tráfico de salida desde el Pod seleccionado, o ambos. Si no se especifican `policyTypes` en una NetworkPolicy el valor `Ingress` será siempre aplicado por defecto y `Egress` será aplicado si la NetworkPolicy contiene alguna regla de salida. From 31159a341b47f5d12b7ed4b5318a445dfae101c7 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:44:11 +0200 Subject: [PATCH 30/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 81e827bf4c..315738a3e4 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -74,7 +74,7 @@ Por lo tanto, la NetworkPolicy de ejemplo: 1. Aísla los Pods "role=db" en el Namespace "default" para ambos tipos de tráfico ingress y egress (si ellos no están aún aislados) 2. (Reglas Ingress) permite la conexión hacia todos los Pods en el Namespace "default" con el label "role=db" en el puerto TCP 6379 desde los siguientes orígenes: - * cualquier pod en el "default" namespace con el label "role=frontend" + * cualquier Pod en el Namespace "default" con el label "role=frontend" * cualquier pod en un namespace con el label "project=myproject" * La dirección IP en los rangos 172.17.0.0–172.17.0.255 y 172.17.2.0–172.17.255.255 (por ejemplo, todo el rango de IPs de 172.17.0.0/16 con excepción del 172.17.1.0/24) 3. (Egress rules) permite conexión desde cualquier Pod en el Namespace "default" con el label "role=db" hacia CIDR 10.0.0.0/24 en el puerto TCP 5978 From 7ce0ae7152f606f592d210f87eb42cb9e9f2324a Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:44:31 +0200 Subject: [PATCH 31/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 315738a3e4..f95d0a8a4b 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -75,7 +75,7 @@ Por lo tanto, la NetworkPolicy de ejemplo: 2. (Reglas Ingress) permite la conexión hacia todos los Pods en el Namespace "default" con el label "role=db" en el puerto TCP 6379 desde los siguientes orígenes: * cualquier Pod en el Namespace "default" con el label "role=frontend" - * cualquier pod en un namespace con el label "project=myproject" + * cualquier Pod en un Namespace con el label "project=myproject" * La dirección IP en los rangos 172.17.0.0–172.17.0.255 y 172.17.2.0–172.17.255.255 (por ejemplo, todo el rango de IPs de 172.17.0.0/16 con excepción del 172.17.1.0/24) 3. (Egress rules) permite conexión desde cualquier Pod en el Namespace "default" con el label "role=db" hacia CIDR 10.0.0.0/24 en el puerto TCP 5978 From 27ad98afd101a38b7ce00292f2579e99a23189e8 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:45:17 +0200 Subject: [PATCH 32/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index f95d0a8a4b..f53c891e25 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -138,7 +138,7 @@ En el caso de la entrada, esto significa que en algunos casos se pueden filtrar entrantes basándose en la IP de origen real, mientras que en otros casos, la "IP de origen" sobre la que actúa la la NetworkPolicy actúa puede ser la IP de un `LoadBalancer` o la IP del Nodo donde este el Pod involucrado, etc. -Para la salida, esto significa que las conexiones de los pods a las IPs de `Service` que se reescriben a +Para la salida, esto significa que las conexiones de los Pods a las IPs de `Service` que se reescriben a IPs externas al clúster pueden o no estar sujetas a políticas basadas en `ipBlock`. From 938c217d9b261be3e3ff0f3834bddf8247f10901 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:45:49 +0200 Subject: [PATCH 33/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index f53c891e25..9dd34a40bb 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -144,7 +144,7 @@ IPs externas al clúster pueden o no estar sujetas a políticas basadas en `ipBl ## Políticas por defecto -Por defecto, si no existen políticas en un espacio de nombres, se permite todo el tráfico de entrada y salida hacia y desde los pods de ese espacio de nombres. Los siguientes ejemplos muestran cómo cambiar el comportamiento por defecto en ese espacio de nombres. +Por defecto, si no existen políticas en un Namespace, se permite todo el tráfico de entrada y salida hacia y desde los Pods de ese Namespace. Los siguientes ejemplos muestran cómo cambiar el comportamiento por defecto en ese Namespace. ### Denegar todo el tráfico de entrada por defecto From 4bd3daba8b9d6b476218c4adfead67067cbb5e2b Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:46:22 +0200 Subject: [PATCH 34/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 9dd34a40bb..8de6a5ddb0 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -153,7 +153,7 @@ Puedes crear una política que "por defecto" aisle a un espacio de nombres del t {{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}} -Esto asegura que incluso los Pods que no están seleccionados por ninguna otra NetworkPolicy también serán aislados del tráfico de entrada. Esta política no afecta el aislamiento en el tráfico de salida desde cualquier Pods. +Esto asegura que incluso los Pods que no están seleccionados por ninguna otra NetworkPolicy también serán aislados del tráfico de entrada. Esta política no afecta el aislamiento en el tráfico de salida desde cualquier Pod. ### Permitir todo el tráfico de entrada From 3b2482c2f65fbbbc26e23cb1dca29909cfc09a7d Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:47:08 +0200 Subject: [PATCH 35/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 8de6a5ddb0..0fd91e6c86 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -149,7 +149,7 @@ Por defecto, si no existen políticas en un Namespace, se permite todo el tráfi ### Denegar todo el tráfico de entrada por defecto -Puedes crear una política que "por defecto" aisle a un espacio de nombres del tráfico de entrada con la creación de una política que seleccione todos los Pods del espacio de nombres pero no permite ningún tráfico de entrada en esos Pods. +Puedes crear una política que "por defecto" aisle a un Namespace del tráfico de entrada con la creación de una política que seleccione todos los Pods del Namespace pero no permite ningún tráfico de entrada en esos Pods. {{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}} From 5d96e59d5304760da83cb109895fb5d8b7b002ce Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:47:31 +0200 Subject: [PATCH 36/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 0fd91e6c86..aacd00890d 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -158,7 +158,7 @@ Esto asegura que incluso los Pods que no están seleccionados por ninguna otra N ### Permitir todo el tráfico de entrada -Si tu quieres permitir todo el tráfico de entrada a todos los Pods en un nombre de espacio, puedes crear una política que explícitamente permita eso. +Si tu quieres permitir todo el tráfico de entrada a todos los Pods en un Namespace, puedes crear una política que explícitamente permita eso. {{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}} From 46b47e3ebc2fcd56db9792407656a39bfe02b351 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:47:56 +0200 Subject: [PATCH 37/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index aacd00890d..4cb1d4aca0 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -167,7 +167,7 @@ Con esta política en curso, ninguna política(s) adicional puede hacer que se n ### Denegar por defecto todo el tráfico de salida -Puedes crear una política que "por defecto" aisle el tráfico de salida para un espacio de nombres, creando una NetworkPolicy que seleccione todos los pods pero que no permita ningún tráfico de salida desde esos pods. +Puedes crear una política que "por defecto" aisle el tráfico de salida para un Namespace, creando una NetworkPolicy que seleccione todos los Pods pero que no permita ningún tráfico de salida desde esos Pods. {{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}} From f6cf8b4f77b877122be8563cdb27de7700bccc91 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:48:18 +0200 Subject: [PATCH 38/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 4cb1d4aca0..af0118d6ca 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -189,7 +189,7 @@ Puede crear una política que "por defecto" en un espacio de nombres impida todo {{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}} -Esto asegura que incluso los pods que no son seleccionados por ninguna otra NetworkPolicy no tendrán permitido el tráfico de entrada o salida. +Esto asegura que incluso los Pods que no son seleccionados por ninguna otra NetworkPolicy no tendrán permitido el tráfico de entrada o salida. ## Soporte a SCTP From 1e46bdc9d5dbf4f4f9d24a3a5862f930139f2116 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:48:46 +0200 Subject: [PATCH 39/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index af0118d6ca..355da76afe 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -185,7 +185,7 @@ Con esta política en vigor, ninguna política(s) adicional puede hacer que se n ### Denegar por defecto todo el tráfico de entrada y de salida -Puede crear una política que "por defecto" en un espacio de nombres impida todo el tráfico de entrada Y de salida creando la siguiente NetworkPolicy en ese espacio de nombres. +Puede crear una política que "por defecto" en un Namespace impida todo el tráfico de entrada y de salida creando la siguiente NetworkPolicy en ese Namespace. {{< codenew file="service/networking/network-policy-default-deny-all.yaml" >}} From d219ca29c712e40c5777707ebdc974aa54ca5e29 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:49:27 +0200 Subject: [PATCH 40/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 355da76afe..64775db737 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -234,7 +234,7 @@ spec: endPort: 32768 ``` -La regla anterior permite que cualquier Pod con la etiqueta `role=db` en el espacio de nombres `default` se comunique +La regla anterior permite que cualquier Pod con la etiqueta `role=db` en el Namespace `default` se comunique con cualquier IP dentro del rango `10.0.0.0/24` sobre el protocolo TCP, siempre que el puerto esté entre el rango 32000 y 32768. From 804b3caaf221868d961dcf9c637264d3025371dc Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:49:55 +0200 Subject: [PATCH 41/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 64775db737..9dee3b9f18 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -260,7 +260,7 @@ la política se aplicará sólo para el campo `port`. {{< feature-state for_k8s_version="1.22" state="stable" >}} El plano de control de Kubernetes establece una etiqueta inmutable `kubernetes.io/metadata.name` en todos los -espacios de nombre, siempre que se haya habilitado la [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `NamespaceDefaultLabelName`. +Namespaces, siempre que se haya habilitado la [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `NamespaceDefaultLabelName`. El valor de la etiqueta es el nombre del espacio de nombres. Aunque NetworkPolicy no puede apuntar a un espacio de nombres por su nombre con algún campo de objeto, puede utilizar la etiqueta estandarizada para apuntar a un espacio de nombres específico. From ed8b5429c87b97005ef64fc5f507436c30e17d26 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:50:31 +0200 Subject: [PATCH 42/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 9dee3b9f18..947902d204 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -261,7 +261,7 @@ la política se aplicará sólo para el campo `port`. El plano de control de Kubernetes establece una etiqueta inmutable `kubernetes.io/metadata.name` en todos los Namespaces, siempre que se haya habilitado la [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `NamespaceDefaultLabelName`. -El valor de la etiqueta es el nombre del espacio de nombres. +El valor de la etiqueta es el nombre del Namespace. Aunque NetworkPolicy no puede apuntar a un espacio de nombres por su nombre con algún campo de objeto, puede utilizar la etiqueta estandarizada para apuntar a un espacio de nombres específico. From be874782223b5b40a92ff79208fbf21418361792 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:51:09 +0200 Subject: [PATCH 43/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 947902d204..095884108e 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -263,7 +263,7 @@ El plano de control de Kubernetes establece una etiqueta inmutable `kubernetes.i Namespaces, siempre que se haya habilitado la [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `NamespaceDefaultLabelName`. El valor de la etiqueta es el nombre del Namespace. -Aunque NetworkPolicy no puede apuntar a un espacio de nombres por su nombre con algún campo de objeto, puede utilizar la etiqueta estandarizada para apuntar a un espacio de nombres específico. +Aunque NetworkPolicy no puede apuntar a un Namespace por su nombre con algún campo de objeto, puede utilizar la etiqueta estandarizada para apuntar a un Namespace específico. ## Que no puedes hacer con políticas de red (al menos, no aún) From 266854267ac22117962934f79166c5a02f1040a4 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:53:19 +0200 Subject: [PATCH 44/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 095884108e..17484bbb22 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -266,7 +266,7 @@ El valor de la etiqueta es el nombre del Namespace. Aunque NetworkPolicy no puede apuntar a un Namespace por su nombre con algún campo de objeto, puede utilizar la etiqueta estandarizada para apuntar a un Namespace específico. - ## Que no puedes hacer con políticas de red (al menos, no aún) + ## Que no puedes hacer con políticas de red (al menos, aún no) A día de hoy, en Kubernetes {{< skew currentVersion >}}, la siguiente funcionalidad no existe en la API de NetworkPolicy, pero es posible que se puedan implementar soluciones mediante componentes del sistema operativo (como SELinux, OpenVSwitch, IPTables, etc.) o tecnologías de capa 7 (Ingress controllers, implementaciones de Service Mesh) o controladores de admisión. En caso de que seas nuevo en la seguridad de la red en Kubernetes, vale la pena señalar que las siguientes historias de usuario no pueden (todavía) ser implementadas usando la API NetworkPolicy. From a7afa631cd620bd01f8d2fe1c58a37e65a91c91f Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 18:55:28 +0200 Subject: [PATCH 45/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 17484bbb22..c1dddc6df4 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -90,7 +90,7 @@ __podSelector__: Este selector selecciona Pods específicos en el mismo Namespac __namespaceSelector__: Este selector selecciona Namespaces específicos para permitir el tráfico como origen de entrada o destino de salida. -__namespaceSelector__ *y* __podSelector__: Una única entrada `to`/`from` que especifique tanto `namespaceSelector` como `podSelector` selecciona Pods específicos dentro de espacios de nombres específicos. Tenga cuidado de utilizar la sintaxis YAML correcta. A continuación se muestra un ejemplo de esta política: +__namespaceSelector__ *y* __podSelector__: Una única entrada `to`/`from` que especifique tanto `namespaceSelector` como `podSelector` selecciona Pods específicos dentro de Namespaces específicos. Tenga cuidado de utilizar la sintaxis de YAML correcta. A continuación se muestra un ejemplo de esta política: ```yaml ... From 40248cff25f6818dfb0698d655f01ab804113c4c Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 12 Jul 2022 19:02:02 +0200 Subject: [PATCH 46/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index c1dddc6df4..e62e39217e 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -67,7 +67,7 @@ __policyTypes__: Cada NetworkPolicy incluye una lista de `policyTypes` la cual p __ingress__: Cada NetworkPolicy puede incluir una lista de reglas `ingress` permitidas. Cada regla permite el tráfico con que se relaciona a ambos valores de las secciones de `from` y `ports`. La política de ejemplo contiene una única regla, la cual se relaciona con el tráfico sobre un solo puerto, desde uno de los tres orígenes definidos, el primero especificado por el valor `ipBlock`, el segundo especificado por el valor `namespaceSelector` y el tercero especificado por el `podSelector`. -__egress__: Cada NetworkPolicy puede incluir una lista de reglas de `egress` permitidas. Cada regla permite el tráfico con que se corresponda a ambos valores de las secciones de `to` and `ports`. La política de ejemplo contiene una única regla, la cual se corresponde con el tráfico en un único puerto para cualquier destino en el rango de IPs `10.0.0.0/24`. +__egress__: Cada NetworkPolicy puede incluir una lista de reglas de `egress` permitidas. Cada regla permite el tráfico con que se relaciona a ambos valores de las secciones de `to` and `ports`. La política de ejemplo contiene una única regla, la cual se relaciona con el tráfico en un único puerto para cualquier destino en el rango de IPs `10.0.0.0/24`. Por lo tanto, la NetworkPolicy de ejemplo: From 4802e0f14aa8d1a8e3bf2e5fef27f34b711b2147 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 19 Jul 2022 19:06:16 +0200 Subject: [PATCH 47/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index e62e39217e..6c17c3eace 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -25,7 +25,7 @@ Por otro lado, cuando se crean NetworkPolicies basadas en IP, se definen políti ## Prerrequisitos -Las políticas de red son implementadas por el [plugin de red](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). Para usar políticas de red, debes estar utilizando una solución de red que soporte NetworkPolicy. Crear un recurso NetworkPolicy sin un controlador que lo habilite no tendrá ningún efecto. +Las políticas de red son implementadas por el [plugin de red](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). Para usar políticas de red, debes estar utilizando una solución de red que soporte NetworkPolicy. Crear un recurso NetworkPolicy sin un controlador que lo habilite no tendrá efecto alguno. ## Dos Tipos de Aislamiento de Pod From 08267eaae67003f93d41f9c208d6fa73fa63c106 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 19 Jul 2022 19:06:28 +0200 Subject: [PATCH 48/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 6c17c3eace..25c9a47b82 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -268,7 +268,7 @@ Aunque NetworkPolicy no puede apuntar a un Namespace por su nombre con algún ca ## Que no puedes hacer con políticas de red (al menos, aún no) -A día de hoy, en Kubernetes {{< skew currentVersion >}}, la siguiente funcionalidad no existe en la API de NetworkPolicy, pero es posible que se puedan implementar soluciones mediante componentes del sistema operativo (como SELinux, OpenVSwitch, IPTables, etc.) o tecnologías de capa 7 (Ingress controllers, implementaciones de Service Mesh) o controladores de admisión. En caso de que seas nuevo en la seguridad de la red en Kubernetes, vale la pena señalar que las siguientes historias de usuario no pueden (todavía) ser implementadas usando la API NetworkPolicy. +Actualmente, en Kubernetes {{< skew currentVersion >}}, la siguiente funcionalidad no existe en la API de NetworkPolicy, pero es posible que se puedan implementar soluciones mediante componentes del sistema operativo (como SELinux, OpenVSwitch, IPTables, etc.) o tecnologías de capa 7 (Ingress controllers, implementaciones de Service Mesh) o controladores de admisión. En caso de que seas nuevo en la seguridad de la red en Kubernetes, vale la pena señalar que las siguientes historias de usuario no pueden (todavía) ser implementadas usando la API NetworkPolicy. - Forzar que el tráfico interno del clúster pase por una puerta de enlace común (esto se puede implementar con una malla de servicios u otro proxy). - Cualquier cosa relacionada con TLS (se puede implementar con una malla de servicios o un Ingress controllers para esto). From c96718f2ee7b5d419a9126127ec0605aeb69b3ee Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 19 Jul 2022 19:07:37 +0200 Subject: [PATCH 49/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 25c9a47b82..5071fc9f20 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -55,7 +55,7 @@ Enviar esto al API Server de su clúster no tendrá ningún efecto a menos que s __Campos Obligatorios__: Como con todos los otras configuraciones de Kubernetes, una NetworkPolicy necesita los campos `apiVersion`, `kind`, y `metadata`. Para obtener información general -sobre cómo funcionan esos ficheros de configuración, mirar +sobre cómo funcionan esos ficheros de configuración, puedes consultar [Configurar un Pod para usar un ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/), y [Gestión de Objetos](/docs/concepts/overview/working-with-objects/object-management). From cef90828d9260a6ccc3c129fade28858abd63377 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 19 Jul 2022 19:11:03 +0200 Subject: [PATCH 50/52] Fix type Signed-off-by: Nicolas Quiceno B --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index 5071fc9f20..f7c20dceed 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -34,7 +34,7 @@ Hay dos tipos de aislamiento para un Pod: el aislamiento para la salida y el ais Por defecto, un Pod no está aislado para la salida; todas las conexiones salientes están permitidas. Un Pod está aislado para la salida si hay alguna NetworkPolicy con "Egress" en su `policyTypes` que seleccione el Pod; decimos que tal política se aplica al Pod para la salida. Cuando un Pod está aislado para la salida, las únicas conexiones permitidas desde el Pod son las permitidas por la lista `egress` de las NetworkPolicy que se aplique al Pod para la salida. Los valores de esas listas `egress` se combinan de forma aditiva. -Por defecto, un Pod no está aislado para la entrada; todas las conexiones entrantes están permitidas. Un Pod está aislado para la entrada si hay alguna NetworkPolicy con "Ingress" en su `policyTypes` que seleccione el Pod; decimos que tal política se aplica al Pod para la entrada. Cuando un Pod está aislado para la entrada, las únicas conexiones permitidas en el Pod son las del nodo del Pod y las permitidas por la lista `ingress` de alguna NetworkPolicy que se aplique al pod para la entrada. Los valores de esas listas de direcciones se combinan de forma aditiva. +Por defecto, un Pod no está aislado para la entrada; todas las conexiones entrantes están permitidas. Un Pod está aislado para la entrada si hay alguna NetworkPolicy con "Ingress" en su `policyTypes` que seleccione el Pod; decimos que tal política se aplica al Pod para la entrada. Cuando un Pod está aislado para la entrada, las únicas conexiones permitidas en el Pod son las del nodo del Pod y las permitidas por la lista `ingress` de alguna NetworkPolicy que se aplique al Pod para la entrada. Los valores de esas listas de direcciones se combinan de forma aditiva. Las políticas de red no entran en conflicto; son aditivas. Si alguna política(s) se aplica a un Pod para una dirección determinada, las conexiones permitidas en esa dirección desde ese Pod es la unión de lo que permiten las políticas aplicables. Por tanto, el orden de evaluación no afecta al resultado de la política. From edeadf50a31287627da398f6b29516a191f798c2 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 19 Jul 2022 20:32:56 +0200 Subject: [PATCH 51/52] Update content/es/docs/concepts/services-networking/network-policies.md Co-authored-by: Victor Morales --- .../es/docs/concepts/services-networking/network-policies.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index f7c20dceed..ab0a752e0b 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -105,7 +105,7 @@ __namespaceSelector__ *y* __podSelector__: Una única entrada `to`/`from` que es ... ``` -contiene un único elemento `from` permitiendo conexiones desde los Pods con el label `role=client` en nombres de espacio con el label `user=alice`. Por el contrario, *esta* política: +contiene un elemento `from` permitiendo conexiones desde los Pods con el label `role=client` en Namespaces con el label `user=alice`. Por el contrario, *esta* política: ```yaml ... From 4d565e7e054175a8a9e9871085a4ba15d8f89743 Mon Sep 17 00:00:00 2001 From: Nicolas Quiceno B Date: Tue, 19 Jul 2022 20:37:35 +0200 Subject: [PATCH 52/52] Improve text localization Signed-off-by: Nicolas Quiceno B --- .../docs/concepts/services-networking/network-policies.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/content/es/docs/concepts/services-networking/network-policies.md b/content/es/docs/concepts/services-networking/network-policies.md index ab0a752e0b..09f65765a4 100644 --- a/content/es/docs/concepts/services-networking/network-policies.md +++ b/content/es/docs/concepts/services-networking/network-policies.md @@ -50,7 +50,7 @@ Un ejemplo de NetworkPolicy pudiera ser este: {{< codenew file="service/networking/networkpolicy.yaml" >}} {{< note >}} -Enviar esto al API Server de su clúster no tendrá ningún efecto a menos que su solución de red tenga soporte de políticas de red. +Enviar esto al API Server de su clúster no tendrá ningún efecto a menos que su solución de red soporte de políticas de red. {{< /note >}} __Campos Obligatorios__: Como con todos los otras configuraciones de Kubernetes, una NetworkPolicy @@ -90,7 +90,7 @@ __podSelector__: Este selector selecciona Pods específicos en el mismo Namespac __namespaceSelector__: Este selector selecciona Namespaces específicos para permitir el tráfico como origen de entrada o destino de salida. -__namespaceSelector__ *y* __podSelector__: Una única entrada `to`/`from` que especifique tanto `namespaceSelector` como `podSelector` selecciona Pods específicos dentro de Namespaces específicos. Tenga cuidado de utilizar la sintaxis de YAML correcta. A continuación se muestra un ejemplo de esta política: +__namespaceSelector__ *y* __podSelector__: Una única entrada `to`/`from` que especifica tanto `namespaceSelector` como `podSelector` selecciona Pods específicos dentro de Namespaces específicos. Es importante revisar que se utiliza la sintaxis de YAML correcta. A continuación se muestra un ejemplo de esta política: ```yaml ... @@ -120,8 +120,7 @@ contiene un elemento `from` permitiendo conexiones desde los Pods con el label ` ... ``` - -contiene dos elementos en el array `from`, y permite conexiones desde Pods en el Namespace local con el label `role=client`, *o* desde cualquier Pod en cualquier Namespace con el label `user=alice`. +contiene dos elementos en el array `from`, y permite conexiones desde Pods en los Namespaces con el label `role=client`, *o* desde cualquier Pod en cualquier Namespace con el label `user=alice`. En caso de duda, utilice `kubectl describe` para ver cómo Kubernetes ha interpretado la política.