Skip to main content

Pregunta 44 | CKS Challenge 4 - Monitoreo de Seguridad y Respuesta a Incidentes

¡Llévame al laboratorio!

Ten en cuenta que el estado de competición para los Desafíos CKS ha terminado. Por favor no envíes una solución. No será puntuada.

Se han desplegado varias objetos de Kubernetes dentro de los namespaces omega, citadel y eden-prime. Sin embargo, ¡se han observado varias operaciones sospechosas/anormales en estos namespaces!

Por ejemplo, en el namespace citadel, la aplicación llamada webapp-color está cambiando constantemente. Puedes ver esto por ti mismo haciendo clic en el enlace citadel-webapp y refrescando la página cada 30 segundos. De manera similar hay otros problemas con varios otros objetos en otros namespaces.

Para entender qué está causando estas anomalías, se te requerirá configurar auditing en Kubernetes y hacer uso de la herramienta Falco.

Inspecciona los problemas en detalle haciendo clic en los iconos del diagrama de arquitectura interactivo en el laboratorio y completa las tareas para asegurar el cluster. Una vez hecho, haz clic en el botón Check para validar tu trabajo.

Realiza las tareas en este orden

Haz clic en todos los iconos individualmente y lee las tareas. Hay información importante dentro.

El icono Deployment en el namespace citadel proporciona la siguiente información:

Elimina el rolebinding que causa la eliminación y creación constante de los configmaps y pods en este namespace.

Así que, esto identifica los objetos que necesitamos auditar en la siguiente tarea.

Auditing/audit-log​

  • El archivo de política de auditoría debe almacenarse en /etc/kubernetes/audit-policy.yaml
  • Crea una única regla en la política de auditoría que registrará eventos para los dos objetos que muestran comportamiento anormal en el namespace citadel. Esta regla sin embargo debe aplicarse a los tres namespaces mostrados en el diagrama a un nivel de metadata. Omite la etapa RequestReceived.
  • Usa un volumen llamado audit que montará solo el archivo /etc/kubernetes/audit-policy.yaml desde el controlplane dentro del pod del servidor api en modo de solo lectura.
  • audit-log-path configurado a /var/log/kubernetes/audit/audit.log

Crea la política de auditoría.

vi /etc/kubernetes/audit-policy.yaml

Crea la política solicitada

apiVersion: audit.k8s.io/v1
kind: Policy
omitStages:             # Omitir RequestReceived
    - RequestReceived
rules:
    - level: Metadata     # Nueva regla a nivel Metadata
    resources:          # para pods y configmaps
    - group: ""
        resources:
        - pods
        - configmaps
    namespaces:         # en los tres namespaces
    - omega
    - citadel
    - eden-prime

Monta la política en el servidor api

Crea el directorio para el log de auditoría primero, o el servidor api fallará al iniciar

mkdir -p /var/log/kubernetes/audit

Edita el manifiesto del servidor api

vi /etc/kubernetes/manifests/kube-apiserver.yaml

Añade los argumentos requeridos para habilitar auditoría

    - --audit-log-path=/var/log/kubernetes/audit/audit.log
    - --audit-policy-file=/etc/kubernetes/audit-policy.yaml

Añade volúmenes (a cualquier volumen existente) para la política de auditoría y el log

    volumes:
    - name: audit-log
    hostPath:
        path: /var/log/kubernetes/audit/
        type: DirectoryOrCreate
    - name: audit
    hostPath:
        path: /etc/kubernetes/audit-policy.yaml
        type: File  # <- satisface el requisito "montará solo el archivo"

Añade volumeMounts (a cualquiera existente) para estos volúmenes

    volumeMounts:
    - name: audit-log
        mountPath: var/log/kubernetes/audit/
        readOnly: false
    - name: audit
        mountPath: /etc/kubernetes/audit-policy.yaml
        readOnly: true      # <- El archivo debe ser inmutable

Guarda y sal de vi. Espera a que el servidor api se reinicie. Si no lo hace, conoce cómo diagnosticar un servidor API fallido.

Falco​

Instala la utilidad 'falco' en el nodo controlplane e iníciala como un servicio systemd

# Actualizar índices apt
apt-get update -y

# Instalar prerrequisitos y falco
apt-get -y install linux-headers-$(uname -r) falco

# No es estrictamente necesario iniciarlo ahora, pero si quieres un icono verde
# en esta etapa, necesitarás iniciarlo.
systemctl start falco

Configurar falco para guardar la salida de eventos en el archivo /opt/falco.log

abre /etc/falco/falco.yaml en vi, encuentra la sección de salida de archivo y hazla así

file_output:
    enabled: true
    keep_alive: false
    filename: /opt/falco.log

Recargar falco

systemctl restart falco

security report​

  • Inspecciona los logs de auditoría del servidor API e identifica al usuario responsable del comportamiento anormal visto en el namespace citadel. Guarda el nombre del user, role y rolebinding responsables del evento en el archivo /opt/blacklist_users (separados por comas y en este orden específico).

  • Inspecciona los logs de falco e identifica el pod que tiene eventos generados debido a actualizaciones de paquetes en él. Guarda el namespace y el nombre del pod en el archivo /opt/compromised_pods (separados por comas - namespace seguido por el nombre del pod)

Inspeccionar logs de auditoría​

Los logs de auditoría son JSON, un registro JSON por línea del archivo de log, y sabemos que estamos buscando citadel. Realiza un escaneo superficial de algunas líneas de log para entender la estructura. Usa la herramienta jq para formatear las líneas de log de manera legible.

cat /var/log/kubernetes/audit/audit.log | grep citadel | head -4 | jq .

Toda la información requerida probablemente está ahí en el JSON que puedes ver ahora, sin embargo mejoremos la búsqueda con un filtro jq para seleccionar eventos de eliminación, ya que eso es lo que estamos buscando

cat /var/log/kubernetes/audit/audit.log | grep citadel | jq 'select (.verb == "delete")'

Y ahí lo tenemos. Prácticamente todos los registros identifican al perpetrador y el role/rolebinding que se está usando.

Guardar resultados

echo 'agent-smith,important_role_do_not_delete,important_binding_do_not_delete' > /opt/blacklist_users

Inspeccionar logs de falco​

Inspeccionar logs

Se nos ha dicho que busquemos algo relacionado con paquetes:

grep -i package /opt/falco.log

Salida:

19:23:46.797259642: Error Package management process launched in container (user=root user_loginuid=-1 command=apt install nginx container_id=55e02f53cced container_name=k8s_eden-software2_eden-software2_eden-prime_78092ae9-37b6-4a37-b01f-8b63c9598aa2_0 image=ubuntu:latest)

Identificar pod

De la salida (container_name=), podemos determinar

  • El Namespace es eden-prime
  • El nombre del Pod es eden-software2

Guardar resultados

echo 'eden-prime,eden-software2' > /opt/compromised_pods

eden-prime/pod​

  • Elimina los pods pertenecientes al namespace eden-prime que fueron marcados en el archivo del 'Informe de Seguridad' /opt/compromised_pods. ¡No elimines los pods no comprometidos!

Usando el pod descubierto en la tarea anterior con el log de falco:

kubectl delete pod -n eden-prime eden-software2

citadel/deploy​

  • Elimina el rolebinding que causa la eliminación y creación constante de los configmaps y pods en este namespace. ¡No elimines ningún otro rolebinding!

Refiere a lo que se encontró en el log de auditoría

kubectl delete rolebinding -n citadel important_binding_do_not_delete

citadel/secret​

  • Elimina el role que causa la eliminación y creación constante de los configmaps y pods en este namespace. ¡No elimines ningún otro role!

Refiere a lo que se encontró en el log de auditoría

kubectl delete role -n citadel important_role_do_not_delete