Factores de amenaza de Kubernetes administrado

Completado

En un entorno de Kubernetes administrado, abordar la seguridad implica comprender y mitigar las amenazas en varias instancias. A continuación, mostramos un desglose de los factores de amenaza en instancias específicas:

Cuenta en peligro

  • Factor de amenaza: un atacante obtiene acceso a un clúster de Kubernetes mediante credenciales robadas, tokens de API o claves. Esto puede provocar el acceso no autorizado, el robo de datos y las implementaciones malintencionadas.
  • Mitigación: Implemente mecanismos de autenticación seguros, autenticación multifactor (MFA), rotación regular de credenciales y principios de acceso con privilegios mínimos.

Imágenes vulnerables o mal configuradas

  • Factor de amenaza: los atacantes pueden aprovechar las imágenes de contenedor con vulnerabilidades o configuraciones incorrectas una vez implementadas. Estas vulnerabilidades podrían incluir software obsoleto, configuraciones predeterminadas no seguras o secretos incrustados.
  • Mitigación: usa herramientas de análisis de imágenes para detectar vulnerabilidades antes de la implementación, aplica directivas de procedencia de imágenes y adopta un proceso de firma de imágenes de contenedor.

Configuración incorrecta del entorno

  • Factor de amenaza: configuraciones incorrectas en la configuración de Kubernetes o los descriptores de implementación pueden exponer los clústeres a ataques. Entre los problemas comunes se incluyen las interfaces de panel expuestas, configuración de RBAC excesivamente permisiva y puntos de conexión no seguros.
  • Mitigación: sigue los procedimientos recomendados para una configuración segura, audita periódicamente las configuraciones con herramientas automatizadas y emplea controladores de admisión para aplicar el cumplimiento de directivas.

Nivel de ataque de las aplicaciones

  • Factor de amenaza: las aplicaciones que se ejecutan en contenedores pueden ser vulnerables a vectores de ataque web tradicionales, como la inyección de código SQL o el scripting entre sitios (XSS), lo que puede poner en peligro el contenedor o provocar una mayor explotación del clúster.
  • Mitigación: Use procedimientos recomendados de seguridad de aplicaciones, como la validación de entrada y la codificación de salida, y use firewalls de aplicaciones web (WAF). Implemente la seguridad en la canalización de integración continua (CI)/entrega continua o implementación (CD), incluidas las herramientas de análisis estático y dinámico.

Ataque de nivel de nodo

  • Factor de amenaza: si un atacante obtiene acceso a un nodo de Kubernetes, puede escalar potencialmente los privilegios para controlar todo el clúster. Las vulnerabilidades pueden surgir de sistemas operativos obsoletos o componentes de Kubernetes.
  • Mitigación: mantén los nodos actualizados con las revisiones de seguridad más recientes, restringe el acceso a los nodos mediante directivas de red y firewalls, y emplea sistemas de detección de intrusiones (HIDS) basados en host.

Tráfico no autorizado

  • Factor de amenaza: el acceso no autorizado al clúster o desde el clúster puede producirse si las directivas de red no están configuradas correctamente, lo que permite a los atacantes filtrar datos, enviar malware o aprovechar los servicios expuestos.
  • Mitigación: implementa directivas de red estrictas para controlar el tráfico de entrada y de salida, separa las cargas de trabajo confidenciales mediante espacios de nombres y supervisa el tráfico para buscar patrones anómalos.

Hacer frente a estas amenazas en un entorno de Kubernetes administrado requiere un enfoque de seguridad en capas que abarque tanto las prácticas específicas de Kubernetes como las medidas de seguridad tradicionales. La supervisión continua, las auditorías periódicas y el cumplimiento del principio de privilegios mínimos en todos los aspectos del clúster son componentes esenciales de una sólida estrategia de seguridad de Kubernetes.

Diagrama que muestra un ejemplo de los factores de amenaza de Kubernetes administrados.

Técnicas de ataque comunes

  • Aprovechar imágenes vulnerables: una aplicación vulnerable de acceso público en un clúster que permite el acceso inicial al clúster. Casos infames: SolarWinds, Log4j
  • Acceso a aplicaciones expuestas: una interfaz confidencial expuesta a Internet supone un riesgo de seguridad. Algunos marcos populares no estaban diseñados para exponerse a Internet y, por lo tanto, no requieren autenticación de forma predeterminada. Por lo tanto, exponerlos a Internet permite el acceso no autenticado a una interfaz confidencial que podría habilitar la ejecución de código o la implementación de contenedores en el clúster por parte de un actor malintencionado. Algunos ejemplos de estas interfaces que se han visto explotadas son Apache NiFi, Kubeflow, Argo Workflows, Weave Scope y el panel de Kubernetes.
  • Implementación de contenedores de puerta trasera: los atacantes ejecutan su código malintencionado en un contenedor del clúster. Mediante el uso de los controladores de Kubernetes, como DaemonSets o Deployments, los atacantes se aseguraron de que un número constante de contenedores se ejecuten en uno o en todos los nodos del clúster.
  • Aprovechamiento de una cuenta de servicio (SA) con roles demasiado permisivos: la SA representa una identidad de aplicación en Kubernetes. De forma predeterminada, una SA se monta en todos los pods creados del clúster. Con la SA, los contenedores del pod pueden enviar solicitudes al servidor de API de Kubernetes. Los atacantes que obtienen acceso a un pod acceden al token de SA y realizan acciones en el clúster, según los permisos de SA. Si RBAC no está habilitado, la SA tiene permisos ilimitados en el clúster. Si RBAC está habilitado, sus permisos se determinan mediante RoleBindings y ClusterRoleBindings que están asociados a él.
  • Escape al host : el volumen hostPath monta un directorio o un archivo del host en el contenedor. Los atacantes que tienen permisos para crear un nuevo contenedor en el clúster pueden crear uno con un volumen hostPath grabable y obtener persistencia en el host subyacente. Por ejemplo, esto último se puede lograr mediante la creación de un trabajo cron en el host.

Diagrama que muestra un ejemplo de técnicas de ataque comunes de Kubernetes.