Anthos Service Mesh 1.9 llegó al final del ciclo de vida y ya no es compatible. Consulta Actualiza desde versiones anteriores.

Consulta la documentación más reciente o selecciona otra versión disponible:

Versiones disponibles

1.20 (más reciente)
1.19
1.18
1.17
1.16
1.15
1.14
1.13
1.12
1.11
1.10
1.9
1.8
1.7
1.6
1.5
1.4

Usa las puertas de enlace de salida de Anthos Service Mesh en los clústeres de GKE: Instructivo

En este instructivo, se muestra cómo usar las puertas de enlace de salida de Anthos Service Mesh y otros controles de Google Cloud para proteger el tráfico saliente (salida) de las cargas de trabajo implementadas en un clúster de Google Kubernetes Engine. El instructivo está diseñó como un complemento de la guía de prácticas recomendadas.

El público previsto para este instructivo incluye ingenieros de redes, seguridad y plataforma que administran los clústeres de Google Kubernetes Engine que usan uno o más equipos de entrega de software. Los controles que se describen aquí son especialmente útiles para las organizaciones que deben demostrar el cumplimiento de las regulaciones (por ejemplo, GDPR y PCI).

Objetivos

Configura la infraestructura para ejecutar Anthos Service Mesh:
- Red de VPC personalizada y subred privada
- Cloud NAT para el acceso a Internet
- Clúster de GKE privado con un grupo de nodos adicional para Pods de puerta de enlace de salida
- Reglas de firewall de VPC de salida restringidas; solo los nodos de la puerta de enlace pueden llegar a hosts externos
- Acceso privado a Google para conectarte a Container Registry y a las API de Google
Instala Anthos Service Mesh con puertas de enlace de salida que se ejecutan en un grupo de nodos dedicado
Configura reglas de enrutamiento de varios usuarios para tráfico externo a través de la puerta de enlace de salida:
- Las aplicaciones en el espacio de nombres “team-x” se pueden conectar a example.com
- Las aplicaciones del espacio de nombres “team-y” se pueden conectar a httpbin.org
Usa el recurso Sidecar a fin de restringir el alcance de la configuración de salida del proxy de sidecar para cada espacio de nombres.
Configura políticas de autorización para aplicar reglas de salida.
Configura la puerta de enlace de salida para actualizar solicitudes HTTP simples a TLS (TLS de origen).
Configura la puerta de enlace de salida para pasar por el tráfico de TLS.
Configura las políticas de red de Kubernetes como un control de salida adicional.
Configura el acceso directo a las API de Google con permisos de Identity and Access Management (IAM) y Acceso privado a Google.

Costos

En este documento, usarás los siguientes componentes facturables de Google Cloud:

Para generar una estimación de costos en función del uso previsto, usa la calculadora de precios. Es posible que los usuarios nuevos de Google Cloud califiquen para obtener una prueba gratuita.

Cuando completes el instructivo puedes borrar los recursos que hayas creado para evitar que se te sigan cobrando. Para obtener más información, consulta Realiza una limpieza.

Antes de comenzar

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector
Asegúrate de que la facturación esté habilitada para tu proyecto de Google Cloud.
In the Google Cloud console, activate Cloud Shell.

Activate Cloud Shell
Crea un directorio de trabajo para usar mientras sigues el instructivo:
```
mkdir -p ~/WORKING_DIRECTORY
cd ~/WORKING_DIRECTORY
```
Crea una secuencia de comandos de shell a fin de inicializar tu entorno para el instructivo. Reemplaza y edita las variables según tu proyecto y tus preferencias. Ejecuta esta secuencia de comandos con el comando source para reinicializar tu entorno si se vence la sesión de shell:
```
cat << 'EOF' > ./init-egress-tutorial.sh
#! /usr/bin/env bash
PROJECT_ID=YOUR_PROJECT_ID
REGION=REGION
ZONE=ZONE

gcloud config set project ${PROJECT_ID}
gcloud config set compute/region ${REGION}
gcloud config set compute/zone ${ZONE}

EOF
```
Haz que la secuencia de comandos sea ejecutable y ejecútala con el comando source para inicializar tu entorno:
```
chmod +x ./init-egress-tutorial.sh
source ./init-egress-tutorial.sh
```

Configura las funciones de administración de identidades y accesos (IAM) requeridas. Si eres el propietario del proyecto, tienes todos los permisos necesarios para completar la instalación. Si no eres propietario del proyecto, pídele a tu administrador que te otorgue las siguientes funciones de IAM. En el siguiente comando, cambia PROJECT_EMAIL_ADDRESS por la cuenta que usas para acceder a Google Cloud.

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member user:PROJECT_EMAIL_ADDRESS \
    --role=roles/editor \
    --role=roles/compute.admin \
    --role=roles/container.admin \
    --role=roles/resourcemanager.projectIamAdmin \
    --role=roles/iam.serviceAccountAdmin \
    --role=roles/iam.serviceAccountKeyAdmin \
    --role=roles/gkehub.admin \
    --role=roles/serviceusage.serviceUsageAdmin

Habilita las API necesarias para el instructivo:

gcloud services enable \
    dns.googleapis.com \
    container.googleapis.com \
    compute.googleapis.com \
    monitoring.googleapis.com \
    logging.googleapis.com \
    cloudtrace.googleapis.com \
    meshca.googleapis.com \
    meshtelemetry.googleapis.com \
    meshconfig.googleapis.com \
    iamcredentials.googleapis.com \
    gkeconnect.googleapis.com \
    gkehub.googleapis.com \
    cloudresourcemanager.googleapis.com \
    stackdriver.googleapis.com

Habilitar las API puede tomar un minuto o más en completarse. Cuando las API están habilitadas, ves un resultado similar al siguiente:

Operation "operations/acf.601db672-88e6-4f98-8ceb-aa3b5725533c" finished
successfully.

Configurar la infraestructura

Crea una red y subred de VPC

Crea una red de VPC nueva:

gcloud compute networks create vpc-network \
    --subnet-mode custom

Crea una subred para que el clúster se ejecute en ella con rangos de direcciones IP secundarios asignados previamente para los Pods y los servicios. El Acceso privado a Google está habilitado para que las aplicaciones con solo direcciones IP internas puedan alcanzar los servicios y las API de Google:
```
gcloud compute networks subnets create subnet-gke \
    --network vpc-network \
    --range 10.0.0.0/24 \
    --secondary-range pods=10.1.0.0/16,services=10.2.0.0/20 \
    --enable-private-ip-google-access
```

Configura Cloud NAT

Cloud NAT permite que las cargas de trabajo sin direcciones IP externas se conecten a destinos en Internet y reciban respuestas entrantes de esos destinos.

Crea un Cloud Router:

gcloud compute routers create nat-router \
    --network vpc-network

Agrega una configuración de NAT al router:

gcloud compute routers nats create nat-config \
    --router nat-router \
    --nat-all-subnet-ip-ranges \
    --auto-allocate-nat-external-ips

Crea cuentas de servicio para cada grupo de nodos de GKE

Crea dos cuentas de servicio para que la usen los dos grupos de nodos de GKE. Se asigna una cuenta de servicio independiente a cada grupo de nodos para que puedas aplicar reglas de firewall de VPC a nodos específicos.

Crea una cuenta de servicio para que la usen los nodos en el grupo de nodos predeterminado:

gcloud iam service-accounts create sa-application-nodes \
    --description="SA for application nodes" \
    --display-name="sa-application-nodes"

Crea una cuenta de servicio para que la usen los nodos en el grupo de nodos de puerta de enlace:

gcloud iam service-accounts create sa-gateway-nodes \
    --description="SA for gateway nodes" \
    --display-name="sa-gateway-nodes"

Otorga permisos a las cuentas de servicio

Agrega un conjunto mínimo de funciones de IAM a las cuentas de servicio de la aplicación y de la puerta de enlace. Estas funciones son necesarias para registrar, supervisar y extraer imágenes de contenedores privadas de Container Registry.

    project_roles=(
        roles/logging.logWriter
        roles/monitoring.metricWriter
        roles/monitoring.viewer
        roles/storage.objectViewer
    )
    for role in "${project_roles[@]}"
    do
        gcloud projects add-iam-policy-binding ${PROJECT_ID} \
            --member="serviceAccount:sa-application-nodes@${PROJECT_ID}.iam.gserviceaccount.com" \
            --role="$role"
        gcloud projects add-iam-policy-binding ${PROJECT_ID} \
            --member="serviceAccount:sa-gateway-nodes@${PROJECT_ID}.iam.gserviceaccount.com" \
            --role="$role"
    done

Cómo crear las reglas de firewall

En los pasos siguientes, aplica una regla de firewall a la red de VPC para que, de forma predeterminada, se deniegue todo el tráfico de salida. Se requiere conectividad específica para que el clúster funcione y que los nodos de puerta de enlace puedan llegar a destinos fuera de la VPC. Un conjunto mínimo de reglas de firewall específicas anulan la regla predeterminada para denegar todo para permitir la conectividad necesaria.

Crea una regla de firewall predeterminada (de baja prioridad) para denegar toda la salida desde la red de VPC:

gcloud compute firewall-rules create global-deny-egress-all \
    --action DENY \
    --direction EGRESS \
    --rules all \
    --destination-ranges 0.0.0.0/0 \
    --network vpc-network \
    --priority 65535 \
    --description "Default rule to deny all egress from the network."

Crea una regla para permitir que solo los nodos con la cuenta de servicio de la puerta de enlace lleguen a Internet:

gcloud compute firewall-rules create gateway-allow-egress-web \
    --action ALLOW \
    --direction EGRESS \
    --rules tcp:80,tcp:443 \
    --target-service-accounts sa-gateway-nodes@${PROJECT_ID}.iam.gserviceaccount.com \
    --network vpc-network \
    --priority 1000 \
    --description "Allow the nodes running the egress gateways to connect to the web"

Permite que los nodos lleguen al plano de control de Kubernetes:

gcloud compute firewall-rules create allow-egress-to-api-server \
    --action ALLOW \
    --direction EGRESS \
    --rules tcp:443,tcp:10250 \
    --destination-ranges 10.5.0.0/28 \
    --network vpc-network \
    --priority 1000 \
    --description "Allow nodes to reach the Kubernetes API server."

Anthos Service Mesh usa webhooks cuando se inyectan proxies de sidecar en las cargas de trabajo. Permite que el servidor de la API de GKE llame a los webhooks expuestos por el plano de control de la malla de servicios que se ejecuta en los nodos:

gcloud compute firewall-rules create allow-ingress-api-server-to-webhook \
    --action ALLOW \
    --direction INGRESS \
    --rules tcp:15017 \
    --source-ranges 10.5.0.0/28 \
    --network vpc-network \
    --priority 1000 \
    --description "Allow the API server to call the webhooks exposed by istiod discovery"

Permite la conectividad de salida entre Pods y servicios que se ejecutan en el clúster. Ten en cuenta que GKE crea de forma automática una regla de entrada correspondiente.

gcloud compute firewall-rules create allow-egress-pods-and-services \
    --action ALLOW \
    --direction EGRESS \
    --rules all \
    --destination-ranges 10.1.0.0/16,10.2.0.0/20 \
    --network vpc-network \
    --priority 1000 \
    --description "Allow pods and services on nodes to reach each other"

Un servicio llamado Calico proporciona la funcionalidad de la API NetworkPolicy para GKE. Permite la conectividad para Calico dentro de la subred:

gcloud compute firewall-rules create allow-egress-calico \
    --action ALLOW \
    --direction EGRESS \
    --rules tcp:5473 \
    --destination-ranges 10.0.0.0/24 \
    --network vpc-network \
    --priority 1000 \
    --description "Allow Calico Typha within the subnet"

El puerto de solo lectura de kubelet es necesario para que GKE lea las métricas de los nodos. Permite el acceso a él dentro de la subred:

gcloud compute firewall-rules create allow-egress-kubelet-readonly \
    --action ALLOW \
    --direction EGRESS \
    --rules tcp:10255 \
    --destination-ranges 10.0.0.0/24 \
    --network vpc-network \
    --priority 1000 \
    --description "Allow access to the kubelet read-only port within the subnet"

Permite el acceso a los conjuntos reservados de direcciones IP que usa el Acceso privado a Google para entregar las API de Google, Container Registry y otros servicios:

gcloud compute firewall-rules create allow-egress-gcp-apis \
    --action ALLOW \
    --direction EGRESS \
    --rules tcp \
    --destination-ranges 199.36.153.8/30 \
    --network vpc-network \
    --priority 1000 \
    --description "Allow access to the VIPs used by Google Cloud APIs (Private Google Access)"

Permite que el servicio de verificador de estado de Google Cloud acceda a los Pods que se ejecutan en el clúster:

gcloud compute firewall-rules create allow-ingress-gcp-health-checker \
    --action ALLOW \
    --direction INGRESS \
    --rules tcp:80,tcp:443 \
    --source-ranges 130.211.0.0/22,35.191.0.0/16,35.191.0.0/16,209.85.152.0/22,209.85.204.0/22 \
    --network vpc-network \
    --priority 1000 \
    --description "Allow workloads to respond to Google Cloud health checks"

Configura el acceso privado a las API de Google Cloud

El Acceso privado a Google permite que las VM y los Pods que solo tienen direcciones IP internas tengan acceso a las API y los servicios de Google. Aunque las API y los servicios de Google se entregan desde IP externas, el tráfico de los nodos nunca sale de la red de Google cuando se usa el Acceso privado a Google.

Crea una zona de DNS privado y registros “CNAME” y “A” para que los nodos y las cargas de trabajo puedan conectarse a los servicios y las API de Google mediante el Acceso privado a Google y el nombre de host “private.googleapis.com”:

gcloud dns managed-zones create private-google-apis \
    --description "Private DNS zone for Google APIs" \
    --dns-name googleapis.com \
    --visibility private \
    --networks vpc-network

gcloud dns record-sets transaction start --zone private-google-apis

gcloud dns record-sets transaction add private.googleapis.com. \
    --name *.googleapis.com \
    --ttl 300 \
    --type CNAME \
    --zone private-google-apis

gcloud dns record-sets transaction add "199.36.153.8" \
"199.36.153.9" "199.36.153.10" "199.36.153.11" \
    --name private.googleapis.com \
    --ttl 300 \
    --type A \
    --zone private-google-apis

gcloud dns record-sets transaction execute --zone private-google-apis

Configura el acceso privado a Container Registry

Crea una zona de DNS privado y registros “CNAME” y “A” para que los nodos se puedan conectar a Container Registry mediante el Acceso privado a Google y el nombre de host “gcr.io”.

gcloud dns managed-zones create private-gcr-io \
    --description "private zone for Container Registry" \
    --dns-name gcr.io \
    --visibility private \
    --networks vpc-network

gcloud dns record-sets transaction start --zone private-gcr-io

gcloud dns record-sets transaction add gcr.io. \
    --name *.gcr.io \
    --ttl 300 \
    --type CNAME \
    --zone private-gcr-io

gcloud dns record-sets transaction add "199.36.153.8" "199.36.153.9" "199.36.153.10" "199.36.153.11" \
    --name gcr.io \
    --ttl 300 \
    --type A \
    --zone private-gcr-io

gcloud dns record-sets transaction execute --zone private-gcr-io

Crea un clúster de GKE privado

Busca la dirección IP externa de Cloud Shell para que puedas agregarla a la lista de redes que tienen acceso al servidor de la API de tu clúster:
```
SHELL_IP=$(dig TXT -4 +short @ns1.google.com o-o.myaddr.l.google.com)
```
Después de un período de inactividad, la dirección IP externa de la VM de Cloud Shell puede cambiar. Si eso sucede, debes actualizar la lista de redes autorizadas de tu clúster. Agrega el siguiente comando a la secuencia de comandos de inicialización:
```
cat << 'EOF' >> ./init-egress-tutorial.sh
SHELL_IP=$(dig TXT -4 +short @ns1.google.com o-o.myaddr.l.google.com)
gcloud container clusters update cluster1 \
    --enable-master-authorized-networks \
    --master-authorized-networks ${SHELL_IP//\"}/32
EOF
```
Crea un clúster de GKE privado:
```
gcloud container clusters create cluster1 \
    --enable-ip-alias \
    --enable-private-nodes \
    --release-channel "regular" \
    --no-enable-basic-auth \
    --no-issue-client-certificate \
    --enable-master-authorized-networks \
    --master-authorized-networks ${SHELL_IP//\"}/32 \
    --master-ipv4-cidr 10.5.0.0/28 \
    --enable-network-policy \
    --service-account "sa-application-nodes@${PROJECT_ID}.iam.gserviceaccount.com" \
    --machine-type "e2-standard-4" \
    --num-nodes "4" \
    --network "vpc-network" \
    --subnetwork "subnet-gke" \
    --cluster-secondary-range-name "pods" \
    --services-secondary-range-name "services" \
    --workload-pool "${PROJECT_ID}.svc.id.goog" \
    --zone ${ZONE}
```
El clúster tarda unos minutos en crearse. El clúster tiene nodos privados con direcciones IP internas. A los pods y los servicios se les asignan IP de los rangos secundarios con nombre que definiste cuando creaste la subred de VPC.

Anthos Service Mesh requiere que los nodos del clúster usen un tipo de máquina que tenga por lo menos 4 CPU virtuales. Google recomienda que el clúster esté suscrito al canal de versiones "normales" para garantizar que los nodos ejecuten una versión de Kubernetes compatible con Anthos Service Mesh. Para obtener más información, consulta las guías de instalación de Anthos Service Mesh.

Workload Identity está habilitada en el clúster. Anthos Service Mesh requiere Workload Identity y es la forma recomendada de acceder a las API de Google desde cargas de trabajo de GKE.
Crea un grupo de nodos llamado gateway. Este grupo de nodos es donde se implementa la puerta de enlace de salida. El taint dedicated=gateway:NoSchedule se agrega a cada nodo en el grupo de nodos de puerta de enlace.
```
gcloud container node-pools create "gateway" \
    --cluster "cluster1" \
    --machine-type "e2-standard-4" \
    --node-taints dedicated=gateway:NoSchedule \
    --service-account "sa-gateway-nodes@${PROJECT_ID}.iam.gserviceaccount.com" \
    --num-nodes "1"
```
Los taints y las tolerancias de Kubernetes ayudan a garantizar que solo los Pods de puerta de enlace de salida se ejecuten en nodos del grupo de nodos de puerta de enlace.
Descarga credenciales para que puedas conectarte al clúster con kubectl:
```
gcloud container clusters get-credentials cluster1
```

Verifica que los nodos de puerta de enlace tengan el taint correcto:

kubectl get nodes -l cloud.google.com/gke-nodepool=gateway -o yaml \
-o=custom-columns='name:metadata.name,taints:spec.taints[?(@.key=="dedicated")]'

El resultado es similar al siguiente:

name                                 taints
gke-cluster1-gateway-9d65b410-cffs   map[effect:NoSchedule key:dedicated value:gateway]

Instala y configura Anthos Service Mesh

En este instructivo, se usan funciones opcionales de Anthos Service Mesh. Para obtener información sobre cómo instalar Anthos Service Mesh con una secuencia de comandos, lee la guía de instalación en la documentación.

Crea espacios de nombres para el plano de control y la puerta de enlace de salida de la malla de servicios que se implementarán en:
```
kubectl create ns istio-system
kubectl create ns istio-egress
```
Etiqueta los espacios de nombres istio-egress, istio-system y kube-system:
```
kubectl label ns istio-egress istio=egress istio-injection=disabled
kubectl label ns istio-system istio=system
kubectl label ns kube-system kube-system=true
```
Estas etiquetas se usan más adelante para aplicar Kubernetes NetworkPolicy. La etiqueta istio-injection=disabled evita advertencias falsas cuando ejecutas el análisis istioctl.
Crea un archivo de manifiesto para personalizar la instalación de Anthos Service Mesh con Istio OperatorAPI:
```
cat << 'EOF' > ./asm-custom-install.yaml
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  name: "egress-gateway"
spec:
  meshConfig:
    accessLogFile: "/dev/stdout"
  components:
    egressGateways:
      - name: "istio-egressgateway"
        enabled: true
        namespace: "istio-egress"
        label:
          istio: "egress"
        k8s:
          tolerations:
          - key: "dedicated"
            operator: "Equal"
            value: "gateway"
          nodeSelector:
            cloud.google.com/gke-nodepool: "gateway"
EOF
```
Este archivo se proporciona como un argumento para la secuencia de comandos de instalación y especifica la siguiente configuración:
- Una implementación de puerta de enlace de salida que se ejecuta en el espacio de nombres istio-egress con una tolerancia y nodeSelector para que solo se ejecute en nodos de gateway.
- Registro de acceso a “stdout” para todos los proxies de sidecar.
Precaución: Asegúrate de que solo los administradores de red puedan aplicar la tolerancia de la puerta de enlace a los Pods. El uso no autorizado de la tolerancia de la puerta de enlace permite que los pods implementados actúen para actuar en nombre de la puerta de enlace y se ejecuten en los nodos de puerta de enlace. Los Pods que se ejecutan en nodos de puerta de enlace pueden conectarse directamente a hosts externos. Restringe el uso de la tolerancia de la puerta de enlace como parte de las canalizaciones de implementación o mediante el control de admisión de Kubernetes. Se puede usar una restricción de GKE Enterprise Policy Controller en ambas situaciones.

Descarga la secuencia de comandos de instalación:

curl -O https://storage.googleapis.com/csm-artifacts/asm/install_asm

Descarga la firma de SHA-256 del archivo en el directorio de trabajo de trabajo:
```
curl -O https://storage.googleapis.com/csm-artifacts/asm/install_asm.sha256
```
Verifica la descarga con ambos archivos en el mismo directorio:
```
sha256sum -c --ignore-missing install_asm.sha256
```
Si la verificación se realiza correctamente, el resultado será el siguiente:
```
install_asm: OK
```
Para mayor compatibilidad, el archivo install_asm.sha256 incluye la suma de verificación dos veces a fin de permitir que cualquier versión de la secuencia de comandos cambie su nombre a install_asm. Si recibes un error que indica que --ignore-missing no existe, vuelve a ejecutar el comando anterior sin la marca --ignore-missing.
Haz que la secuencia de comandos sea ejecutable:
```
chmod +x install_asm
```

Ejecuta la siguiente secuencia de comandos para instalar Anthos Service Mesh:

./install_asm \
    --mode install \
    --project_id ${PROJECT_ID} \
    --cluster_name cluster1 \
    --cluster_location ${ZONE} \
    --custom_overlay ./asm-custom-install.yaml \
    --output_dir ./ \
    --enable_all

Cuando se complete la secuencia de comandos, configura una variable de entorno para conservar la ruta de acceso a la herramienta de istioctl y agrégala a tu secuencia de comandos de inicialización:
```
ISTIOCTL=$(find "$(pwd -P)" -name istioctl)
echo "ISTIOCTL=\"${ISTIOCTL}\"" >> ./init-egress-tutorial.sh
```

Verifica la instalación de Anthos Service Mesh

Comprueba que los componentes del plano de control de Anthos Service Mesh se ejecuten en el espacio de nombres istio-system:
```
kubectl get pod -n istio-system
```
Verás los pods istio-ingressgateway y istiod-asm en ejecución.
Verifica que los pods de puerta de enlace de salida se ejecuten en el espacio de nombres istio-egress y en los nodos del grupo de nodos gateway:
```
kubectl get pods -n istio-egress -o wide
```

Los Pods de puerta de enlace de salida tienen un nodeSelector para seleccionar nodos en el grupo de nodos de gateway y una tolerancia que les permite ejecutarse en los nodos de puerta de enlace con taints. Examina el nodeSelector y las tolerancias para los Pods de puerta de enlace de salida:

kubectl -n istio-egress get pod -l app=istio-egressgateway \
    -o=custom-columns='name:metadata.name,nodeSelector:spec.nodeSelector,\
    tolerations:spec.tolerations[?(@.key=="dedicated")]'

El resultado es similar al siguiente:

name                                   nodeSelector                                 tolerations
istio-egressgateway-74687946f5-dg9mp   map[cloud.google.com/gke-nodepool:gateway]   map[key:dedicated operator:Equal value:gateway]

Prepara la malla y una aplicación de prueba

Asegúrate de que la TLS mutua STRICT esté habilitada. Aplica una política de PeerAuthentication predeterminada para la malla en el espacio de nombres istio-system:
```
cat <<EOF | kubectl apply -f -
apiVersion: "security.istio.io/v1beta1"
kind: "PeerAuthentication"
metadata:
  name: "default"
  namespace: "istio-system"
spec:
  mtls:
    mode: STRICT
EOF
```
Puedes anular esta configuración creando recursos de PeerAuthentication en espacios de nombres específicos.
Crea espacios de nombres para usar en la implementación de cargas de trabajo de prueba. En los pasos posteriores de este instructivo, se explica cómo configurar diferentes reglas de enrutamiento de salida para cada espacio de nombres.
```
kubectl create namespace team-x
kubectl create namespace team-y
```
Etiqueta los espacios de nombres para que las políticas de red de Kubernetes puedan seleccionarlos:
```
kubectl label namespace team-x team=x
kubectl label namespace team-y team=y
```
Para que Anthos Service Mesh inserte de forma automática sidecars de proxy, debes configurar una etiqueta de revisión en los espacios de nombres de la carga de trabajo. La etiqueta de revisión debe coincidir con la revisión del plano de control de Anthos Service Mesh que se implementó en tu clúster. Busca la etiqueta de revisión en el Pod istiod y almacénala en una variable de entorno:
```
REVISION_LABEL=$(kubectl get pod -n istio-system -l app=istiod \
  -o jsonpath='{.items[0].metadata.labels.istio\.io/rev}')
```

Configura la etiqueta de revisión en los espacios de nombres team-x y team-y:

kubectl label ns team-x istio.io/rev=${REVISION_LABEL}
kubectl label ns team-y istio.io/rev=${REVISION_LABEL}

Crea un archivo YAML para usarlo en la implementación de pruebas:

cat << 'EOF' > ./test.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: test
---
apiVersion: v1
kind: Service
metadata:
  name: test
  labels:
    app: test
spec:
  ports:
  - port: 80
    name: http
  selector:
    app: test
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
    spec:
      serviceAccountName: test
      containers:
      - name: test
        image: gcr.io/google.com/cloudsdktool/cloud-sdk:slim
        command: ["/bin/sleep", "infinity"]
        imagePullPolicy: IfNotPresent
EOF

Implementa la aplicación de prueba en el espacio de nombres team-x:
```
kubectl -n team-x create -f ./test.yaml
```
Verifica que la aplicación de prueba se implemente en un nodo en el grupo predeterminado y que se inserte un contenedor de sidecar del proxy. Repite el siguiente comando hasta que el estado del Pod sea Running:
```
kubectl -n team-x get po -l app=test -o wide
```
El resultado es similar al siguiente:
```
NAME                   READY   STATUS    RESTARTS   AGE   IP          NODE                                      NOMINATED NODE   READINESS GATES
test-d5bdf6f4f-9nxfv   2/2     Running   0          19h   10.1.1.25   gke-cluster1-default-pool-f6c7a51f-wbzj
```
2 de 2 contenedores son Running. Un contenedor es la aplicación de prueba y el otro es el sidecar del proxy.

El Pod se ejecuta en un nodo en el grupo de nodos predeterminado.
Verifica que no sea posible realizar una solicitud HTTP desde el contenedor de prueba a un sitio externo:
```
kubectl -n team-x exec -it \
    $(kubectl -n team-x get pod -l app=test -o jsonpath={.items..metadata.name}) \
    -c test -- curl -v http://example.com
```
Se genera un mensaje de error del proxy de sidecar porque la regla de firewall "global-deny-egress-all" deniega la conexión ascendente.

Usa el recurso de sidecar para restringir el alcance de la configuración del proxy de sidecar

Puedes usar el recurso de sidecar a fin de restringir el alcance del objeto de escucha de salida que se configura para proxies de sidecar. A fin de reducir un sobredimensionamiento en la configuración y el uso de memoria, se recomienda aplicar un recurso de Sidecar predeterminado para cada espacio de nombres.

El proxy que Anthos Service Mesh ejecuta en el archivo de sidecar es Envoy. En la Terminología de Envoy, un cluster es un grupo lógicamente similar de extremos ascendentes que se usa como destino para el balanceo de cargas.

Inspecciona los clústeres salientes configurados en el proxy de sidecar de Envoy para el Pod de prueba mediante la ejecución del comando istioctl proxy-config:
```
${ISTIOCTL} pc c $(kubectl -n team-x get pod -l app=test \
    -o jsonpath={.items..metadata.name}).team-x --direction outbound
```
Hay alrededor de 20 clústeres de Envoy en la lista, incluidos varios para la puerta de enlace de salida.
Restringe la configuración del proxy a las rutas de salida que se definieron de forma explícita con entradas de servicio en los espacios de nombres istio-egress y team-x. Aplica un recurso de Sidecar al espacio de nombres team-x:
```
cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: default
  namespace: team-x
spec:
  outboundTrafficPolicy:
    mode: REGISTRY_ONLY
  egress:
  - hosts:
    - 'istio-egress/*'
    - 'team-x/*'
EOF
```
La configuración del modo de política de tráfico saliente en REGISTRY_ONLY restringe la configuración del proxy para incluir solo los hosts externos que se agregaron de manera explícita al registro de servicio de la malla mediante la definición de las entradas de servicio.

La parte "istio-egress/*" especifica que el proxy de sidecar selecciona las rutas del espacio de nombres istio-egress que están disponibles mediante el atributo exportTo. La parte “team-x/*” incluye cualquier ruta que se haya configurado de forma local en el espacio de nombres team-x.
Visualiza los clústeres salientes configurados en el proxy de sidecar de Envoy y compáralos con la lista de clústeres que se configuraron antes de aplicar el recurso Sidecar:
```
${ISTIOCTL} pc c $(kubectl -n team-x get pod -l app=test \
    -o jsonpath={.items..metadata.name}).team-x --direction outbound
```
El resultado incluye solo algunos clústeres para la puerta de enlace de salida y otro para el propio Pod de prueba.

Configura Anthos Service Mesh para enrutar el tráfico a través de la puerta de enlace de salida

Configura una Gateway para el tráfico HTTP en el puerto 80. La Gateway selecciona el proxy istio-egressgateway que el instalador implementó en el espacio de nombres istio-egress. La configuración de Gateway se aplica al espacio de nombres istio-egress y controla el tráfico para cualquier host.

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: egress-gateway
  namespace: istio-egress
spec:
  selector:
    istio: egress
  servers:
  - port:
      number: 80
      name: https
      protocol: HTTPS
    hosts:
      - '*'
    tls:
      mode: ISTIO_MUTUAL
EOF

Crea una DestinationRule para la puerta de enlace de salida con TLS mutua para la autenticación y encriptación. Usa una sola regla de destino compartida para todos los hosts externos.

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: target-egress-gateway
  namespace: istio-egress
spec:
  host: istio-egressgateway.istio-egress.svc.cluster.local
  subsets:
  - name: target-egress-gateway-mTLS
    trafficPolicy:
      loadBalancer:
        simple: ROUND_ROBIN
      tls:
        mode: ISTIO_MUTUAL
EOF

Crea una ServiceEntry en el espacio de nombres istio-egress a fin de registrar example.com en el registro de servicio de la malla para el espacio de nombres team-x de manera explícita:
```
cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: example-com-ext
  namespace: istio-egress
spec:
  hosts:
  - example.com
  ports:
  - number: 80
    name: http
    protocol: HTTP
  - number: 443
    name: tls
    protocol: TLS
  resolution: DNS
  location: MESH_EXTERNAL
  exportTo:
  - 'team-x'
  - 'istio-egress'
EOF
```
Configura un enrutamiento de salida diferente para cada espacio de nombres
La propiedad "exportTo" controla qué espacios de nombres pueden usar la entrada de servicio. Los administradores de red usan entradas de servicio para controlar de forma centralizada el conjunto de hosts externos disponibles para cada espacio de nombres. Configura los permisos de RBAC de Kubernetes para que solo los administradores de red puedan crear y modificar entradas de servicio de forma directa. Considera crear la automatización con un flujo de trabajo de aprobación para que los desarrolladores de aplicaciones puedan solicitar acceso a hosts externos nuevos.

Crea un VirtualService para enrutar el tráfico a example.com a través de la puerta de enlace de salida. Existen dos condiciones de coincidencia: la primera condición dirige el tráfico a la puerta de enlace de salida y la segunda dirige el tráfico de la puerta de enlace de salida al host de destino. La propiedad exportTo controla qué espacios de nombres pueden usar el servicio virtual.

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: example-com-through-egress-gateway
  namespace: istio-egress
spec:
  hosts:
  - example.com
  gateways:
  - istio-egress/egress-gateway
  - mesh
  http:
  - match:
    - gateways:
      - mesh
      port: 80
    route:
    - destination:
        host: istio-egressgateway.istio-egress.svc.cluster.local
        subset: target-egress-gateway-mTLS
        port:
          number: 80
      weight: 100
  - match:
    - gateways:
      - istio-egress/egress-gateway
      port: 80
    route:
    - destination:
        host: example.com
        port:
          number: 80
      weight: 100
  exportTo:
  - 'istio-egress'
  - 'team-x'
EOF

Ejecuta istioctl analyze para comprobar si hay errores de configuración:

${ISTIOCTL} analyze -n istio-egress

El resultado es similar al siguiente:

✔ No validation issues found when analyzing namespace: istio-egress.

Envía varias solicitudes a través de la puerta de enlace de salida al sitio externo:

for i in {1..4}
do
    kubectl -n team-x exec -it $(kubectl -n team-x get pod -l app=test \
        -o jsonpath={.items..metadata.name}) -c test -- \
    curl -s -o /dev/null -w "%{http_code}\n" http://example.com
done

Verás los códigos de estado 200 para las cuatro respuestas.

Verifica que las solicitudes se hayan dirigido a través de la puerta de enlace de salida mediante la verificación de los registros de acceso del proxy. Primero, verifica el registro de acceso del sidecar del proxy implementado con la aplicación de prueba:

kubectl -n team-x logs -f $(kubectl -n team-x get pod -l app=test \
    -o jsonpath={.items..metadata.name}) istio-proxy

Para cada solicitud que envíes, verás una entrada de registro similar a la que se muestra a continuación:

[2020-09-14T17:37:08.045Z] "HEAD / HTTP/1.1" 200 - "-" "-" 0 0 5 4 "-" "curl/7.67.0" "d57ea5ad-90e9-46d9-8b55-8e6e404a8f9b" "example.com" "10.1.4.12:8080" outbound|80||istio-egressgateway.istio-egress.svc.cluster.local 10.1.0.17:42140 93.184.216.34:80 10.1.0.17:60326 - -

Verifica también el registro de acceso de la puerta de enlace de salida:

kubectl -n istio-egress logs -f $(kubectl -n istio-egress get pod -l istio=egress \
    -o jsonpath="{.items[0].metadata.name}") istio-proxy

Para cada solicitud que envíes, verás una entrada de registro de acceso de puerta de enlace de salida similar a la siguiente:

[2020-09-14T17:37:08.045Z] "HEAD / HTTP/2" 200 - "-" "-" 0 0 4 3 "10.1.0.17" "curl/7.67.0" "095711e6-64ef-4de0-983e-59158e3c55e7" "example.com" "93.184.216.34:80" outbound|80||example.com 10.1.4.12:37636 10.1.4.12:8080 10.1.0.17:44404 outbound_.80_.target-egress-gateway-mTLS_.istio-egressgateway.istio-egress.svc.cluster.local -

Configura un enrutamiento diferente para un segundo espacio de nombres

Configura el enrutamiento de un segundo host externo a fin de obtener información sobre cómo se pueden configurar una conectividad externa diferente para distintos equipos.

Crea un recurso de Sidecar para el espacio de nombres team-y:

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
  name: default
  namespace: team-y
spec:
  outboundTrafficPolicy:
    mode: REGISTRY_ONLY
  egress:
  - hosts:
    - 'istio-egress/*'
    - 'team-y/*'
EOF

Implementa la aplicación de prueba en el espacio de nombres team-y:
```
kubectl -n team-y create -f ./test.yaml
```

Registra un segundo host externo y expórtalo al team-x y al espacio de nombres team-y:

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: httpbin-org-ext
  namespace: istio-egress
spec:
  hosts:
  - httpbin.org
  ports:
  - number: 80
    name: http
    protocol: HTTP
  - number: 443
    name: tls
    protocol: TLS
  resolution: DNS
  location: MESH_EXTERNAL
  exportTo:
  - 'istio-egress'
  - 'team-x'
  - 'team-y'
EOF

Crea un servicio virtual para enrutar el tráfico a httpbin.org a través de la puerta de enlace de salida:

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-org-through-egress-gateway
  namespace: istio-egress
spec:
  hosts:
  - httpbin.org
  gateways:
  - istio-egress/egress-gateway
  - mesh
  http:
  - match:
    - gateways:
      - mesh
      port: 80
    route:
    - destination:
        host: istio-egressgateway.istio-egress.svc.cluster.local
        subset: target-egress-gateway-mTLS
        port:
          number: 80
      weight: 100
  - match:
    - gateways:
      - istio-egress/egress-gateway
      port: 80
    route:
    - destination:
        host: httpbin.org
        port:
          number: 80
      weight: 100
  exportTo:
  - 'istio-egress'
  - 'team-x'
  - 'team-y'
EOF

Ejecuta istioctl analyze para comprobar si hay errores de configuración:

${ISTIOCTL} analyze -n istio-egress

Verás lo siguiente:

✔ No validation issues found when analyzing namespace: istio-egress.

Haz una solicitud a httpbin.org desde la aplicación de prueba team-y:

kubectl -n team-y exec -it $(kubectl -n team-y get pod -l app=test -o \
    jsonpath={.items..metadata.name}) -c test -- curl -I http://httpbin.org

Verás una respuesta 200 OK.

También haz una solicitud a httpbin.org desde la aplicación de prueba team-x:

kubectl -n team-x exec -it $(kubectl -n team-x get pod -l app=test \
    -o jsonpath={.items..metadata.name}) -c test -- curl -I http://httpbin.org

Verás una respuesta 200 OK.

Intenta realizar una solicitud a example.com desde el espacio de nombres team-y:
```
kubectl -n team-y exec -it $(kubectl -n team-y get pod -l app=test \
    -o jsonpath={.items..metadata.name}) -c test -- curl -I http://example.com
```
La solicitud falla porque no hay una ruta de salida configurada para el host example.com.

Usa la política de autorización para proporcionar control adicional sobre el tráfico

En este instructivo, las políticas de autorización para la puerta de enlace de salida se crean en el espacio de nombres istio-egress. Puedes configurar el RBAC de Kubernetes para que solo los administradores de red puedan acceder al espacio de nombres istio-egress.

Crea una AuthorizationPolicy para que las aplicaciones en el espacio de nombres team-x puedan conectarse a example.com, pero no a otros hosts externos cuando envíes solicitudes usando el puerto 80. El targetPort correspondiente en los Pods de la puerta de enlace de salida es 8080.

cat <<EOF | kubectl apply -f -
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: egress-team-x-to-example-com
  namespace: istio-egress
spec:
  rules:
    - from:
      - source:
          namespaces:
          - 'team-x'
      to:
      - operation:
          hosts:
            - 'example.com'
      when:
      - key: destination.port
        values: ["8080"]
EOF

Verifica que puedes realizar una solicitud a example.com desde la aplicación de prueba en el espacio de nombres team-x:

kubectl -n team-x exec -it $(kubectl -n team-x get pod -l app=test \
    -o jsonpath={.items..metadata.name}) -c test -- curl -I http://example.com

Verás una respuesta 200 OK.

Intenta realizar una solicitud a httpbin.org desde la aplicación de prueba en el espacio de nombres team-x:
```
kubectl -n team-x exec -it $(kubectl -n team-x get pod -l app=test \
    -o jsonpath={.items..metadata.name}) -c test -- curl -s -w " %{http_code}\n" \
    http://httpbin.org
```
La solicitud falla con un mensaje RBAC: access denied y un código de estado 403 Forbidden. Es posible que debas esperar unos segundos porque, por lo general, la política de autorización suele tardarse un poco en aplicarse.

Las políticas de autorización proporcionan un control detallado sobre el tráfico que se permite o se deniega. Aplica la siguiente política de autorización para permitir que la app de prueba en el espacio de nombres team-y realice solicitudes a httpbin.org mediante una ruta de URL específica cuando se envíen solicitudes con el puerto 80. El targetPort correspondiente en los Pods de la puerta de enlace de salida es 8080.

cat <<EOF | kubectl apply -f -
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: egress-team-y-to-httpbin-teapot
  namespace: istio-egress
spec:
  rules:
    - from:
      - source:
          namespaces:
          - 'team-y'
      to:
      - operation:
          hosts:
          - httpbin.org
          paths: ['/status/418']
      when:
      - key: destination.port
        values: ["8080"]
EOF

Intenta conectarte a httpbin.org desde la aplicación de prueba en el espacio de nombres team-y:
```
kubectl -n team-y exec -it $(kubectl -n team-y get pod -l app=test \
    -o jsonpath={.items..metadata.name}) -c test -- curl -s -w " %{http_code}\n" \
    http://httpbin.org
```
La solicitud falla con un RBAC: el mensaje de acceso denegado y un código de estado 403 Forbidden.

Ahora, realiza una solicitud a httpbin.org/status/418 desde la misma aplicación:

kubectl -n team-y exec -it $(kubectl -n team-y get pod -l app=test \
    -o jsonpath={.items..metadata.name}) -c test -- curl http://httpbin.org/status/418

La solicitud se ejecuta de forma correcta porque la ruta de acceso coincide con el patrón en la política de autorización. El resultado es similar al siguiente:

   -=[ teapot ]=-
      _...._
    .'  _ _ `.
   | ."` ^ `". _,
   \_;`"---"`|//
     |       ;/
     \_     _/
       `"""`

TLS de origen en la puerta de enlace de salida

Puedes configurar puertas de enlace de salida en solicitudes HTTP simples de “actualización” (de origen) a TLS. Permitir a las aplicaciones que realicen solicitudes HTTP simples tiene varias ventajas cuando se usan con la TLS mutua y la TLS de origen. Para obtener más información, consulta la guía de prácticas recomendadas.

TLS de origen en la puerta de enlace de salida

Crea una DestinationRule. The DestinationRule que especifique que la puerta de enlace origina una conexión TLS a example.com.

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: example-com-originate-tls
  namespace: istio-egress
spec:
  host: example.com
  subsets:
    - name: example-com-originate-TLS
      trafficPolicy:
        loadBalancer:
          simple: ROUND_ROBIN
        portLevelSettings:
        - port:
            number: 443
          tls:
            mode: SIMPLE
            sni: example.com
EOF

Actualiza el servicio virtual para example.com a fin de que las solicitudes al puerto 80 en la puerta de enlace se "actualicen" a TLS en el puerto 443 cuando se envíen al host de destino:

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: example-com-through-egress-gateway
  namespace: istio-egress
spec:
  hosts:
  - example.com
  gateways:
  - mesh
  - istio-egress/egress-gateway
  http:
  - match:
    - gateways:
      - mesh
      port: 80
    route:
    - destination:
        host: istio-egressgateway.istio-egress.svc.cluster.local
        subset: target-egress-gateway-mTLS
        port:
          number: 80
  - match:
    - gateways:
      - istio-egress/egress-gateway
      port: 80
    route:
    - destination:
        host: example.com
        port:
          number: 443
        subset: example-com-originate-TLS
      weight: 100
EOF

Realiza varias solicitudes a example.com desde la app de prueba en el espacio de nombres team-x:

for i in {1..4}
do
    kubectl -n team-x exec -it $(kubectl -n team-x get pod -l app=test \
        -o jsonpath={.items..metadata.name}) -c test -- curl -I http://example.com
done

Como antes, las solicitudes funcionan correctamente con respuestas 200 OK.

Verifica el registro de puerta de enlace de salida para comprobar que la puerta de enlace enruta las solicitudes al host de destino mediante conexiones TLS de origen:

kubectl -n istio-egress logs -f $(kubectl -n istio-egress get pod -l istio=egress \
    -o jsonpath="    {.items[0].metadata.name}") istio-proxy

El resultado es similar al siguiente:

[2020-09-24T17:58:02.548Z] "HEAD / HTTP/2" 200 - "-" "-" 0 0 6 5 "10.1.1.15" "curl/7.67.0" "83a77acb-d994-424d-83da-dd8eac902dc8" "example.com" "93.184.216.34:443" outbound|443|example-com-originate-TLS|example.com 10.1.4.31:49866 10.1.4.31:8080 10.1.1.15:37334 outbound_.80_.target-egress-gateway-mTLS_.istio-egressgateway.istio-egress.svc.cluster.local -

El sidecar del proxy envió la solicitud a la puerta de enlace usando el puerto 80 y la TLS de origen en el puerto 443 para enviar la solicitud al host de destino.

Paso de conexiones HTTPS/TLS

Es posible que tus aplicaciones existentes ya usen conexiones TLS cuando se comunican con servicios externos. Puedes configurar la puerta de enlace de salida para traspasar conexiones TLS sin desencriptarlas.

paso de tls

Modifica tu configuración de modo que la puerta de enlace de salida use el paso TLS para las conexiones al puerto 443:

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: egress-gateway
  namespace: istio-egress
spec:
  selector:
    istio: egress
  servers:
  - port:
      number: 80
      name: https
      protocol: HTTPS
    hosts:
      - '*'
    tls:
      mode: ISTIO_MUTUAL
  - port:
      number: 443
      name: tls
      protocol: TLS
    hosts:
    - '*'
    tls:
      mode: PASSTHROUGH
EOF

Actualiza la DestinationRule que apunta a la puerta de enlace de salida para agregar un segundo subconjunto para el puerto 443 en la puerta de enlace. Este subconjunto nuevo no usa TLS mutua. La TLS mutua de Istio no es compatible para el paso de conexiones TLS. Las conexiones en el puerto 80 siguen usando mTLS:

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: target-egress-gateway
  namespace: istio-egress
spec:
  host: istio-egressgateway.istio-egress.svc.cluster.local
  subsets:
  - name: target-egress-gateway-mTLS
    trafficPolicy:
      loadBalancer:
        simple: ROUND_ROBIN
      portLevelSettings:
      - port:
          number: 80
        tls:
          mode: ISTIO_MUTUAL
  - name: target-egress-gateway-TLS-passthrough
EOF

Actualiza el servicio virtual para example.com a fin de que el tráfico TLS en el puerto 443 se pase a través de la puerta de enlace:

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: example-com-through-egress-gateway
  namespace: istio-egress
spec:
  hosts:
  - example.com
  gateways:
  - mesh
  - istio-egress/egress-gateway
  http:
  - match:
    - gateways:
      - mesh
      port: 80
    route:
    - destination:
        host: istio-egressgateway.istio-egress.svc.cluster.local
        subset: target-egress-gateway-mTLS
        port:
          number: 80
  - match:
    - gateways:
      - istio-egress/egress-gateway
      port: 80
    route:
    - destination:
        host: example.com
        port:
          number: 443
        subset: example-com-originate-TLS
      weight: 100
  tls:
  - match:
    - gateways:
      - mesh
      port: 443
      sniHosts:
      - example.com
    route:
    - destination:
        host: istio-egressgateway.istio-egress.svc.cluster.local
        subset: target-egress-gateway-TLS-passthrough
        port:
          number: 443
  - match:
    - gateways:
      - istio-egress/egress-gateway
      port: 443
      sniHosts:
      - example.com
    route:
    - destination:
        host: example.com
        port:
          number: 443
      weight: 100
  exportTo:
  - 'istio-egress'
  - 'team-x'
EOF

Actualiza el servicio virtual para httpbin.org a fin de que el tráfico TLS en el puerto 443 se pase a través de la puerta de enlace:

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: httpbin-org-through-egress-gateway
  namespace: istio-egress
spec:
  hosts:
  - httpbin.org
  gateways:
  - istio-egress/egress-gateway
  - mesh
  http:
  - match:
    - gateways:
      - mesh
      port: 80
    route:
    - destination:
        host: istio-egressgateway.istio-egress.svc.cluster.local
        subset: target-egress-gateway-mTLS
        port:
          number: 80
      weight: 100
  - match:
    - gateways:
      - istio-egress/egress-gateway
      port: 80
    route:
    - destination:
        host: httpbin.org
        port:
          number: 80
      weight: 100
  tls:
  - match:
    - gateways:
      - mesh
      port: 443
      sniHosts:
      - httpbin.org
    route:
    - destination:
        host: istio-egressgateway.istio-egress.svc.cluster.local
        subset: target-egress-gateway-TLS-passthrough
        port:
          number: 443
  - match:
    - gateways:
      - istio-egress/egress-gateway
      port: 443
      sniHosts:
      - httpbin.org
    route:
    - destination:
        host: httpbin.org
        port:
          number: 443
      weight: 100
  exportTo:
  - 'istio-egress'
  - 'team-x'
  - 'team-y'
EOF

Agrega una política de autorización que acepte cualquier tipo de tráfico enviado al puerto 443 del servicio de puerta de enlace de salida. El targetPort correspondiente en los Pods de puerta de enlace es 8443.

cat <<EOF | kubectl apply -f -
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: egress-all-443
  namespace: istio-egress
spec:
  rules:
    - when:
      - key: destination.port
        values: ["8443"]
EOF

Ejecuta istioctl analyze para comprobar si hay errores de configuración:

${ISTIOCTL} analyze -n istio-egress

Verás lo siguiente:

✔ No validation issues found when analyzing namespace: istio-egress.

Realiza una solicitud HTTP simple a example.com desde la aplicación de prueba en el espacio de nombres team-x:
```
kubectl -n team-x exec -it $(kubectl -n team-x get pod -l app=test \
    -o jsonpath={.items..metadata.name}) -c test -- curl -I http://example.com
```
La solicitud se ejecuta correctamente con una respuesta 200 OK.

Ahora realiza varias solicitudes TLS (HTTPS) desde la aplicación de prueba en el espacio de nombres team-x:

for i in {1..4}
do
    kubectl -n team-x exec -it $(kubectl -n team-x get pod -l app=test \
        -o jsonpath={.items..metadata.name}) -c test -- curl -s -o /dev/null \
        -w "%{http_code}\n" \
        https://example.com
done

Verás 200 respuestas.

Mira el registro de la puerta de enlace de salida nuevamente:

kubectl -n istio-egress logs -f $(kubectl -n istio-egress get pod -l istio=egress \
    -o jsonpath="{.items[0].metadata.name}") istio-proxy

Verás entradas de registro similares a las siguientes:

[2020-09-24T18:04:38.608Z] "- - -" 0 - "-" "-" 1363 5539 10 - "-" "-" "-" "-" "93.184.216.34:443" outbound|443||example.com 10.1.4.31:51098 10.1.4.31:8443 10.1.1.15:57030 example.com -

La solicitud HTTPS se procesó como tráfico de TCP y se pasó por la puerta de enlace al host de destino, por lo que no se incluye información HTTP en el registro.

Usa Kubernetes NetworkPolicy como un control adicional

Hay muchas situaciones en las que una aplicación puede omitir un proxy de sidecar. Puedes usar NetworkPolicy de Kubernetes a fin de especificar de forma adicional qué conexiones pueden realizar las cargas de trabajo. Una vez que se aplica una sola política de red, se deniegan todas las conexiones que no se permiten de forma específica.

En este instructivo, solo se consideran las conexiones de salida y los selectores de salida para las políticas de red. Si controlas la entrada con políticas de red en tus propios clústeres, debes crear políticas de entrada para que coincidan con tus políticas de salida. Por ejemplo, si permites la salida de cargas de trabajo en el espacio de nombres team-x al espacio de nombres team-y, también debes permitir la entrada al espacio de nombres team-y desde el espacio de nombres team-x.

Permite que las cargas de trabajo y los proxies implementados en el espacio de nombres team-x se conecten a istiod y la puerta de enlace de salida:

cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-to-control-plane
  namespace: team-x
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          istio: system
      podSelector:
        matchLabels:
          istio: istiod
    - namespaceSelector:
        matchLabels:
          istio: egress
      podSelector:
        matchLabels:
          istio: egress
EOF

Permite que las cargas de trabajo y los proxies consulten el DNS:

cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-to-dns
  namespace: team-x
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          kube-system: "true"
    ports:
    - port: 53
      protocol: UDP
    - port: 53
      protocol: TCP
EOF

Permite que las cargas de trabajo y los proxies se conecten a las IP que entregan las API y los servicios de Google, incluida la CA de Mesh:

cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-to-google-apis
  namespace: team-x
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
  - to:
    - ipBlock:
        cidr: 199.36.153.4/30
    - ipBlock:
        cidr: 199.36.153.8/30
EOF

Permite que las cargas de trabajo y los proxies se conecten al servidor de metadatos de GKE:

cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-to-metadata-server
  namespace: team-x
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
  - to: # For GKE data plane v2
    - ipBlock:
        cidr: 169.254.169.254/32
  - to: # For GKE data plane v1
    - ipBlock:
        cidr: 127.0.0.1/32
    ports:
    - protocol: TCP
      port: 988
EOF

Opcional: Permite que las cargas de trabajo y los proxies del espacio de nombres team-x hagan conexiones entre sí:

cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-to-same-namespace
  namespace: team-x
spec:
  podSelector: {}
  ingress:
    - from:
      - podSelector: {}
  egress:
    - to:
      - podSelector: {}
EOF

Opcional: Permite que las cargas de trabajo y los proxies en el espacio de nombres team-x establezcan conexiones con las cargas de trabajo implementadas por un equipo diferente:

cat <<EOF | kubectl apply -f -
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-to-team-y
  namespace: team-x
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
  - to:
    - namespaceSelector:
        matchLabels:
          team: 'y'
EOF

Las conexiones entre proxies de sidecar persisten. Las conexiones existentes no se cierran cuando aplicas una política de red nueva. Reinicia las cargas de trabajo en el espacio de nombres de Team-x para asegurarte de que las conexiones existentes estén cerradas:
```
kubectl -n team-x rollout restart deployment
```
Verifica que aún puedas realizar una solicitud HTTP a example.com desde la aplicación de prueba en el espacio de nombres team-x:
```
kubectl -n team-x exec -it $(kubectl -n team-x get pod -l app=test \
    -o jsonpath={.items..metadata.name}) -c test -- curl -I http://example.com
```
La solicitud se ejecuta correctamente con una respuesta 200 OK.

Accede directamente a las API de Google con permisos de IAM y Acceso privado a Google

Las API y los servicios de Google se exponen mediante direcciones IP externas. Cuando los Pods con direcciones IP de alias nativos de VPC realizan conexiones a las API de Google mediante el Acceso privado a Google, el tráfico nunca sale de la red de Google.

Cuando configuraste la infraestructura para este instructivo, habilitaste el Acceso privado a Google para la subred que usan los Pods de GKE. Para permitir el acceso a las direcciones IP que usa el Acceso privado a Google, creaste una ruta, una regla de firewall de VPC y una zona de DNS privado. Esta configuración permite que los Pods lleguen a las API de Google directamente sin enviar tráfico a través de la puerta de enlace de salida. Puedes controlar qué API están disponibles para cuentas de servicio de Kubernetes específicas (y, por lo tanto, espacios de nombres) mediante Workload Identity, así como IAM. La autorización de Istio no se aplica porque la puerta de enlace de salida no maneja conexiones a las API de Google.

Antes de que los Pods puedan llamar a las API de Google, debes usar IAM para otorgar permisos. El clúster que usas para este instructivo está configurado a fin de usar Workload Identity, que permite que una cuenta de servicio de Kubernetes actúe como una cuenta de servicio de Google.

Crea una cuenta de servicio de Google para que tu aplicación use:
```
gcloud iam service-accounts create sa-test-app-team-x
```

Permite que la cuenta de servicio de Kubernetes actúe en nombre de la cuenta de servicio de Google:

gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:${PROJECT_ID}.svc.id.goog[team-x/test]" \
  sa-test-app-team-x@${PROJECT_ID}.iam.gserviceaccount.com

Anota la cuenta de servicio de Kubernetes para la app de prueba en el espacio de nombres team-x con la dirección de correo electrónico de la cuenta de servicio de Google:

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    iam.gke.io/gcp-service-account: sa-test-app-team-x@${PROJECT_ID}.iam.gserviceaccount.com
  name: test
  namespace: team-x
EOF

El Pod de la aplicación de prueba debe poder acceder al servidor de metadatos de Google (que se ejecuta como DaemonSet) a fin de obtener credenciales temporales para llamar a las API de Google. Crea una entrada de servicio para el servidor de metadatos de GKE:

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: metadata-google-internal
  namespace: istio-egress
spec:
  hosts:
  - metadata.google.internal
  ports:
  - number: 80
    name: http
    protocol: HTTP
  - number: 443
    name: tls
    protocol: TLS
  resolution: DNS
  location: MESH_EXTERNAL
  exportTo:
  - 'istio-egress'
  - 'team-x'
EOF

También crea una entrada de servicio para private.googleapis.com y storage.googleapis.com:

cat <<EOF | kubectl apply -f -
apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: private-googleapis-com
  namespace: istio-egress
spec:
  hosts:
  - private.googleapis.com
  - storage.googleapis.com
  ports:
  - number: 80
    name: http
    protocol: HTTP
  - number: 443
    name: tls
    protocol: TLS
  resolution: DNS
  location: MESH_EXTERNAL
  exportTo:
  - 'istio-egress'
  - 'team-x'
EOF

Verifica que la cuenta de servicio de Kubernetes esté configurada correctamente para que actúe como la cuenta de servicio de Google:
```
kubectl -n team-x exec -it $(kubectl -n team-x get pod -l app=test \
    -o jsonpath={.items..metadata.name}) -c test -- gcloud auth list
```
Verás la cuenta de servicio de Google como la identidad activa y única.

Crea un archivo de prueba en un bucket de Cloud Storage:

echo "Hello, World!" > /tmp/hello
gsutil mb gs://${PROJECT_ID}-bucket
gsutil cp /tmp/hello gs://${PROJECT_ID}-bucket/

Otorga permiso a la cuenta de servicio para enumerar y ver archivos en el bucket:

gsutil iam ch \
serviceAccount:sa-test-app-team-x@${PROJECT_ID}.iam.gserviceaccount.com:objectViewer \
    gs://${PROJECT_ID}-bucket/

Verifica que la aplicación de prueba pueda acceder al bucket de prueba:

kubectl -n team-x exec -it \
$(kubectl -n team-x get pod -l app=test -o jsonpath={.items..metadata.name}) \
-c test \
-- gsutil cat gs://${PROJECT_ID}-bucket/hello

Verás lo siguiente:

Hello, World!

Limpia

Para evitar que se apliquen cargos a tu cuenta de Google Cloud por los recursos usados en este instructivo, borra el proyecto que contiene los recursos o conserva el proyecto y borra los recursos individuales.

Para evitar que se generen cargos en tu cuenta de Google Cloud por los recursos que se usaron en este instructivo, sigue los pasos de las siguientes secciones:

Borra el proyecto

La manera más fácil de eliminar la facturación es borrar el proyecto que creaste para el instructivo.

Precaución: Borrar un proyecto tiene estas consecuencias:

Se borra todo en el proyecto. Si usaste un proyecto existente para las tareas de este documento, cuando lo borres, también se borrará cualquier otro trabajo que hayas realizado en el proyecto.
Se pierden los ID personalizados de proyectos. Cuando creaste este proyecto, es posible que hayas creado un ID del proyecto personalizado que desees utilizar en el futuro. Para conservar las URL que utilizan el ID del proyecto, como una URL appspot.com, borra los recursos seleccionados dentro del proyecto en lugar de borrar todo el proyecto.

Si planeas explorar varias infraestructuras, instructivos y guías de inicio rápido la reutilización de proyectos puede ayudarte a evitar exceder los límites de las cuotas del proyecto.

En la consola de Google Cloud, ve a la página Administrar recursos.
Ir a Administrar recursos
En la lista de proyectos, elige el proyecto que quieres borrar y haz clic en Borrar.
En el diálogo, escribe el ID del proyecto y, luego, haz clic en Cerrar para borrar el proyecto.

¿Qué sigue?

Consulta la guía de prácticas recomendadas complementarias.
Consulta la guía de endurecimiento de GKE.
Obtén información sobre cómo administrar la configuración y la política en toda tu infraestructura con la Administración de configuraciones de GKE Enterprise.
Para obtener más información sobre las arquitecturas de referencia, los diagramas y las prácticas recomendadas, explora Cloud Architecture Center.