Kubernetes es extremadamente popular, pero sin las medidas de seguridad adecuadas, también conlleva riesgos. El experto en seguridad CyberArk nombra tres riesgos específicos y muestra qué medidas defensivas se requieren para controlar los riesgos de hardware, servidor API y contenedor en Kubernetes.
En el desarrollo de software actual, la velocidad y la agilidad son claves. La tecnología de contenedores se utiliza cada vez más. Kubernetes se ha convertido en el estándar de facto para administrar cargas de trabajo y servicios en contenedores.
Aspectos de seguridad de Kubernetes
Desde una perspectiva de seguridad, la plataforma de orquestación de Kubernetes trae consigo desafíos específicos relacionados con la identidad que deben abordarse al principio del proceso de desarrollo. De lo contrario, los entornos en contenedores pueden representar un riesgo para la seguridad de TI. Hay tres áreas principales potencialmente vulnerables dentro de Kubernetes en las que las organizaciones deben centrarse como parte de un verdadero enfoque DevSecOps.
Riesgo de Kubernetes: Hardware
Ya sea que ejecute Kubernetes en las instalaciones o en una nube administrada por un tercero, aún se requiere una plataforma de hardware. Una vez que un atacante tiene acceso a la máquina virtual que ejecuta Kubernetes y obtiene privilegios de raíz, también puede atacar los clústeres de Kubernetes.
Para evitar esto, existen las siguientes mejores prácticas de seguridad:
- Hacer cumplir el principio de privilegio mínimo es crucial para proteger el hardware que subyace tanto en Kubernetes como en los propios contenedores. Las máquinas virtuales deben implementarse con el nivel más bajo de privilegios (es decir, solo aquellos que sean estrictamente necesarios por razones funcionales) para dificultar que los atacantes obtengan acceso de root.
- Las credenciales deben rotarse regularmente, y el uso de una solución de bóveda automatizada tiene sentido para aumentar aún más la protección sin aumentar los gastos generales.
Riesgo de Kubernetes: Servidor API de Kubernetes
Aparte de las máquinas físicas, el plano de control de Kubernetes también debe protegerse. Brinda acceso a todos los contenedores que se ejecutan en un clúster, incluido el servidor API de Kubernetes, que actúa como front-end y facilita la interacción del usuario dentro del clúster.
Un ataque al servidor API puede tener un gran impacto. Incluso un solo secreto o credencial robada puede usarse para escalar los derechos y privilegios de acceso de un atacante. Una vulnerabilidad inicialmente pequeña puede convertirse rápidamente en un problema de toda la red.
Las mejores prácticas de seguridad incluyen:
- Para mitigar el riesgo, las organizaciones primero deben proteger los puntos finales contra el robo de credenciales y las amenazas de malware. Las computadoras locales utilizadas por usuarios con derechos administrativos en Kubernetes son particularmente relevantes.
- La autenticación multifactor (MFA) para acceder a los servidores API de Kubernetes es esencial. Por ejemplo, una credencial robada no se puede usar para acceder a Kubernetes.
- Una vez que los usuarios se autentican en Kubernetes, pueden acceder a todos los recursos dentro del clúster. La gestión de las autorizaciones es, por tanto, de crucial importancia. Con el control de acceso basado en roles, una empresa puede garantizar que los usuarios solo tengan los derechos de acceso que realmente necesitan.
- También se debe aplicar el privilegio mínimo en las cuentas de servicio de Kubernetes, que se crean automáticamente cuando se configura un clúster, para ayudar a autenticar los pods. Igualmente importante es la rotación regular de secretos para eliminar oportunidades de acceso para aquellos que ya no los necesitan.
Riesgo de Kubernetes: Contenedores
Los pods y contenedores son los componentes básicos de un clúster de Kubernetes y contienen la información necesaria para ejecutar la aplicación. Hay varias vulnerabilidades potenciales dentro de este flujo de trabajo y ecosistema de contenedores. Estos incluyen, por ejemplo, el acceso no seguro a la API del contenedor o al host del contenedor y los registros de imágenes desprotegidos.
Se recomiendan las siguientes prácticas recomendadas para la seguridad de los contenedores:
- Los secretos no deben estar incrustados en el código o en una imagen contenedora. De lo contrario, cualquier persona con acceso al código fuente también tiene acceso a la información en los repositorios de código, por ejemplo.
- Los riesgos de seguridad se minimizan significativamente con el control de acceso basado en roles, la restricción del acceso secreto a procesos dentro de un contenedor específico y la eliminación de secretos que ya no son necesarios.
- El uso de secretos, incluida la rotación o la desactivación, debe registrarse. También es ventajosa una solución central de gestión de secretos que permita la administración y protección automáticas de los datos de acceso confidencial.
"Al adoptar estas mejores prácticas, una empresa puede mejorar significativamente la seguridad en todo el entorno de Kubernetes", dijo Michael Kleist, vicepresidente de área de DACH en CyberArk. “Además, también existe la posibilidad de apoyar a los desarrolladores con funciones de autoservicio en su trabajo diario, por ejemplo, con respecto al escaneo de códigos. Esto les permite hacer una contribución adicional para aumentar la seguridad de Kubernetes de manera rápida y conveniente”.
Más en CyberArk.com
Acerca de CyberArk
CyberArk es el líder mundial en seguridad de identidad. Con Privileged Access Management como componente central, CyberArk brinda seguridad integral para cualquier identidad, humana o no humana, en aplicaciones comerciales, entornos de trabajo distribuidos, cargas de trabajo de nube híbrida y ciclos de vida de DevOps.