Fundamentos de la seguridad de contenedores: orquestación

Si acabas de incorporarte a esta serie, quizá te interese empezar por el principio:
Fundamentos de la seguridad de contenedores: Introducción
Fundamentos de la seguridad de contenedores: Canalización

Según el informe de Tripwire sobre el estado de la seguridad de los contenedores en 2019, casi una de cada tres organizaciones (el 32 %) utiliza actualmente más de 100 contenedores en producción. Un porcentaje menor (el 13 %) utiliza más de 500. Y el 6 % de las organizaciones que han apostado decididamente por esta tecnología gestiona actualmente más de 1000. Son pocas las organizaciones que utilizan contenedores a gran escala sin un sistema de orquestación que les ayude.

La capa de orquestación de la seguridad de los contenedores se centra en el entorno responsable del funcionamiento diario de los contenedores. Según los datos disponibles actualmente, si utiliza contenedores, es casi seguro que está aprovechando Kubernetes como orquestador.

Es importante señalar que existen otros orquestadores, pero la mayoría también utilizan componentes y conceptos derivados de Kubernetes. Por lo tanto, nos centraremos en la seguridad de Kubernetes y sus componentes.

El entorno de Kubernetes

Kubernetes está compuesto por múltiples elementos interdependientes. Esto dificulta su protección, no solo por la cantidad de componentes implicados, sino también por la forma en que interactúan entre sí. Algunos se comunican mediante API; otros, a través del sistema de archivos del host. Todos ellos son posibles puntos de entrada al entorno de orquestación que deben protegerse.

Entorno básico de Kubernetes

Un breve resumen de los componentes principales que requieren atención:

• Servidor de API y Kubelet
• Pods
• Etcd

Eso significa que puedes ir a por una taza de café, porque esto te llevará un poco más de tiempo.

1. La autenticación no es opcional

Los lectores más perspicaces observarán que esto les resulta familiar. Puede que hayan oído hablar de ello como la segunda regla de seguridad, también conocida como «Cierra la puerta». Es un tema recurrente en el que seguiremos insistiendo porque a menudo se pasa por alto. Es imprescindible contar con una autenticación robusta. Hemos observado cómo sigue aumentando el número de incidentes de seguridad debidos a malas prácticas de seguridad relacionadas con los contenedores. Y una de las causas habituales es no utilizar autenticación, normalmente en implementaciones en la nube pública.

Exija credenciales robustas y cámbielas con frecuencia. El acceso al servidor de la API (a través de consolas no seguras) puede llevar a una situación de «fin de la partida», ya que permite controlar todo el entorno de orquestación. Esto incluye desplegar pods, cambiar configuraciones y detener o iniciar contenedores. En un entorno de Kubernetes, el servidor de la API es la «API única para gobernarlas a todas» que debe mantenerse fuera del alcance de agentes maliciosos.

Cómo proteger el servidor de la API y Kubelet
Es importante señalar que estas recomendaciones se basan en el modelo de autorización actual de Kubernetes. Consulte siempre la documentación más reciente de la versión que utilice.

• Habilite mTLS en todas partes
  - Dedique una CA a cada servicio: k8s, etcd, aplicaciones
  - Rote los certificados y tenga cuidado con los permisos de las claves privadas en el disco
  
• Vincular únicamente a direcciones seguras
  - Tenga cuidado con las opciones de configuración de la API «insecure-bind-address» e «insecure-port»
  - Aplique esto a _todos_ los servicios (SSH, Vault, etcd)
  
• Deshabilitar la «autenticación anónima»
  - ¿La «autenticación anónima» parece una buena idea?
  - Está deshabilitada de forma predeterminada desde la versión 1.5 y se habilita manualmente con «--anonymous-auth=True»
  
• Habilitar la autorización
  - No utilice “--authorization-mode=AlwaysAllow”
  - El servidor de la API debe tener “--authorization-mode=RBAC,Node”
  - Kubelet debe tener “--authorization-mode=Webhook”
  - Restrinja Kubelet para que solo tenga acceso a los recursos de su propio nodo.
  

Es importante señalar que estas recomendaciones se basan en el modelo de autorización actual de Kubernetes. Consulte siempre la documentación más reciente de la versión que esté utilizando.

• Referencia de autorización de Kubernetes
• Referencia de autenticación y autorización de Kubelet

2. Pods y privilegios

Los pods son conjuntos de contenedores. Son el componente más pequeño de Kubernetes y, dependiendo del complemento de interfaz de red de contenedores (CNI), es posible que, de forma predeterminada, todos los pods puedan comunicarse entre sí. Algunos complementos CNI pueden utilizar «políticas de red» para aplicar restricciones a este comportamiento predeterminado. Es importante tenerlo en cuenta porque los pods pueden programarse en distintos nodos de Kubernetes (análogos a un servidor físico). Además, los pods suelen montar secretos, que pueden ser claves privadas, tokens de autenticación y otra información confidencial. De ahí que se denominen «secretos».

Esto significa que existen varias cuestiones relacionadas con los pods y la seguridad. En F5, cuando empezamos a modelar amenazas, siempre partimos de la premisa de que hay un pod comprometido. Esto se debe a que los pods son el lugar donde se despliegan las cargas de trabajo de las aplicaciones. Dado que estas cargas son las que tienen más probabilidades de estar expuestas a accesos no fiables, también constituyen el punto de vulneración más probable. Esta premisa plantea cuatro preguntas básicas que debemos formularnos para planificar cómo mitigar las posibles amenazas.

1. ¿Qué podría ver o hacer un atacante con otros pods si tuviera acceso a un pod?
2. ¿Puede un atacante acceder a otros servicios del clúster?
3. ¿Qué secretos se montan automáticamente?
4. ¿Qué permisos se han concedido a la cuenta de servicio del pod?

Las respuestas a estas preguntas ponen de manifiesto riesgos que podrían aprovecharse si un atacante obtiene acceso a un pod dentro del clúster. Para mitigar las amenazas derivadas de la vulneración de un pod, se requiere un enfoque multidimensional que incluya opciones de configuración, control de privilegios y restricciones a nivel del sistema. Recuerde que se pueden desplegar varios pods en el mismo nodo (físico o virtual) y que, por tanto, comparten el acceso al sistema operativo, normalmente Linux.

Cómo mitigar las amenazas de los pods
Kubernetes incluye un recurso de política de seguridad de pods que controla aspectos sensibles de un pod. Permite a los operadores definir las condiciones en las que debe funcionar un pod para que se permita su acceso al sistema y establece una base de referencia para el contexto de seguridad del pod. Nunca dé por sentado que la configuración predeterminada es segura. Implemente bases de referencia seguras y compruebe que se cumplen las expectativas para protegerse frente a las amenazas de los pods.

Las opciones específicas de una política de seguridad de pods deben abordar lo siguiente:

• Evite los contenedores con privilegios
  • Busque la opción «—allow-privileged» en kube-api y/o kubelet
  • Busque «privileged: true» en la especificación del pod.
  • Reduce el riesgo de seguridad con «--allow-privileged=false»
• El usuario predeterminado de los contenedores de Docker es root
  • Evita ejecutar cualquier carga de trabajo como root
  • Pod Security Policy puede usar «runAsUser», «runAsGroup» y «runAsNonRoot: true»
  • Se pueden definir opciones similares en un Dockerfile
• Impedir la escalada de privilegios dentro de un contenedor
  • “allowPrivilegeEscalation: false”
• Usa SELinux / AppArmor
  • SELinux utilizará la seguridad multicategoría para aislar los contenedores entre sí
  • Déjelo habilitado y vaya resolviendo las denegaciones
  • Deshabilitarlo o cambiarlo al modo permisivo reduce considerablemente la seguridad
• Evitar ataques mediante enlaces simbólicos o puntos de entrada
  • Los atacantes pueden sobrescribir el binario del punto de entrada o crear enlaces simbólicos maliciosos
  • Evita esto configurando «readOnlyRootFilesystem: true»
• Evita las opciones de configuración host*
  • Los atacantes con acceso a los recursos del host tienen más probabilidades de ampliar su intrusión al propio host o a los contenedores adyacentes
  • Evite opciones como hostPID, hostIPC, hostNetwork y hostPorts
• Montajes hostPath de solo lectura
  • Si es necesario configurar el acceso de lectura y escritura en el host, tenga cuidado con el despliegue y, desde luego, no lo convierta en una práctica predeterminada.
  • Usa «readOnly» en todas las rutas allowedHostPaths para evitar ataques
• Perfiles de seccomp
  • Reduzca la superficie de ataque limitando las llamadas al sistema permitidas
  • La configuración predeterminada de Docker reducirá algunos riesgos, pero es un perfil genérico
  • Los perfiles específicos de cada aplicación proporcionarán el mayor nivel de seguridad

3. Etcd

Etcd es el almacén de la configuración y los secretos. Si se ve comprometido, podría permitir la extracción de datos confidenciales o la inyección de datos maliciosos. Ninguna de las dos cosas es buena. Para mitigar las amenazas a etcd, es necesario controlar el acceso. La mejor forma de hacerlo es aplicar mTLS. Kubernetes almacena los secretos en etcd codificados en base64. Considere el uso de una funcionalidad alfa, «proveedor de cifrado», para disponer de opciones más robustas al almacenar secretos confidenciales, o bien considere utilizar HashiCorp Vault.

Lee el siguiente artículo de la serie:
Conceptos básicos de seguridad de contenedores: cargas de trabajo