Skip to main content

Introducción a la Seguridad Kubernetes

Vamos a hacer una visión general sobre varios aspectos de seguridad de Kubernetes. Esto es bastante importante cuando trabajamos con Kubernetes en producción y para el examen del CKS.

Principios de la Seguridad​

De forma general la seguridad es un proceso complejo pues no es una única cosa a la que debemos prestar atención, es una combinación de varias cosas diferentes.

Los entornos cambian, lo que significa que la seguridad no puede permanecer en un determinado estado por mucho tiempo, siendo necesario adaptarse constantemente.

Los atacantes generalmente tienen ventaja por decidir cuándo y qué atacar, pudiendo elegir por el eslabón débil de nuestro sistema, es por eso que es bueno seguir los principios de seguridad.

  • Defensa en profundidad: Debemos tener múltiples capas de seguridad y la redundancia es siempre bienvenida.
  • Mínimo privilegio: Todo debe ejecutarse solamente con el permiso necesario. Por ejemplo un pod debe usar una service account con el mínimo de privilegio para que si un atacante consigue ejecutar algo esté dentro del contenedor limitado.
  • Disminuir superficies de Ataque: Eliminar o incluso eliminar posibilidades para que el invasor pueda explotar cualquier cosa en nuestro sistema.

La redundancia es buena en seguridad, lo que va contra el principio DRY (Don't repeat yourself) del desarrollo.

Imaginemos que un invasor va a atacar algo en nuestro clúster.

El primer nivel de defensa sería lo que hicimos para reducir la superficie de ataque. Eliminamos aplicaciones innecesarias en el sistema e implementamos algunas reglas de firewall. Esto ya mantiene muchos invasores lejos.

Los niveles intermedios son todas las capas de seguridad que podemos implementar para garantizar la redundancia del primer nivel.

Si el invasor consigue romper todas las capas ya estará apto para hacer algo. Lo que podemos hacer es garantizar que donde llegó no consiga hacer mucha cosa que vaya a perjudicar el sistema.

Garantizando la seguridad entre los componentes de Kubernetes, aunque el invasor consiga, a través de un pod que ejecuta un contenedor sin límite de permisos, salir de este contenedor para dentro del host, no debe ser capaz de comunicarse con el etcd. En ese punto podemos poner restricción de comunicación y cifrado.

Categorías de Seguridad de K8S​

  • Seguridad del sistema operativo del host. Probablemente es un sistema operativo Linux que ya viene con alguna seguridad implementada.
    • Los nodos de Kubernetes deben ejecutar solamente los componentes de Kubernetes.
    • Reducir la superficie de ataque.
      • Eliminar todas las aplicaciones extras que no son necesarias para ejecutar los componentes de Kubernetes.
    • Mantener todo actualizado.
    • Usar herramientas de seguridad para ayudar.
    • Identificar procesos maliciosos.
    • Restringir accesos de usuarios al host (IAM/SSH).
  • Seguridad del clúster Kubernetes. Esta es la parte de seguridad de los componentes que se ejecutan en el host.
    • Garantizar que los componentes estén ejecutándose de forma segura y actualizados.
      • Apiserver
      • Kubelet
      • ETCD
    • Restringir accesos externos.
    • Confinar la comunicación a través de la red.
      • Los componentes deben comunicarse con los otros que necesitan comunicarse. Por ejemplo el kubelet no necesita comunicarse con el etcd.
    • Usar autenticación -> autorización.
    • Admission controller
      • NodeRestriction
      • Custom Policies (OPA)
    • Activar logs de auditoría.
    • Benchmark de seguridad para darnos recomendaciones
  • Seguridad de las aplicaciones. Es la seguridad que aplicamos en los pods y contenedores que en él se ejecutan.
    • Usar secrets en vez de escribirlas dentro de nuestros contenedores Docker o en los manifiestos.
    • RBAC para control y restricción de acceso.
    • Ejecutar los contenedores del pod en sandbox para crear otra capa de seguridad entre el contenedor y el host.
    • Container Hardening
      • Reducir ataques de superficie en las imágenes base.
      • Ejecutar contenedores como User y no como Root.
      • Readonly filesystem.
      • El contenedor debe ser inmutable durante su ejecución.
    • Scan de vulnerabilidades en las imágenes debe hacerse constantemente.
    • mTLS/Service Meshes garantizando que el tráfico entre nuestras aplicaciones del clúster sea cifrado.

alt text

Los servicios de kubernetes en cloud como por ejemplo EKS, AKS, GKS, etc son responsables de garantizar la seguridad a nivel de host y del clúster, pero la seguridad de nuestras aplicaciones es problema nuestro. Si vamos a montar un clúster autogestionado entonces debemos preocuparnos por todas las categorías y es en eso en lo que se centra el CKS.