Conceptos básicos de seguridad de los contenedores: orquestación

Si recién te estás iniciando en esta serie, quizá quieras empezar por el principio: 
Conceptos básicos de seguridad de contenedores: Introducción
Conceptos básicos de seguridad de contenedores: Tubería

Según el informe State of Container Security de Tripwire de 2019 , aproximadamente una de cada tres organizaciones (32 %) opera actualmente más de 100 contenedores en producción. Un porcentaje menor (13%) opera más de 500. Y el 6% de los adoptantes verdaderamente entusiastas actualmente gestionan más de 1000. Hay pocas organizaciones que operan contenedores a gran escala sin un sistema de orquestación que las 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 hoy, si usa contenedores, es casi seguro que está aprovechando Kubernetes como orquestador.

Es importante tener en cuenta que existen otros orquestadores, pero la mayoría de ellos también aprovechan componentes y conceptos derivados de Kubernetes. Por lo tanto, nos centraremos en la seguridad de Kubernetes y sus componentes.

El entorno de Kubernetes

Hay múltiples partes móviles que componen Kubernetes. Esto hace que sea más difícil protegerlo no solo por la cantidad de componentes involucrados, sino por la forma en que esos componentes interactúan. Algunos se comunican mediante la API. Otros mediante el sistema de archivos del host. Todos son puntos de entrada potenciales al entorno de orquestación que deben abordarse. 

Entorno básico de Kubernetes

Una descripción rápida de los componentes principales que requieren atención:

• Servidor API y Kubelet
• Vainas
• Etc.

Eso significa tomar una taza de café, esto va a llevar un poco más de tiempo terminarlo.

1.La autenticación no es opcional

Los lectores astutos notarán que esto les suena familiar. Es posible que hayas oído hablar de ella como Regla de seguridad dos, también conocida como Cierre la puerta. Es un tema común que seguiremos repitiendo porque a menudo se ignora. La autenticación fuerte es imprescindible. Hemos observado cómo el número de incidentes de seguridad debidos a malas prácticas de seguridad con respecto a los contenedores continúa aumentando. Y una de las fuentes más comunes es la falta de uso de la autenticación, generalmente cuando se implementa en la nube pública.

Exigir credenciales sólidas y rotar con frecuencia. El acceso al servidor API (a través de consolas no seguras) puede llevar a una situación de “fin del juego” porque todo el entorno de orquestación se puede controlar a través de él. Eso significa implementar pods, cambiar configuraciones y detener/iniciar contenedores. En un entorno de Kubernetes, el servidor API es la “única API para gobernarlos a todos” que desea mantener fuera del alcance de actores maliciosos.

Cómo proteger el servidor API y Kubelet
Es importante tener en cuenta 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.

• Habilitar mTLS en todas partes
  - Dedicar una CA por servicio: k8s, etcd, aplicações
  - Rote los certificados y tenga cuidado con los permisos de clave privada en el disco
  
• Vincular únicamente a direcciones seguras
  - Tenga cuidado con la configuración de API “insecure-bind-address” y “insecure-port”
  - Aplicar esto a _todos_ los servicios (SSH, Vault, etc.)
  
• Desactivar la “Autenticación anónima”
  - ¿Te parece una buena idea la “autenticación anónima”?
  - Deshabilitado de forma predeterminada a partir de la versión 1.5, habilitado manualmente con “--anonymous-auth=True”
  
• Habilitar autorización
  - No utilice “--authorization-mode=AlwaysAllow”
  - El servidor API debe tener “--authorization-mode=RBAC,Node”
  - Kubelet debería tener “--authorization-mode=Webhook”
  - Restrinja Kubelet para que solo tenga acceso a los recursos en su propio nodo.
  

Es importante tener en cuenta que estas recomendaciones se basan en el modelo de autorización actual de Kubernetes. Consulte siempre la documentación más reciente para 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 

Las vainas son una colección de contenedores. Son los componentes más pequeños de Kubernetes y, según el complemento Container Network Interface (CNI), todos los pods pueden comunicarse entre sí de forma predeterminada. Hay complementos CNI que pueden usar “Políticas de red” para implementar restricciones en este comportamiento predeterminado. Es importante tener esto en cuenta porque los pods se pueden programar en diferentes nodos de Kubernetes (que son análogos a un servidor físico). Los pods también suelen montar secretos, que pueden ser claves privadas, tokens de autenticación y otra información confidencial. De ahí la razón por la que se llaman “secretos”.

Esto significa que existen varias preocupaciones con los pods y la seguridad. En F5, siempre asumimos que hay un pod comprometido cuando comenzamos a modelar amenazas. Esto se debe a que los pods son donde se implementan las cargas de trabajo de las aplicação . Debido a que las cargas de trabajo de las aplicação son las que tienen más probabilidades de estar expuestas a accesos no confiables, son el punto de compromiso más probable. Esa suposición nos lleva a plantearnos cuatro preguntas básicas para planificar cómo mitigar las amenazas potenciales. 

1. ¿Qué podría ver o hacer un atacante con otros pods a los que se les da 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 otorgado a la cuenta de servicio del pod?

Las respuestas a estas preguntas exponen riesgos que podrían aprovecharse si un atacante obtiene acceso a un pod dentro del clúster. Para mitigar las amenazas de vulneración de pods se requiere un enfoque multifacético que involucra opciones de configuración, control de privilegios y restricciones a nivel del sistema. Recuerde que se pueden implementar varios pods en el mismo nodo (físico o virtual) y, por lo tanto, compartir el acceso al sistema operativo, generalmente un sistema operativo Linux.

Cómo mitigar las amenazas de Pod
Kubernetes incluye un recurso de política de seguridad de pod que controla los aspectos confidenciales de un pod. Permite a los operadores definir las condiciones bajo las cuales debe operar un pod para poder ingresar al sistema y aplica una línea base para el contexto de seguridad del pod. Nunca asuma que los valores predeterminados son seguros. Implemente líneas de base seguras y verifique las expectativas para protegerse contra amenazas de pods.

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

• Evite los contenedores privilegiados
  • Busque la configuración “—allow-privileged” en kube-api y/o kubelet
  • Busque “privileged: true” en la especificación del pod.
  • Reducir el riesgo de seguridad con “--allow-privileged=false”
• El usuario del contenedor predeterminado con Docker es root
  • Evite ejecutar cualquier carga de trabajo como root
  • La política de seguridad del pod puede usar “runAsUser”, “runAsGroup” y “runAsNonRoot: true”
  • Se pueden definir opciones similares en un Dockerfile
• No permitir la escalada de privilegios dentro de un contenedor
  • “permitirEscalamientoDePrivilegios: falso”
• Utilice SELinux / AppArmor
  • SELinux utilizará seguridad de múltiples categorías para confinar los contenedores entre sí
  • Dejar habilitado y trabajar con las denegaciones
  • Deshabilitar o cambiar al modo permisivo reduce gravemente la seguridad.
• Prevenir ataques de enlace simbólico/punto de entrada
  • Los atacantes pueden sobrescribir el binario del punto de entrada o crear enlaces simbólicos incorrectos.
  • Evite esto configurando “readOnlyRootFilesystem: true”
• Evitar las opciones de configuración del host*
  • Es más probable que los atacantes con acceso a los recursos del host profundicen su compromiso en el host y/o los contenedores adyacentes.
  • Evite opciones como hostPID, hostIPC, hostNetwork, hostPorts
• montajes de hostPath de solo lectura
  • Si es necesario configurar la lectura/escritura en el host, tenga cuidado con la implementación y ciertamente no haga de esto una práctica predeterminada.
  • Utilice “readOnly” en todos los HostPaths permitidos para evitar ataques
• Perfiles Seccomp
  • Reducir la superficie de amenaza limitando las llamadas al sistema permitidas
  • El valor predeterminado de Docker reducirá algunos, pero es un perfil genérico.
  • Los perfiles específicos de la aplicação proporcionarán el mayor beneficio de seguridad

3.Etc.

Etcd es el almacén de configuraciones y secretos. El compromiso aquí puede permitir la extracción de datos confidenciales o la inyección de datos maliciosos. Ninguno es bueno Mitigar las amenazas a etcd significa controlar el acceso. La mejor manera de lograrlo es aplicando mTLS . Kubernetes almacena los secretos en etcd codificados en base64. Considere el uso de una función alfa, “proveedor de cifrado” , para obtener opciones más sólidas al almacenar secretos confidenciales o considere usar HashiCorp Vault.

Lea el siguiente blog de la serie: 
Conceptos básicos de seguridad de contenedores: Carga de trabajo