[ES] Issue #16684: pendings translations to Spanish (Split PR 4) (#16743)

* Add Spanish translation for security and traffic management tasks (files 109-130)

Signed-off-by: Francisco Herrera <fjglira@gmail.com>

* Apply suggestions from code review

Co-authored-by: Josune Cordoba <49480155+josunect@users.noreply.github.com>

* Update content/es/docs/tasks/traffic-management/ingress/gateway-api/index.md

Co-authored-by: Josune Cordoba <49480155+josunect@users.noreply.github.com>

---------

Signed-off-by: Francisco Herrera <fjglira@gmail.com>
Co-authored-by: Josune Cordoba <49480155+josunect@users.noreply.github.com>

Author: fjglira

content/es/docs/tasks/security/authentication/authn-policy/index.md

@@ -117,9 +117,9 @@ $ kubectl exec "$(kubectl get pod -l app=curl -n foo -o jsonpath={.items..metada
 ## Habilitar globalmente mTLS de Istio en modo STRICT
 
 Aunque Istio actualiza automáticamente todo el tráfico entre los proxies y los workloads a mTLS,
-los workloads aún pueden recibir tráfico de texto plano. Para evitar el tráfico no mTLS para toda la malla,
-establezca una política de autenticación de pares a nivel de malla con el modo mTLS establecido en `STRICT`.
-La política de autenticación de pares a nivel de malla no debe tener un `selector` y debe aplicarse en el **namespace raíz**, por ejemplo:
+los workloads aún pueden recibir tráfico de texto plano. Para evitar el tráfico no mTLS para toda la mesh,
+establezca una política de autenticación de pares a nivel de mesh con el modo mTLS establecido en `STRICT`.
+La política de autenticación de pares a nivel de mesh no debe tener un `selector` y debe aplicarse en el **namespace raíz**, por ejemplo:
 
 {{< text bash >}}
 $ kubectl apply -f - <<EOF
@@ -139,7 +139,7 @@ El ejemplo asume que `istio-system` es el namespace raíz. Si usó un valor dife
  {{< /tip >}}
 
 Esta política de autenticación de pares configura los workloads para que solo acepten solicitudes cifradas con TLS.
-Dado que no especifica un valor para el campo `selector`, la política se aplica a todos los workloads de la malla.
+Dado que no especifica un valor para el campo `selector`, la política se aplica a todos los workloads de la mesh.
 
 Ejecute el comando de prueba de nuevo:
 

content/es/docs/tasks/security/authentication/mtls-migration/index.md

@@ -129,7 +129,7 @@ Si no puede migrar todos sus services a Istio (es decir, inyectar el sidecar de
 Sin embargo, cuando se configura con el modo `PERMISSIVE`, no se realizarán comprobaciones de autenticación o autorización para el tráfico de texto plano por defecto.
 Le recomendamos que utilice la [Autorización de Istio](/es/docs/tasks/security/authorization/authz-http/) para configurar diferentes rutas con diferentes políticas de autorización.
 
-## Bloquear mTLS para toda la malla
+## Bloquear mTLS para toda la mesh
 
 Puede bloquear los workloads en todos los namespaces para que solo acepten tráfico mTLS colocando la política en el namespace del sistema de su instalación de Istio.
 

content/es/docs/tasks/security/authorization/authz-custom/index.md

@@ -46,7 +46,7 @@ La sobrecarga de caché y propagación puede causar algún retraso.
 
 ## Desplegar el autorizador externo
 
-Primero, debe desplegar el autorizador externo. Para ello, simplemente desplegará el autorizador externo de ejemplo en un pod independiente en la malla.
+Primero, debe desplegar el autorizador externo. Para ello, simplemente desplegará el autorizador externo de ejemplo en un pod independiente en la mesh.
 
 1. Ejecute el siguiente comando para desplegar el autorizador externo de ejemplo:
 
@@ -65,8 +65,8 @@ Primero, debe desplegar el autorizador externo. Para ello, simplemente desplegar
     {{< /text >}}
 
 Alternativamente, también puede desplegar el autorizador externo como un contenedor separado en el mismo pod de la aplicación
-que necesita la autorización externa o incluso desplegarlo fuera de la malla. En cualquier caso, también deberá crear un
-recurso de entrada de service para registrar el service en la malla y asegurarse de que sea accesible para el proxy.
+que necesita la autorización externa o incluso desplegarlo fuera de la mesh. En cualquier caso, también deberá crear un
+recurso de entrada de service para registrar el service en la mesh y asegurarse de que sea accesible para el proxy.
 
 El siguiente es un ejemplo de entrada de service para un autorizador externo desplegado en un contenedor separado en el mismo pod
 de la aplicación que necesita la autorización externa.
@@ -78,29 +78,29 @@ metadata:
   name: external-authz-grpc-local
 spec:
   hosts:
-  - "external-authz-grpc.local" # El nombre del service a usar en el proveedor de extensión en la configuración de la malla.
+  - "external-authz-grpc.local" # El nombre del service a usar en el proveedor de extensión en la configuración de la mesh.
   endpoints:
   - address: "127.0.0.1"
   ports:
   - name: grpc
-    number: 9191 # El número de puerto a usar en el proveedor de extensión en la configuración de la malla.
+    number: 9191 # El número de puerto a usar en el proveedor de extensión en la configuración de la mesh.
     protocol: GRPC
   resolution: STATIC
 {{< /text >}}
 
 ## Definir el autorizador externo
 
 Para utilizar la acción `CUSTOM` en la política de autorización, debe definir el autorizador externo que está permitido
-utilizar en la malla. Esto se define actualmente en el [proveedor de extensión](https://github.com/istio/api/blob/a205c627e4b955302bbb77dd837c8548e89e6e64/mesh/v1alpha1/config.proto#L534)
-en la configuración de la malla.
+utilizar en la mesh. Esto se define actualmente en el [proveedor de extensión](https://github.com/istio/api/blob/a205c627e4b955302bbb77dd837c8548e89e6e64/mesh/v1alpha1/config.proto#L534)
+en la configuración de la mesh.
 
 Actualmente, el único tipo de proveedor de extensión compatible es el proveedor [Envoy `ext_authz`](https://www.envoyproxy.io/docs/envoy/v1.16.2/intro/arch_overview/security/ext_authz_filter).
 El autorizador externo debe implementar la API de verificación `ext_authz` de Envoy correspondiente.
 
 En esta tarea, utilizará un [autorizador externo de ejemplo]({{< github_tree >}}/samples/extauthz) que
 permite solicitudes con la cabecera `x-ext-authz: allow`.
 
-1. Edite la configuración de la malla con el siguiente comando:
+1. Edite la configuración de la mesh con el siguiente comando:
 
     {{< text bash >}}
     $ kubectl edit configmap istio -n istio-system
@@ -168,7 +168,7 @@ El autorizador externo ya está listo para ser utilizado por la política de aut
           app: httpbin
       action: CUSTOM
       provider:
-        # El nombre del proveedor debe coincidir con el proveedor de extensión definido en la configuración de la malla.
+        # El nombre del proveedor debe coincidir con el proveedor de extensión definido en la configuración de la mesh.
         # También puede reemplazar esto con sample-ext-authz-http para probar la otra definición de autorizador externo.
         name: sample-ext-authz-grpc
       rules:
@@ -230,7 +230,7 @@ El autorizador externo ya está listo para ser utilizado por la política de aut
     $ kubectl delete namespace foo
     {{< /text >}}
 
-1. Elimine la definición del proveedor de extensión de la configuración de la malla.
+1. Elimine la definición del proveedor de extensión de la configuración de la mesh.
 
 ## Expectativas de rendimiento
 

content/es/docs/tasks/security/authorization/authz-deny/index.md

@@ -7,7 +7,7 @@ owner: istio/wg-security-maintainers
 test: yes
 ---
 
-Esta tarea muestra cómo configurar la política de autorización de Istio de acción `DENY` para denegar explícitamente el tráfico en una malla de Istio.
+Esta tarea muestra cómo configurar la política de autorización de Istio de acción `DENY` para denegar explícitamente el tráfico en un mesh de Istio.
 Esto es diferente de la acción `ALLOW` porque la acción `DENY` tiene mayor prioridad y no será
 eludida por ninguna acción `ALLOW`.
 

content/es/docs/tasks/security/authorization/authz-http/index.md

@@ -10,7 +10,7 @@ owner: istio/wg-security-maintainers
 test: yes
 ---
 
-Esta tarea muestra cómo configurar la política de autorización de Istio de acción `ALLOW` para el tráfico HTTP en una malla de Istio.
+Esta tarea muestra cómo configurar la política de autorización de Istio de acción `ALLOW` para el tráfico HTTP en un mesh de Istio.
 
 ## Antes de empezar
 
@@ -69,7 +69,7 @@ y luego otorgue más acceso al workload de forma gradual e incremental.
     Apunte su navegador a la `productpage` de Bookinfo (`http://$GATEWAY_URL/productpage`).
     Debería ver `"RBAC: acceso denegado"`. El error muestra que la política `deny-all` configurada
     está funcionando como se esperaba, y Istio no tiene ninguna regla que permita ningún acceso a
-    los workloads en la malla.
+    los workloads en la mesh.
 
 1. Ejecute el siguiente comando para crear una política `productpage-viewer` para permitir el acceso
    con el método `GET` al workload `productpage`. La política no establece el campo `from`

content/es/docs/tasks/security/authorization/authz-tcp/index.md

@@ -9,7 +9,7 @@ owner: istio/wg-security-maintainers
 test: no
 ---
 
-Esta tarea muestra cómo configurar la política de autorización de Istio para el tráfico TCP en una malla de Istio.
+Esta tarea muestra cómo configurar la política de autorización de Istio para el tráfico TCP en un mesh de Istio.
 
 ## Antes de empezar
 

content/es/docs/tasks/security/authorization/authz-td-migration/index.md

@@ -10,9 +10,9 @@ test: yes
 Esta tarea muestra cómo migrar de un trust domain a otro sin cambiar la política de autorización.
 
 En Istio 1.4, introducimos una feature alfa para soportar la {{< gloss >}}trust domain migration{{</ gloss >}} para la política de autorización. Esto significa que si una
-malla de Istio necesita cambiar su {{< gloss >}}trust domain{{</ gloss >}}, la política de autorización no necesita ser cambiada manualmente.
+mesh de Istio necesita cambiar su {{< gloss >}}trust domain{{</ gloss >}}, la política de autorización no necesita ser cambiada manualmente.
 En Istio, si un {{< gloss >}}workload{{</ gloss >}} se está ejecutando en el namespace `foo` con la cuenta de service `bar`, y el trust domain del sistema es `my-td`,
-la identidad de dicho workload es `spiffe://my-td/ns/foo/sa/bar`. Por defecto, el trust domain de la malla de Istio es `cluster.local`,
+la identidad de dicho workload es `spiffe://my-td/ns/foo/sa/bar`. Por defecto, el trust domain de la mesh de Istio es `cluster.local`,
 a menos que lo especifique durante la instalación.
 
 ## Antes de empezar
@@ -97,7 +97,7 @@ Antes de comenzar esta tarea, haga lo siguiente:
     $ kubectl rollout restart deployment -n istio-system istiod
     {{< /text >}}
 
-    La malla de Istio ahora se está ejecutando con un nuevo trust domain, `new-td`.
+    la mesh de Istio ahora se está ejecutando con un nuevo trust domain, `new-td`.
 
 1. Vuelva a desplegar las applications `httpbin` y `curl` para que recojan los cambios del nuevo control plane de Istio.
 
@@ -165,7 +165,7 @@ Antes de comenzar esta tarea, haga lo siguiente:
 
 A partir de Istio 1.4, al escribir la política de autorización, debe considerar usar el valor `cluster.local` como la
 parte del trust domain en la política. Por ejemplo, en lugar de `old-td/ns/curl-allow/sa/curl`, debería ser `cluster.local/ns/curl-allow/sa/curl`.
-Tenga en cuenta que en este caso, `cluster.local` no es el trust domain de la malla de Istio (el trust domain sigue siendo `old-td`). Sin embargo,
+Tenga en cuenta que en este caso, `cluster.local` no es el trust domain de la mesh de Istio (el trust domain sigue siendo `old-td`). Sin embargo,
 en la política de autorización, `cluster.local` es un puntero que apunta al trust domain actual, es decir, `old-td` (y más tarde `new-td`), así como a sus alias.
 Al usar `cluster.local` en la política de autorización, cuando migre a un nuevo trust domain, Istio detectará esto y tratará el nuevo trust domain
 como el antiguo trust domain sin que tenga que incluir los alias.

content/es/docs/tasks/security/cert-management/plugin-ca-cert/index.md

@@ -18,7 +18,7 @@ y utilizar la CA raíz para emitir certificados intermedios a las CA de Istio qu
 Una CA de Istio puede firmar certificados de workloads utilizando el certificado y la clave especificados por el administrador, y distribuir un
 certificado raíz especificado por el administrador a los workloads como la raíz de confianza.
 
-El siguiente gráfico demuestra la jerarquía de CA recomendada en una malla que contiene dos clusters.
+El siguiente gráfico demuestra la jerarquía de CA recomendada en un mesh que contiene dos clusters.
 
 {{< image width="50%"
     link="ca-hierarchy.svg"

content/es/docs/tasks/traffic-management/circuit-breaking/index.md

@@ -10,7 +10,7 @@ test: yes
 Esta tarea muestra cómo configurar el interruptor de circuito para conexiones, solicitudes
 y detección de valores atípicos.
 
-el interruptor de circuito es un patrón importante para crear applications de microservices resilientes.
+el interruptor de circuito es un patrón importante para crear applications de microservicios resilientes.
 el interruptor de circuito le permite escribir applications que limitan el impacto de fallos, picos de latencia y otros efectos indeseables de las peculiaridades de la red.
 
 En esta tarea, configurará las reglas de interruptor de circuito y luego probará la

content/es/docs/tasks/traffic-management/egress/egress-control/index.md

@@ -1,6 +1,6 @@
 ---
 title: Acceso a Services Externos
-description: Describe cómo configurar Istio para enrutar el tráfico de services en la malla a services externos.
+description: Describe cómo configurar Istio para enrutar el tráfico de services en la mesh a servicios externos.
 weight: 10
 aliases:
     - /docs/tasks/egress.html
@@ -18,7 +18,7 @@ un control más estricto suele ser preferible.
 
 Esta tarea le muestra cómo acceder a services externos de tres maneras diferentes:
 
-1. Permitir que el proxy Envoy pase las solicitudes a services que no están configurados dentro de la malla.
+1. Permitir que el proxy Envoy pase las solicitudes a services que no están configurados dentro de la mesh.
 1. Configurar [entradas de service](/es/docs/reference/config/networking/service-entry/) para proporcionar acceso controlado a services externos.
 1. Omitir completamente el proxy Envoy para un rango específico de IPs.
 
@@ -60,7 +60,7 @@ Istio tiene una [opción de instalación](/es/docs/reference/config/istio.mesh.v
 de services externos, es decir, aquellos services que no están definidos en el service registry interno de Istio.
 Si esta opción se establece en `ALLOW_ANY`, el proxy de Istio permite que las llamadas a services desconocidos pasen.
 Si la opción se establece en `REGISTRY_ONLY`, el proxy de Istio bloquea cualquier host sin un service HTTP o
-una entrada de service definida dentro de la malla.
+una entrada de service definida dentro de la mesh.
 `ALLOW_ANY` es el valor predeterminado, lo que le permite comenzar a evaluar Istio rápidamente,
 sin controlar el acceso a services externos.
 Luego puede decidir [configurar el acceso a services externos](#controlled-access-to-external-services) más tarde.
@@ -97,11 +97,11 @@ Luego puede decidir [configurar el acceso a services externos](#controlled-acces
     HTTP/2 200
     {{< /text >}}
 
-¡Felicidades! Ha enviado tráfico de salida desde su malla con éxito.
+¡Felicidades! Ha enviado tráfico de salida desde su mesh con éxito.
 
 Este enfoque simple para acceder a services externos tiene el inconveniente de que se pierde el monitoreo y control de Istio
-para el tráfico a services externos. La siguiente sección le muestra cómo monitorear y controlar el acceso de su malla a
-services externos.
+para el tráfico a services externos. La siguiente sección le muestra cómo monitorear y controlar el acceso de su mesh a
+servicios externos.
 
 ## Acceso controlado a services externos
 
@@ -163,7 +163,7 @@ cualquier otro acceso no intencional.
     accediendo a `httpbin.org` estableciéndolo en la cabecera `HOST`, mientras que en realidad se conecta a una IP diferente
     (que no está asociada con `httpbin.org`). El proxy sidecar de Istio confiará en la cabecera HOST, y permitirá incorrectamente
     el tráfico, aunque se esté entregando a la dirección IP de un host diferente. Ese host puede ser un sitio malicioso,
-    o un sitio legítimo, prohibido por las políticas de seguridad de la malla.
+    o un sitio legítimo, prohibido por las políticas de seguridad de la mesh.
 
     Con la resolución `DNS`, el proxy sidecar ignorará la dirección IP de destino original y dirigirá el tráfico
     a `httpbin.org`, realizando una consulta DNS para obtener una dirección IP de `httpbin.org`.
@@ -548,17 +548,17 @@ $ istioctl install <flags-you-used-to-install-Istio>
 
 ## Comprender lo que sucedió
 
-En esta tarea, examinó tres formas de llamar a services externos desde una malla de Istio:
+En esta tarea, examinó tres formas de llamar a services externos desde un mesh de Istio:
 
 1. Configurar Envoy para permitir el acceso a cualquier service externo.
 
-1. Usar una entrada de service para registrar un service externo accesible dentro de la malla. Este es el
+1. Usar una entrada de service para registrar un service externo accesible dentro de la mesh. Este es el
    enfoque recomendado.
 
 1. Configurar el sidecar de Istio para excluir IPs externas de su tabla de IPs remapeadas.
 
 El primer enfoque dirige el tráfico a través del proxy sidecar de Istio, incluidas las llamadas a services
-desconocidos dentro de la malla. Al usar este enfoque,
+desconocidos dentro de la mesh. Al usar este enfoque,
 no puede monitorear el acceso a services externos ni aprovechar las features de control de tráfico de Istio para ellos.
 Para cambiar fácilmente al segundo enfoque para services específicos, simplemente cree entradas de service para esos services externos.
 Este proceso le permite acceder inicialmente a cualquier service externo y luego