Skip to content

LABORATORIO FINAL: SEGURIDAD EN KUBERNETES

Una empresa llamada SecureApp está a punto de desplegar su primera aplicación en producción sobre Kubernetes. Antes de hacerlo, el equipo de seguridad exige tres controles fundamentales: verificar que ninguna imagen con vulnerabilidades críticas llegue al clúster, garantizar que los pods cumplan políticas de seguridad mediante un motor de admisión, y aislar la comunicación entre componentes usando Network Policies. Este laboratorio es el desafío integrador del curso. No se proporcionan comandos ni configuraciones completas. Los enunciados describen el estado final esperado y los tips al final son las únicas pistas disponibles.

Laboratorio

Sección 1 — Análisis de Imágenes con Trivy

1. Instale Trivy en su máquina de trabajo siguiendo la documentación oficial para su sistema operativo.

2. Analice la imagen nginx:1.21 y genere un reporte en formato tabla. Identifique cuántas vulnerabilidades de severidad CRITICAL y HIGH contiene e indíquelas en su reporte de entrega.

3. Analice la misma imagen pero filtrando únicamente las vulnerabilidades de severidad CRITICAL. Compare la cantidad de resultados con el análisis anterior.

4. Analice la imagen nginx:alpine con el mismo filtro de severidad CRITICAL. Compare los resultados contra nginx:1.21.

5. Analice la imagen python:3.9 y genere el reporte en formato JSON. Utilice jq para extraer únicamente el nombre del paquete, la severidad y el CVE de cada vulnerabilidad encontrada.

6. Escanee el directorio de trabajo secureapp-lab como sistema de archivos en busca de secretos o configuraciones sensibles expuestas.

Sección 2 — Políticas de Admisión con Kubewarden

1. Cree el namespace kubewarden en el clúster.

2. Agregue el repositorio Helm de Kubewarden a su configuración local e instale los siguientes componentes en orden:

kubewarden-crds kubewarden-controller kubewarden-defaults Todos deben desplegarse en el namespace kubewarden. Verifique que todos los pods del namespace están en estado Running antes de continuar.

3. Cree el namespace secureapp-prod donde se desplegarán las aplicaciones de producción de SecureApp.

4. Aplique una AdmissionPolicy en el namespace secureapp-prod usando la política ghcr.io/kubewarden/policies/pod-privileged:latest que rechace cualquier pod que solicite modo privilegiado. El modo de la política debe ser protect.

5. Intente crear el siguiente pod en el namespace secureapp-prod:

apiVersion: v1
kind: Pod
metadata:
  name: test-privileged
  namespace: secureapp-prod
spec:
  containers:
  - name: test
    image: nginx:alpine
    securityContext:
      privileged: true

6. Intente crear un pod normal sin contexto de seguridad privilegiado en el mismo namespace y verifique que esta vez sí es admitido.

7. Aplique una segunda AdmissionPolicy en el namespace secureapp-prod usando la política ghcr.io/kubewarden/policies/user-group-psp:latest que rechace pods que se ejecuten como root. Configure la política para que el campo run_as_user tenga la regla MustRunAsNonRoot.

8. Intente desplegar un pod que no defina runAsNonRoot ni runAsUser en su Security Context dentro del namespace secureapp-prod.

9. Cree un Deployment llamado secureapp-api en el namespace secureapp-prod que cumpla con ambas políticas aplicadas. El Deployment debe:

Usar la imagen nginx:alpine Definir runAsNonRoot: true y runAsUser: 1000 No usar modo privilegiado Tener 2 réplicas Verifique que el Deployment llega a estado Available.

10. Consulte los eventos del namespace secureapp-prod y confirme que los rechazos de Kubewarden aparecen registrados.

Sección 3 — Network Policies

1. Además del namespace secureapp-prod ya creado, cree los siguientes namespaces:

secureapp-frontend secureapp-monitoring 2. Etiquete cada namespace con la etiqueta role usando los valores backend, frontend y monitoring respectivamente.

3. Despliegue los siguientes pods de prueba:

Un pod llamado backend-app en secureapp-prod con la imagen nginx:alpine y la etiqueta app: backend Un pod llamado frontend-app en secureapp-frontend con la imagen nginx:alpine y la etiqueta app: frontend Un pod llamado monitoring-app en secureapp-monitoring con la imagen nginx:alpine y la etiqueta app: monitoring Exponga backend-app con un Service de tipo ClusterIP en el puerto 80 dentro del namespace secureapp-prod.

4. Verifique la conectividad inicial antes de aplicar políticas. Desde el pod frontend-app, haga curl al Service de backend-app usando su nombre DNS completo.

5. Aplique una Network Policy de tipo deny-all en el namespace secureapp-prod que bloquee todo el tráfico de entrada y salida por defecto.

6. Verifique nuevamente desde frontend-app que ya no puede alcanzar backend-app.

7. Cree una Network Policy que permita tráfico de entrada hacia los pods con etiqueta app: backend en secureapp-prod, pero únicamente originado desde pods con etiqueta app: frontend en namespaces con etiqueta role: frontend.

8. Verifique que frontend-app ahora puede alcanzar backend-app y que monitoring-app sigue sin poder hacerlo.

9. Cree una Network Policy que permita al namespace secureapp-prod realizar solicitudes de salida únicamente hacia el puerto 53 UDP y TCP para resolución DNS, y hacia el namespace secureapp-monitoring.

10. Desde backend-app, intente hacer curl a frontend-app y luego a monitoring-app.