Las mejores prácticas de seguridad con Kubernetes

En esta nueva entrada de nuestro blog les traemos una guía de prácticas de seguridad que complementa nuestra última entrada sobre “Introducción a Kubernetes - Orquestador de contenedores”, con el objetivo de que su equipo de tenga más claridad sobre las consideraciones de seguridad para el orquestador de contenedores.

Las pautas que acá presentamos son guías referenciales y no deben ser consideradas como la totalidad de las prácticas necesarias en términos de de seguridad:

Escáner de Seguridad Kubernetes con Kube-Bench

Este es un recurso utilizado para eliminar alrededor del 95% de defectos de configuración, generando pautas bastante específicas para garantizar la configuración de su red de computadores mediante la aplicación de kubernetes benchmark. 

Kube Bench es recomendado para ejecucar en primera instancia antes de probar cualquier otro método.

Firewall ports

Esta práctica de seguridad es usada frecuentemente, ya que no es para nada recomendable exponer un puerto que no necesita estar expuesto. Para evitar que esto ocurra, existe un orden ideal para definir la exposición del puerto:

• Lo primero que usted debe hacer es comprobar la existencia  de alguna interfaz o definir una IP para vincular el servicio, en la medida de lo posible 127.0.0.1. Pero en caso de que no sea posible escuchar en una interfaz o IP, debe cortar el puerto.

• Algunos procesos están abriendo tantos puertos en todas las interfaces que más bien deberían contar con un firewall de acceso público. Aunque sólo permiten información netamente confidencial, también le permiten acceso directo a su conjunto de computadores. 

Topología privada

En el caso de que su infraestructura le permitirá tener interfaces de red privadas, es recomendado alojar el cúmulo de servidores en una subred privada y solamente reenviar con puertos desde su clúster hasta la puerta de enlace NAT.

También existe el caso de que pueda estar conectado a través de un proveedor de la nube como Amazon Web Services (AWS). Este procedimiento se logra mediante una VPC (nube virtual privada).

Tablero de Kubernetes

El complemento del tablero en kubernetes ofrece la opción de recibir una cuenta de servicio en la que usted puede visualizar todo el funcionamiento de su red de computadores con un acceso total.

El reto con el tablero o dashboard de Kubernetes está en restringir el acceso público al mismo. En Febrero de 2018 fue ampliamente conocido que la empresa Tesla tenía mal asegurado su tablero de Kubernetes causando que sus recursos fueran usados para minar criptomonedas (cryptojacking).

Puede seguir la guía de Heptio para asegurar el tablero de Kubernetes.

Restringir la "Docker Image Pull"

Docker es un recurso que a veces se puede descontrolar por la facilidad de acceso que tiene. Es decir, cualquier persona con acceso al conector Kubernetes API o Docker, puede obtener la imagen que sea de su gusto, generando un tráfico de imágenes infectadas o con serios problemas de seguridad para Kubernetes.

Incluso muchos clusters ya se han convertido en una red de mineros de Bitcoin. A pesar de que es un problema que parece no poder solucionarse, el plugin de políticas de imagen (Image Policy) puede mejorar considerablemente esa situación, conectándose de forma directa con la API de Docker.

Este plugin impone una serie de reglas estrictas de seguridad en las que se refleja una lista en blanco y negro de las imágenes que se pueden extraer y las que no.

Otra de las soluciones aplicables a estos inconvenientes es el “Image Policy Webhook” a través de “Admission Controller”, el cual intercepta todas las extracciones de imágenes y cuida de la seguridad en la misma manera en que lo hace el plugin mencionado anteriormente.

Bastión Host

Esto se refiere a que no se debe proporcionar acceso al protocolo de administración remota de seguridad (SSH) de manera pública. En vez de eso, puede utilizar una configuración de bastión host que exponga el SSH solamente en un host específico.

También hay formas de fortalecer el protocolo de administración mediante la utilización de otros métodos que usted puede consultar en “Hardening OpenSSH” y en el capítulo de “OpenSSH” de “Applied Crypto Hardening” en bettercrypto.org.

Modo de Autorización API y Autenticación Anónima

El método de autorización AlwaysAllow para el cluster, utilizado por la mayoría de instaladores como kops, siempre permitiría a cualquier entidad que esté autorizada y autenticada un acceso completo al cluster. El caso contrario sucede con el control de acceso basado en roles (RBAC).

Es absolutamente necesario que usted conozca qué modo de autorización está usando su sistema. Esto puede hacerlo verificando los parámetros, en donde también puede revisar que la autenticación no esté configurada de forma anónima. De ser así, puede desactivarla usando “--anonymous-auth = false”.

Es importante que sepa que esto no va a afectar de ninguna manera al modo de autorización kubelet, ya que este expone una API por sí mismo que ejecuta comandos que kubelet puede omitir totalmente.

De forma más específica, kubelet brinda una API de comando utilizada por kubi-apiserver, en la cual se ejecutan los comandos arbitrarios en un nodo específico. Esta configuración se puede diseñar de la siguiente manera: “--authorization-mode = Webhook” y “--anonymous-auth = false”.

Cuenta de Servicio Predeterminada de Montaje Automático

Las cuentas de servicios predeterminadas son una dependencia del controlador de admisión. Este procura que las credenciales de este servicio se puedan visualizar en un sistema de archivo de contenedores ejecutado en el pod, siempre y cuando la función de montaje automático esté activa.

Este token implementado también se utiliza para mostrar la configuración API de Kubernetes.

API de Metadatos de AWS

Esta herramienta es exclusiva para el uso de Amazon Web Services, en la cual se consultan las credenciales de roles de IAM (Identity and Access Management) a través del acceso de firewall a la API de metadatos de EC2 (Amazon Elastic Compute Cloud).

Privilegios de Host del Proveedor de la Nube

Si usted está utilizando su clúster en algún proveedor de la nube (puede ser de AWS), es necesario que sepa que de forma predeterminada los pod heredan privilegios de los nodos de kubernetes. Es por ello que si usted tiene políticas vigentes que permitan que Amazon Elastic Compute Cloud maneje los recursos de su AWS, sepa que el pod también tiene permitido hacerlo.

Utilice las Políticas de Red

Las políticas de red representan una serie de reglas de firewall para kubernetes. Por eso, es bueno que usted consulte las políticas de red de kubernetes para configurarlas correctamente desde un principio.

Consulte la política de red de Kubernetes para obtener un excelente punto de partida. Si su proveedor de red no es compatible con las políticas de red, considere cambiar a una que sí lo haga, consulte.

Si su organización tiene interés en implementar proyectos Cloud de la mano de expertos, lo invitamos a contactarnos.