Hardening de Kubernetes – OWASP

Como escribir ayuda a mi mecanismo de estudio hare esta pequeña guia.

Si bien, tengo esta horrible opinion de que la ciberseguridad esta sobrevalorda, como una disciplina. En otro articulo me quejare, pero que una pregunta del examen KCSA sea ¿Como se llama la actividad de evaluar vulnerabilidades? y la respuesta sea ‘Vulnerability Assessment’ (Evaluacion de vulnerbilidades), me resulta algo vacio. Y sobretodo que esta evaluacion es revisar filepaths y hash de archivos.

En fin. El hardening es algo en la misma linea. Es basicamente reforzar una tecnologia (hacerla mas dura) y hay algunas Guias populares que son parte de la prueba.

Entre esas guias tenemos.

  1. OWASP 10: https://owasp.org/Top10/2025/
  2. NSA Hardening Guide: https://github.com/kubearmor/KubeArmor/wiki/NSA-Kubernetes-Hardening-Guide | https://media.defense.gov/2022/Aug/29/2003066362/-1/-1/0/CTR_KUBERNETES_HARDENING_GUIDANCE_1.2_20220829.PDF
  3. K8 Checklist: https://kubernetes.io/docs/concepts/security/security-checklist/
  4. Y en mi caso la de azure: https://learn.microsoft.com/en-us/azure/security/fundamentals/overview
  5. Y no puedo olvidarme de STRIDE: https://es.wikipedia.org/wiki/STRIDE_(seguridad)

La mayoria de estas me parecen en lo personal de lo mas curiosas, porque en gran parte son sentido comun. Aunque sentido comunn es mal utilizado, son sentido minimo. Es lo minimo que deberias considerar para evitar el caos.

Vamos con los puntos mas interesantes:

OWASP 10, el cual me resulta el mas gracioso de todos, porque la lista es, el analisis de los problemas mas comunes segun su muestra:

  • A01:2025 Broken Access Control: Basicamente se permite a sistemas que pueden accederse sin autenticacion. Ya sea porque permite el acceso publico, porque se puede alterar o manipular externamente. En general, denegar toda comunicacion sin accesos.
  • A02:2025 Security Misconfiguration: En general se refiere a fallas en la configuracion de sistemas desde el punto de vista de seguridad. Por ejemplo no actualizar a la ultima version (mis reservas sobre esto), mantener usuarios por defecto, no tener configuracion de seguridad por defecto en sistemas.
  • A03:2025 Software Supply Chain Failures: Este es uno de los temas mas sensibles, por eso mis reserva en la parte de actualizar la ultima version. Pero se refiere a no realizar la validacion de firmas dependencias, y al origen del software. Para evitar esto durante la construccion de sistemas, se debe identificar concientemente todas las dependencias que el sistema necesita y depende.
  • A04:2025 Cryptographic Failures: Basicamente se refiere al uso de protocolos seguros en la transmision y reposo de datos. Asi como el uso de algoritmos validos y modernos.
  • A05:2025 Injection: Esto ya es un poco mas de vulnerabilidades reales. La inyeccion es permitir la ejecucion de codigo o comandos remotos, desde la entrada de datos de un cliente. Ya sea por no limpiar, transformar, evitar cadenas de inyeccion. Que a dia de hoy la mayoria de frameworks te limitan.
  • A06:2025 Insecure Design: Basicamente esto se refiere a seguir buenas practicas en el desarrollo del software, curiosamente con dos buzzwords. ‘design patterns’ o ‘paved road’ y tener diferentes analisis de amenazas, y un analista de seguridad de aplicaciones componente. O que al menos tenga una herramienta automatica de monitoreo.
  • A07 Authentication Failures: Basicamente fallas de la configuracion, me parece raro que no se considere igual que la primera. Pero se refiere cuando una persona externa con credenciales incorrectas es capaz de accede al sistema o crear nuevas cuentas.
  • A08:2025 Software or Data Integrity Failures: Se refiere a problemas en el software y plataformas. Basicamente a confiar mediante firmas en todos los proveedores internos de informacion.
  • A09:2025 Security Logging & Alerting Failures: Basicamente es la ausencia de logs a nivel global. A nivel de auditoria, a nivel de acciones sensibles, a nivel de sistema, y a nivel de usuario. La ausencia en diferentes niveles causa con este incomplimiento. Todo debe alertar segun su nivel correspondiente.
  • A10:2025 Mishandling of Exceptional Conditions: Es la perdida de control a situaciones inesperadas, normalmente programaticas, pero puede escalar a cualquier nivel. Los ataques de DDoS entran en esta categoria. Donde una plataforma empieza a fallar a las solicitudes por la falta de recursos.

Bien eso es todo por esta publicacion, separare en varios post para que sea mas facil leer y escribir, por mi mismo, el unico usuario de este blog.