GSP480

Descripción general

En este lab, aprenderás a aplicar restricciones precisas a la comunicación de red para mejorar la seguridad de tu instancia de Kubernetes Engine.

El Principio de mínimo privilegio es ampliamente reconocido como una importante consideración de diseño al momento de mejorar la protección de sistemas fundamentales contra las fallas y el comportamiento malicioso. Sugiere que cada componente pueda acceder solo a la información y los recursos necesarios para su propósito legítimo. Este documento demuestra cómo se puede implementar el principio de privilegio mínimo dentro de la capa de red de Kubernetes Engine.

Las conexiones de red se pueden restringir a dos niveles de tu infraestructura de Kubernetes Engine. El primer mecanismo, de menor precisión, es la aplicación de reglas de firewall a niveles de red, subred y host. Estas reglas se aplican fuera de Kubernetes Engine, a nivel de VPC.

Si bien las reglas de firewall son una medida de seguridad sólida, Kubernetes te permite definir reglas aún más precisas mediante las políticas de red. Las políticas de red se usan para limitar la comunicación dentro del clúster. No se aplican a los Pods conectados al espacio de nombres de red del host.

En este lab, aprovisionarás un clúster privado de Kubernetes Engine y un host de bastión mediante el cual accederás al clúster. Un host de bastión proporciona un solo host con acceso al clúster, el cual, al combinarse con una red privada de Kubernetes, garantiza que el clúster no esté expuesto a comportamientos maliciosos de Internet en general. Los hosts de bastión son particularmente útiles cuando no tienes acceso de VPN a la red de la nube.

Dentro del clúster, se aprovisionarán un servidor HTTP simple y dos Pods cliente. Aprenderás a usar una política de red y a establecer etiquetas para permitir solo las conexiones desde uno de los Pods cliente.

Los ingenieros de GKE Helmsman crearon este lab para ayudarte a comprender mejor la Autorización Binaria de GKE. Para ver esta demostración, ejecuta los comandos gsutil cp -r gs://spls/gke-binary-auth/* . y cd gke-binary-auth-demo en Cloud Shell. Te invitamos a hacer cualquier aporte que creas conveniente.

Arquitectura

Definirás un clúster privado de Kubernetes de modo estándar que use Dataplane V2. Dataplane V2 tiene políticas de red habilitadas de forma predeterminada.

Dado que el clúster es privado, no se podrá acceder a la API ni a los nodos trabajadores desde Internet. En su lugar, definirás un host de bastión y usarás una regla de firewall para habilitar el acceso al clúster. La dirección IP del host de bastión se define como una red autorizada para el clúster, la cual le otorga acceso a la API.

Dentro del clúster, aprovisiona tres cargas de trabajo:

1. hello-server: Este es un servidor HTTP simple con un extremo accesible internamente.
2. hello-client-allowed: Este es un Pod único que intenta de forma repetida acceder a hello-server. El Pod se etiquetará de tal manera que la política de red te permitirá conectarte a hello-server.
3. hello-client-blocked: Este ejecuta el mismo código que hello-client-allowed, pero el Pod se etiquetará de tal manera que la política de red no le permitirá conectarse a hello-server.

Configuración y requisitos

Antes de hacer clic en el botón Comenzar lab

Lee estas instrucciones. Los labs son cronometrados y no se pueden pausar. El cronómetro, que comienza a funcionar cuando haces clic en Comenzar lab, indica por cuánto tiempo tendrás a tu disposición los recursos de Google Cloud.

Este lab práctico te permitirá realizar las actividades correspondientes en un entorno de nube real, no en uno de simulación o demostración. Para ello, se te proporcionan credenciales temporales nuevas que utilizarás para acceder a Google Cloud durante todo el lab.

Para completar este lab, necesitarás lo siguiente:

• Acceso a un navegador de Internet estándar (se recomienda el navegador Chrome)

Nota: Usa una ventana de navegador privada o de Incógnito para ejecutar este lab. Así evitarás cualquier conflicto entre tu cuenta personal y la cuenta de estudiante, lo que podría generar cargos adicionales en tu cuenta personal.

• Tiempo para completar el lab: Recuerda que, una vez que comienzas un lab, no puedes pausarlo.

Nota: Si ya tienes un proyecto o una cuenta personal de Google Cloud, no los uses en este lab para evitar cargos adicionales en tu cuenta.

Cómo iniciar tu lab y acceder a la consola de Google Cloud

1. Haga clic en el botón Comenzar lab. Si debe pagar por el lab, se abrirá una ventana emergente para que seleccione su forma de pago. A la izquierda, se encuentra el panel Detalles del lab, que tiene estos elementos:

   • El botón Abrir la consola de Google Cloud
   • El tiempo restante
   • Las credenciales temporales que debe usar para el lab
   • Otra información para completar el lab, si es necesaria

2. Haz clic en Abrir la consola de Google Cloud (o haz clic con el botón derecho y selecciona Abrir el vínculo en una ventana de incógnito si ejecutas el navegador Chrome).

   El lab inicia recursos y abre otra pestaña en la que se muestra la página de acceso.

   Sugerencia: Ordene las pestañas en ventanas separadas, una junto a la otra.

   Nota: Si ves el diálogo Elegir una cuenta, haz clic en Usar otra cuenta.

3. De ser necesario, copia el nombre de usuario a continuación y pégalo en el diálogo Acceder.

   {{{user_0.username | "Username"}}}

   También puedes encontrar el nombre de usuario en el panel Detalles del lab.

4. Haz clic en Siguiente.

5. Copia la contraseña que aparece a continuación y pégala en el diálogo Te damos la bienvenida.

   {{{user_0.password | "Password"}}}

   También puedes encontrar la contraseña en el panel Detalles del lab.

6. Haz clic en Siguiente.

   Importante: Debes usar las credenciales que te proporciona el lab. No uses las credenciales de tu cuenta de Google Cloud. Nota: Usar tu propia Cuenta de Google podría generar cargos adicionales.

7. Haga clic para avanzar por las páginas siguientes:

   • Acepta los Términos y Condiciones.
   • No agregues opciones de recuperación o autenticación de dos factores (esta es una cuenta temporal).
   • No te registres para obtener pruebas gratuitas.

Después de un momento, se abrirá la consola de Google Cloud en esta pestaña.

Nota: Para ver un menú con una lista de productos y servicios de Google Cloud, haz clic en el menú de navegación que se encuentra en la parte superior izquierda.

Activa Cloud Shell

Cloud Shell es una máquina virtual que cuenta con herramientas para desarrolladores. Ofrece un directorio principal persistente de 5 GB y se ejecuta en Google Cloud. Cloud Shell proporciona acceso de línea de comandos a tus recursos de Google Cloud.

1. Haz clic en Activar Cloud Shell en la parte superior de la consola de Google Cloud.

Cuando te conectes, habrás completado la autenticación, y el proyecto estará configurado con tu PROJECT_ID. El resultado contiene una línea que declara el PROJECT_ID para esta sesión:

Your Cloud Platform project in this session is set to YOUR_PROJECT_ID

gcloud es la herramienta de línea de comandos de Google Cloud. Viene preinstalada en Cloud Shell y es compatible con la función de autocompletado con tabulador.

2. Puedes solicitar el nombre de la cuenta activa con este comando (opcional):

gcloud auth list

3. Haz clic en Autorizar.

4. Ahora, el resultado debería verse de la siguiente manera:

Resultado:

ACTIVE: * ACCOUNT: student-01-xxxxxxxxxxxx@qwiklabs.net To set the active account, run: $ gcloud config set account `ACCOUNT`

5. Puedes solicitar el ID del proyecto con este comando (opcional):

gcloud config list project

Resultado:

[core] project = <project_ID>

Resultado de ejemplo:

[core] project = qwiklabs-gcp-44776a13dea667a6 Nota: Para obtener toda la documentación de gcloud, consulta la guía con la descripción general de gcloud CLI en Google Cloud.

Clona la demostración

1. Copia los recursos necesarios para este ejercicio de lab desde un bucket de Cloud Storage:

gsutil cp -r gs://spls/gsp480/gke-network-policy-demo .

2. Ve al directorio de la demostración:

cd gke-network-policy-demo

3. Haz que los archivos de demostración sean ejecutables con el siguiente comando:

chmod -R 755 *

Tarea 1. Configuración del lab

Primero, configura la región y la zona de Google Cloud.

1. Configura la región de Google Cloud.

gcloud config set compute/region "{{{project_0.default_region|placeholder}}}"

2. Configura la zona de Google Cloud. gcloud config set compute/zone "{{{project_0.default_zone|placeholder}}}"

En este lab, se usarán las siguientes APIs de servicio de Google Cloud, habilitadas para ti:

• compute.googleapis.com
• container.googleapis.com
• cloudbuild.googleapis.com

Además, la configuración de Terraform tiene tres parámetros para determinar dónde se debe crear el clúster de Kubernetes Engine:

• project ID
• region
• zone

Para mayor simplicidad, estos parámetros se especifican en un archivo llamado terraform.tfvars, en el directorio de terraform.

3. Ejecuta el siguiente comando para asegurarte de que estén habilitadas las APIs adecuadas y generar el archivo terraform/terraform.tfvars basado en tus valores predeterminados de gcloud:

make setup-project

4. Escribe y cuando se te pida confirmar.

Esto habilitará las API de servicio necesarias y también generará un archivo terraform/terraform.tfvars con las siguientes claves.

5. Ejecuta el siguiente comando para verificar que los valores coincidan con el resultado de gcloud config list:

cat terraform/terraform.tfvars

Aprovisiona el clúster de Kubernetes Engine

1. A continuación, aplica la configuración de Terraform en el directorio raíz del proyecto:

make tf-apply

2. Cuando se te solicite, revisa el plan generado e ingresa yes para implementar el entorno.

La implementación tardará varios minutos.

Tarea 2. Validación

Terraform mostrará un mensaje cuando se haya creado el clúster de forma exitosa.

...snip... google_container_cluster.primary: Still creating... (3m0s elapsed) google_container_cluster.primary: Still creating... (3m10s elapsed) google_container_cluster.primary: Still creating... (3m20s elapsed) google_container_cluster.primary: Still creating... (3m30s elapsed) google_container_cluster.primary: Creation complete after 3m34s (ID: gke-demo-cluster) Apply complete! Resources: 5 added, 0 changed, 0 destroyed.

Prueba la tarea completada

Haz clic en Revisar mi progreso para verificar la tarea realizada. Si implementaste correctamente la infraestructura necesaria con Terraform, verás una puntuación de evaluación.

Usar Terraform para configurar la infraestructura necesaria (Configuración del lab)

1. Ahora, para los pasos restantes, establece una conexión SSH al host de bastión:

gcloud compute ssh gke-demo-bastion

Las versiones existentes de kubectl y los clientes personalizados de Kubernetes contienen código específico del proveedor para administrar la autenticación entre el cliente y Google Kubernetes Engine. A partir de la versión 1.26, este código ya no se incluirá como parte del kubectl de OSS. Los usuarios de GKE deberán descargar y usar un complemento de autenticación independiente para generar tokens específicos de GKE. Este nuevo objeto binario, gke-gcloud-auth-plugin, usa el mecanismo complemento de credenciales Client-go de Kubernetes para extender la autenticación de kubectl y hacerla compatible con GKE. Para obtener más información, revisa la siguiente documentación.

Sigue estos pasos para que kubectl use el nuevo complemento de objeto binario para la autenticación, en lugar del código específico del proveedor.

2. Luego de conectarte, ejecuta el siguiente comando para instalar gke-gcloud-auth-plugin en la VM.

sudo apt-get install google-cloud-sdk-gke-gcloud-auth-plugin

3. Establece export USE_GKE_GCLOUD_AUTH_PLUGIN=True en ~/.bashrc de la siguiente forma:

echo "export USE_GKE_GCLOUD_AUTH_PLUGIN=True" >> ~/.bashrc

4. Ejecuta el siguiente comando:

source ~/.bashrc

5. Ejecuta el siguiente comando para forzar la configuración de este clúster, de manera que se actualice a la configuración del complemento de credenciales Client-go.

gcloud container clusters get-credentials gke-demo-cluster --zone {{{project_0.default_zone|placeholder}}}

Si la operación es exitosa, verás este mensaje:

kubeconfig entry generated for gke-demo-cluster.

El clúster recién creado estará disponible para los comandos estándar de kubectl en el host de bastión.

Tarea 3. Instala el servidor hello server

La aplicación de prueba consiste en un servidor HTTP simple, implementado como hello-server, y dos clientes, uno que se etiquetará como app=hello y el otro como app=not-hello.

Los tres servicios se pueden implementar al aplicar los manifiestos de hello-app.

1. En el host de bastión, ejecuta el siguiente comando:

kubectl apply -f ./manifests/hello-app/

Resultado:

deployment.apps/hello-client-allowed created deployment.apps/hello-client-blocked created service/hello-server created deployment.apps/hello-server created

2. Verifica que los tres Pods se hayan implementado correctamente:

kubectl get pods

Verás un Pod en funcionamiento por cada implementación de hello-client-allowed, hello-client-blocked y hello-server.

NAME READY STATUS RESTARTS AGE hello-client-allowed-7d95fcd5d9-t8fsk | 1/1 Running 0 14m hello-client-blocked-6497db465d-ckbn8 | 1/1 Running 0 14m hello-server-7df58f7fb5-nvcvd | 1/1 Running 0 14m

Prueba la tarea completada

Haz clic en Revisar mi progreso para verificar la tarea realizada. Si implementaste correctamente el servidor HTTP simple hello server, verás una puntuación de evaluación.

Instalar el servidor hello server

Tarea 4. Confirma el acceso predeterminado a hello server

1. Primero, muestra las últimas líneas del cliente "permitido" con tail:

kubectl logs --tail 10 -f $(kubectl get pods -oname -l app=hello)

Para salir, presiona Ctrl+C.

2. Segundo, muestra las últimas líneas de los registros del cliente "bloqueado":

kubectl logs --tail 10 -f $(kubectl get pods -oname -l app=not-hello)

3. Para salir, presiona Ctrl+C.

Notarás que los dos Pods pueden conectarse con éxito al servicio hello-server. Esto es porque aún no definiste una política de red para restringir el acceso. En cada una de estas ventanas, deberías ver respuestas exitosas por parte del servidor.

Hostname: hello-server-7df58f7fb5-nvcvd Hello, world! Version: 1.0.0 Hostname: hello-server-7df58f7fb5-nvcvd Hello, world! Version: 1.0.0 Hostname: hello-server-7df58f7fb5-nvcvd ...

Tarea 5. Restringe el acceso mediante una política de red

Ahora bloquearás el acceso al Pod hello-server de todos los Pods que no tengan la etiqueta app=hello.

La definición de la política que usarás está incluida en el archivo manifests/network-policy.yaml.

1. Aplica la política con el siguiente comando:

kubectl apply -f ./manifests/network-policy.yaml

Resultado:

networkpolicy.networking.k8s.io/hello-server-allow-from-hello-client created

2. Vuelve a mostrar las últimas líneas de los registros del cliente "bloqueado":

kubectl logs --tail 10 -f $(kubectl get pods -oname -l app=not-hello)

Ahora, en la ventana que muestra las líneas del cliente "bloqueado", verás que el resultado se ve así:

wget: download timed out wget: download timed out wget: download timed out wget: download timed out wget: download timed out wget: download timed out wget: download timed out wget: download timed out wget: download timed out ...

La política de red evitó la comunicación desde el Pod sin etiqueta a hello-server.

3. Para salir, presiona Ctrl+C.

Tarea 6. Restringe los espacios de nombres con políticas de red

En el ejemplo anterior, definiste una política de red que restringe las conexiones en función de etiquetas de Pod. Por lo general, resulta útil etiquetar espacios de nombres completos, particularmente cuando los equipos o aplicaciones tienen sus propios espacios de nombres.

Modificarás la política de red para que solo permita el tráfico desde un espacio de nombres designado y, luego, moverás el Pod hello-allowed hacia ese espacio de nombres nuevo.

1. Primero, borra la política de red existente:

kubectl delete -f ./manifests/network-policy.yaml

Resultado:

networkpolicy.networking.k8s.io "hello-server-allow-from-hello-client" deleted

2. Crea la versión con espacio de nombres:

kubectl create -f ./manifests/network-policy-namespaced.yaml

Resultado:

networkpolicy.networking.k8s.io/hello-server-allow-from-hello-client created

3. Ahora observa los registros del Pod hello-allowed-client en el espacio de nombres predeterminado:

kubectl logs --tail 10 -f $(kubectl get pods -oname -l app=hello)

Notarás que ya no puedes conectarte a hello-server.

4. Para salir, presiona Ctrl+C.

5. Por último, implementa una segunda copia de la aplicación hello-clients en el espacio de nombres nuevo.

kubectl -n hello-apps apply -f ./manifests/hello-app/hello-client.yaml

Resultado:

deployment.apps/hello-client-allowed created deployment.apps/hello-client-blocked created

Prueba la tarea completada

Haz clic en Revisar mi progreso para verificar la tarea realizada. Si implementaste correctamente una segunda copia de la aplicación hello-clients en el espacio de nombres nuevo, verás una puntuación de evaluación.

Implementar una segunda copia de la aplicación hello-clients en el espacio de nombres nuevo

Tarea 7. Validación

A continuación, revisa los registros de los dos clientes nuevos de hello-app.

1. Ejecuta el siguiente comando para observar los registros de la aplicación con la etiqueta "hello" en el espacio de nombres hello-apps de la aplicación:

kubectl logs --tail 10 -f -n hello-apps $(kubectl get pods -oname -l app=hello -n hello-apps)

Resultado:

Hostname: hello-server-6c6fd59cc9-7fvgp Hello, world! Version: 1.0.0 Hostname: hello-server-6c6fd59cc9-7fvgp Hello, world! Version: 1.0.0 Hostname: hello-server-6c6fd59cc9-7fvgp Hello, world! Version: 1.0.0 Hostname: hello-server-6c6fd59cc9-7fvgp Hello, world! Version: 1.0.0 Hostname: hello-server-6c6fd59cc9-7fvgp

Ambos clientes pueden conectarse con éxito porque, a partir de Kubernetes 1.10.x, las políticas de red no admiten la restricción del acceso a los Pods dentro de un espacio de nombres determinado. Puedes agregar a la lista de entidades permitidas etiquetas de Pods o de espacios de nombres, o la unión (es decir, OR) de ambas. Sin embargo, aún no puedes incluir en la lista la intersección (es decir, AND) de etiquetas de Pods y etiquetas de espacios de nombres.

2. Para salir, presiona Ctrl+C.

Tarea 8. Eliminación

Qwiklabs se encargará de cerrar todos los recursos utilizados en este lab, pero esto es lo que debes hacer para limpiar tu propio entorno a fin de reducir los costos y ser un buen ciudadano de la nube:

1. Sal del host de bastión:

exit

2. Ejecuta el siguiente comando para destruir el entorno:

make teardown

Resultado:

...snip... google_compute_subnetwork.cluster-subnet: Still destroying... (ID: us-east1/kube-net-subnet, 20s elapsed) google_compute_subnetwork.cluster-subnet: Destruction complete after 25s google_compute_network.gke-network: Destroying... (ID: kube-net) google_compute_network.gke-network: Still destroying... (ID: kube-net, 10s elapsed) google_compute_network.gke-network: Still destroying... (ID: kube-net, 20s elapsed) google_compute_network.gke-network: Destruction complete after 26s Destroy complete! Resources: 5 destroyed.

Tarea 9. Soluciona problemas en tu propio entorno

Cuando se ejecuta Terraform, la secuencia de comandos de instalación falla y muestra el mensaje “Permission denied”

Las credenciales que usa Terraform no proporcionan los permisos necesarios para crear recursos en los proyectos seleccionados. Asegúrate de que la cuenta que se detalla en gcloud config list tenga los permisos necesarios para crear recursos. Si los tiene, vuelve a generar las credenciales predeterminadas de la aplicación mediante gcloud auth application-default login.

Error de huella digital no válida durante las operaciones de Terraform

En ocasiones, Terraform emite un mensaje de error de huella digital no válida al actualizar ciertos recursos.

Si ves el error que aparece a continuación, simplemente vuelve a ejecutar el comando.

¡Felicitaciones!

Aplicaste restricciones precisas a la comunicación de red para mejorar la seguridad de tu instancia de Kubernetes Engine.

Finaliza la Quest

Este lab de autoaprendizaje es parte de la Quest Google Kubernetes Engine Best Practices: Security. Una Quest es una serie de labs relacionados que forman una ruta de aprendizaje. Si completas esta Quest, obtendrás una insignia como reconocimiento por tu logro. Puedes hacer públicas tus insignias y agregar vínculos a ellas en tu currículum en línea o en tus cuentas de redes sociales. Inscríbete en esta Quest y obtén un crédito inmediato de realización. Consulta el catálogo de Google Cloud Skills Boost para ver todas las Quests disponibles.

Realiza tu próximo lab

Continúa tu Quest con Cómo endurecer las configuraciones de clústeres de GKE predeterminadas, o revisa otros labs de Google Cloud Skills Boost:

• Seguridad de Google Kubernetes Engine: Autorización binaria
• Cómo utilizar el control de acceso basado en roles en Kubernetes Engine

Próximos pasos/Más información

• Terraform Google Provider
• Políticas de red de Kubernetes
• Kubernetes Engine: Crea una política de red de clúster
• Kubernetes Engine: Instructivo sobre políticas de red
• Kubernetes Engine: Endurecimiento de la seguridad del clúster

Capacitación y certificación de Google Cloud

Recibe la formación que necesitas para aprovechar al máximo las tecnologías de Google Cloud. Nuestras clases incluyen habilidades técnicas y recomendaciones para ayudarte a avanzar rápidamente y a seguir aprendiendo. Para que puedas realizar nuestros cursos cuando más te convenga, ofrecemos distintos tipos de capacitación de nivel básico a avanzado: a pedido, presenciales y virtuales. Las certificaciones te ayudan a validar y demostrar tus habilidades y tu conocimiento técnico respecto a las tecnologías de Google Cloud.

Última actualización del manual: 18 de octubre de 2023

Prueba más reciente del lab: 18 de octubre de 2023

Copyright 2024 Google LLC. Este software se proporciona tal como está, sin garantías ni declaraciones para ningún uso o propósito. El uso que hagas de él está sujeto a tu acuerdo con Google.