Guía Avanzada de Hardening y Detección en Kubernetes

Índice

1. Introducción
2. Arquitectura Segura de Kubernetes
   1. Control Plane
   2. Worker Nodes
   3. Redes Seguras
3. Hardening de Nodos y Contenedores
   1. Nodos Linux
   2. Contenedores
   3. Imágenes y Supply Chain
4. Políticas de Seguridad
   1. PodSecurityStandards
   2. Admission Controllers
   3. Secrets y Gestión de Credenciales
5. Monitorización Avanzada de Kubernetes
   1. Logging Centralizado
   2. Métricas y Observabilidad
6. Detección de Anomalías
   1. Falco: Runtime Security
   2. Integración con SIEM
7. Respuesta y Mitigación
   1. Aislamiento de Pods Comprometidos
   2. Actualización Segura
   3. Backups y Recuperación
8. Checklist Avanzado de Hardening y Detección
9. Herramientas Recomendadas
10. Ejemplos Prácticos de Scripts y YAML
    1. Script de auditoría de pods con privilegios
    2. Restrictive NetworkPolicy YAML
11. Conclusión

Introducción

Kubernetes se ha convertido en el estándar de facto para la orquestación de contenedores en entornos de producción, desde startups hasta grandes corporaciones. Sin embargo, su creciente complejidad y la adopción de microservicios distribuidos aumentan la superficie de ataque y los riesgos asociados a una configuración insegura. Los ataques pueden ir desde compromisos de pods individuales hasta la escalada de privilegios en el cluster completo.

Esta guía tiene como objetivo proporcionar un manual avanzado de hardening y detección, combinando teoría, buenas prácticas, ejemplos prácticos y comandos aplicables, pensado para sysadmins, DevSecOps y responsables de seguridad.

Objetivos principales de la guía:

• Reducir la superficie de ataque de clusters Kubernetes y nodos asociados.
• Implementar políticas de seguridad robustas, tanto a nivel de nodos como de workloads.
• Establecer mecanismos de monitorización y detección temprana de incidentes.
• Crear un flujo de trabajo reproducible y auditable que pueda adaptarse a entornos de producción críticos.

Alcance de la Parte 1:

• Arquitectura segura del cluster.
• Hardening de nodos y contenedores.
• Configuración de políticas de seguridad básicas y avanzadas.
• Buenas prácticas de gestión de imágenes y secretos.

1. Arquitectura Segura de Kubernetes

La arquitectura de Kubernetes es compleja y se divide principalmente en Control Plane y Worker Nodes. Una comprensión profunda de estos componentes es fundamental para implementar medidas de seguridad efectivas.

1.1 Control Plane

El control plane gestiona el estado del cluster y toma decisiones sobre scheduling, escalado y gestión de workloads. Incluye los siguientes componentes:

• kube-apiserver: expone la API del cluster y es el punto de entrada para usuarios, controladores y nodos.
• etcd: almacén clave-valor que guarda la configuración completa del cluster y secretos.
• kube-scheduler: asigna pods a nodos disponibles basándose en recursos y políticas.
• kube-controller-manager: ejecuta controladores que mantienen el estado deseado del cluster.
• cloud-controller-manager (si aplica): integra Kubernetes con proveedores de nube.

Buenas prácticas de seguridad para el control plane:

1. Separación física o virtual: ejecuta los componentes del control plane en nodos dedicados, aislados de los workloads.
2. Firewall y VPN: restringe el acceso a kube-apiserver mediante VPN o bastion hosts.
3. TLS obligatorio: todas las comunicaciones internas deben usar certificados TLS válidos.
4. Autenticación robusta: habilitar OIDC, certificados de cliente o autenticación basada en tokens.
5. Auditoría: habilitar audit logging en kube-apiserver para rastrear cambios y accesos.

Ejemplo de habilitación de audit logging en kube-apiserver:

--audit-log-path=/var/log/kubernetes/audit.log
--audit-log-maxage=30
--audit-log-maxbackup=10
--audit-log-maxsize=100
--audit-policy-file=/etc/kubernetes/audit-policy.yaml

audit-policy.yaml (ejemplo mínimo):

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata
  verbs: ["create", "update", "patch", "delete"]
  resources:
  - group: ""
    resources: ["pods", "secrets", "configmaps"]

1.2 Worker Nodes

Los nodos ejecutan los pods y contienen los agentes kubelet y kube-proxy. Recomendaciones de hardening para nodos:

• Sistema base: utilizar distribuciones Linux orientadas a seguridad, como Ubuntu LTS con minimal install, Rocky Linux o AlmaLinux.
• Kernel hardened: aplicar configuraciones de sysctl y deshabilitar módulos innecesarios.
• Control de acceso: únicamente el kubelet y el root del sistema deben tener privilegios administrativos.
• Actualizaciones automáticas: mantener el kernel y paquetes de seguridad actualizados.

Ejemplo de configuración básica de sysctl para nodos:

# Deshabilitar IP forwarding innecesario
sysctl -w net.ipv4.ip_forward=0

# Activar protecciones contra spoofing
sysctl -w net.ipv4.conf.all.rp_filter=1
sysctl -w net.ipv4.conf.default.rp_filter=1

# Deshabilitar ICMP redirects
sysctl -w net.ipv4.conf.all.accept_redirects=0
sysctl -w net.ipv4.conf.all.send_redirects=0

1.3 Redes Seguras

Las políticas de red son críticas para limitar el movimiento lateral dentro del cluster y proteger servicios sensibles.

• Network Policies: controlar qué pods pueden comunicarse entre sí.
• CNI seguro: Calico o Cilium permiten segmentación y políticas avanzadas de firewall.
• Namespaces y segmentación: usar namespaces para aislar workloads críticos, combinando políticas de red restrictivas.
• Control de egress: limitar el tráfico saliente de pods para evitar que procesos comprometidos accedan a Internet innecesariamente.

Ejemplo de NetworkPolicy restringida:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-app-traffic
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: my-app
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 80
  egress:
  - to:
    - podSelector:
        matchLabels:
          role: database
    ports:
    - protocol: TCP
      port: 5432

2. Hardening de Nodos y Contenedores

2.1 Nodos Linux

• Mínima exposición: desinstalar paquetes y servicios innecesarios.
• SUID/SGID audit: revisar binarios que puedan ser usados para escalamiento de privilegios.

find / -perm /4000 -type f -exec ls -la {} \;

• Auditd y journald: habilitar y centralizar logs.
• Kernel hardening: activar protecciones de memoria (ASLR), mitigaciones de spectre/meltdown y restricciones de ptrace.

Ejemplo de sysctl avanzado:

# Habilitar ASLR
sysctl -w kernel.randomize_va_space=2

# Limitar ptrace
sysctl -w kernel.yama.ptrace_scope=1

# Protecciones contra SYN flood
sysctl -w net.ipv4.tcp_syncookies=1

2.2 Contenedores

• Filesystem read-only: evita escritura innecesaria en rootfs.

securityContext:
  readOnlyRootFilesystem: true
  runAsNonRoot: true
  runAsUser: 1001
  allowPrivilegeEscalation: false

• Capabilities mínimas:

capabilities:
  drop:
    - ALL
  add:
    - NET_BIND_SERVICE

• Seccomp y AppArmor: definir perfiles para limitar syscalls.

securityContext:
  seccompProfile:
    type: RuntimeDefault

• No ejecutar como root: runAsNonRoot: true y runAsUser.

2.3 Imágenes y Supply Chain

• Escaneo de vulnerabilidades: Trivy, Clair, Grype.
• Firmado de imágenes: Cosign o Notary.
• Minimizar layers: usar imágenes base distroless o Alpine.
• Evitar secretos en imágenes: ningún token ni password en Dockerfile o build context.

Ejemplo de escaneo con Trivy:

trivy image mycompany/myapp:latest

3. Políticas de Seguridad

3.1 PodSecurityStandards

• Configurar restricted como default para todos los namespaces sensibles.
• Revisar excepciones con documentación y aprobaciones.

apiVersion: policy/v1
kind: PodSecurityPolicy
metadata:
  name: restricted
spec:
  privileged: false
  allowPrivilegeEscalation: false
  requiredDropCapabilities:
    - ALL
  runAsUser:
    rule: MustRunAsNonRoot
  seLinux:
    rule: RunAsAny
  readOnlyRootFilesystem: true

3.2 Admission Controllers

• OPA/Gatekeeper: aplicar políticas como “no pods con root” o “no imagenes no firmadas”.
• LimitRange: limitar recursos por pod.

apiVersion: v1
kind: LimitRange
metadata:
  name: limits
spec:
  limits:
  - type: Container
    max:
      cpu: "1"
      memory: 512Mi
    min:
      cpu: 100m
      memory: 64Mi

3.3 Secrets y Gestión de Credenciales

• Usar Kubernetes Secrets cifrados y rotación periódica.
• Integración con Vault o KMS externos para mejorar seguridad.
• Evitar incluir secretos en manifests o imágenes.

Ejemplo de creación de secret cifrado:

kubectl create secret generic db-password \
  --from-literal=password='SuperSecreto123!' \
  --namespace=production

• Validar acceso con RBAC:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: production
  name: secret-reader
rules:
- apiGroups: [""]
  resources: ["secrets"]
  verbs: ["get", "list"]

4. Monitorización Avanzada de Kubernetes

La monitorización no solo sirve para métricas de rendimiento, sino también para detección temprana de incidentes de seguridad, identificación de anomalías y auditoría de cambios críticos.

4.1 Logging Centralizado

• Objetivo: recopilar logs de pods, nodos y control plane en un sistema centralizado para análisis y auditoría.

• Herramientas recomendadas:

  • ELK Stack (Elasticsearch, Logstash, Kibana)
  • Loki + Grafana
  • Splunk

Ejemplo de configuración con Fluentd para ELK:

apiVersion: v1
kind: ConfigMap
metadata:
  name: fluentd-config
  namespace: kube-system
data:
  fluentd.conf: |
    
      @type tail
      path /var/log/containers/*.log
      pos_file /var/log/fluentd-containers.log.pos
      tag kubernetes.*
      format json
    
    
      @type elasticsearch
      host elasticsearch.kube-system.svc.cluster.local
      port 9200
      logstash_format true
    

Buenas prácticas:

• Normalizar los logs para facilitar búsquedas y alertas.
• Configurar retención según normativas y capacidad de almacenamiento.
• Separar logs de producción de entornos de desarrollo.

4.2 Métricas y Observabilidad

• Prometheus + Grafana: para métricas de CPU, memoria, latencia y tráfico.
• Alertmanager: para definir reglas de alerta ante comportamientos sospechosos, como picos inusuales de tráfico o fallos de pods críticos.

Ejemplo de alerta Prometheus para pods que reinician excesivamente:

groups:
- name: pod-restart-alerts
  rules:
  - alert: PodCrashLooping
    expr: increase(kube_pod_container_status_restarts_total[5m]) > 3
    for: 10m
    labels:
      severity: critical
    annotations:
      summary: "Pod en crashloop"
      description: "El pod {{ $labels.pod }} en el namespace {{ $labels.namespace }} ha reiniciado más de 3 veces en los últimos 5 minutos."

5. Detección de Anomalías

La detección avanzada combina eventos del sistema, auditoría y reglas de comportamiento para identificar posibles ataques o incidentes.

5.1 Falco: Runtime Security

• Falco: motor de detección de comportamiento anómalo en contenedores y nodos.

• Detecta actividades sospechosas como:

  • Pods ejecutando como root.
  • Cambios en binarios críticos.
  • Montajes de dispositivos no permitidos.
  • Ejecución de comandos en contenedores comprometidos.

Ejemplo de regla Falco para detectar ejecución de bash en pods no autorizados:

- rule: Bash Shell in Pod
  desc: Detect bash execution in production pods
  condition: evt.type = execve and proc.name = bash and container.id != host
  output: "Bash detected in container (user=%user.name container=%container.id)"
  priority: WARNING
  tags: [container, shell]

5.2 Integración con SIEM

• Objetivo: correlacionar eventos de múltiples fuentes para detectar patrones de ataque complejos.
• Fuentes de datos: auditd, kube-audit, logs de pods, alertas de Falco o Sysdig.
• Herramientas: Wazuh, Splunk, ELK Stack con dashboards personalizados.

Caso práctico:

• Detectar acceso a secretos por usuarios no autorizados.
• Detectar creación de pods con privilegios elevados.
• Alertar cuando un contenedor ejecuta comandos de red sospechosos.

6. Respuesta y Mitigación

La respuesta rápida y organizada reduce el impacto de incidentes en Kubernetes.

6.1 Aislamiento de Pods Comprometidos

• Kubernetes commands:

kubectl cordon node01
kubectl drain node01 --ignore-daemonsets --delete-emptydir-data
kubectl label pod compromised=true
kubectl apply -f restrictive-networkpolicy.yaml

• Redirigir tráfico o aislar el namespace afectado mediante NetworkPolicies restrictivas.

6.2 Actualización Segura

• Mantener nodos y clusters actualizados mediante rolling upgrades para minimizar downtime.
• Actualizar imágenes de contenedores con vulnerabilidades conocidas y aplicar imagePullPolicy: Always.

Ejemplo rolling update seguro:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: mycompany/myapp:v2.0

6.3 Backups y Recuperación

• etcd backup: crítico para recuperar el cluster.

ETCDCTL_API=3 etcdctl snapshot save snapshot.db \
  --endpoints=https://127.0.0.1:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/peer.crt \
  --key=/etc/kubernetes/pki/etcd/peer.key

• Restauración en entorno de prueba antes de aplicar en producción.
• Backups de volúmenes persistentes y secretos cifrados.

7. Checklist Avanzado de Hardening y Detección

8. Herramientas Recomendadas

• Escaneo de vulnerabilidades: Trivy, Clair, Grype
• Seguridad en runtime: Falco, Sysdig Secure
• Gestión de secretos: HashiCorp Vault, Sealed Secrets
• Auditoría CIS Kubernetes Benchmark: kube-bench, kube-hunter
• Políticas y validación: OPA/Gatekeeper, Kyverno
• Monitorización y alertas: Prometheus + Alertmanager, Grafana, ELK, Loki

9. Ejemplos Prácticos de Scripts y YAML

9.1 Script de auditoría de pods con privilegios

#!/bin/bash
# Audita pods que corren como root o con capacidades elevadas
kubectl get pods --all-namespaces -o json | jq '.items[] | select(.spec.containers[]?.securityContext.runAsNonRoot == false)'

9.2 Restrictive NetworkPolicy YAML

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: production
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  - Egress

Conclusión

La seguridad en Kubernetes requiere un enfoque defense-in-depth, combinando:

1. Hardening de nodos y contenedores
2. Políticas de seguridad estrictas y revisables
3. Monitorización avanzada y detección de anomalías
4. Planes de respuesta y recuperación efectivos

Esta guía proporciona un marco completo y profesional para endurecer clusters Kubernetes y detectar incidentes tempranamente. La clave es la automatización, auditoría continua y adaptación a nuevas amenazas, manteniendo al mismo tiempo la operatividad del entorno.