Entender los estándares de seguridad de Pods de Kubernetes
20 de junio de 2023
0 minutos de lecturaKubernetes “superó la brecha de adopción” en 2021, después de que 5.6 millones de desarrolladores lo usaran para orquestar sus contenedores, según Cloud Native Computing Foundation (CNCF). La encuesta anual de CNCF registró que un impresionante 96 % de las organizaciones estaba considerando Kubernetes o ya lo usaba.
Sin embargo, Kubernetes resulta más atractivo para los hackers y otros actores maliciosos a medida que gana popularidad. A medida que los desarrolladores adoptan Kubernetes como su plataforma preferida para la orquestación de contenedores, también deben asegurarse de usarla de forma segura.
Los estándares de seguridad de Pods de Kubernetes son una forma clave de mantener la seguridad de Kubernetes. Incluyen tres políticas acumulativas, desde medidas de seguridad totalmente estrictas hasta otras bastante flexibles. Profundicemos en qué son los estándares de seguridad de Pods de Kubernetes, examinemos cómo el controlador de admisión Pod Security los aplica y exploremos casos de uso para cada política.
¿Qué son los estándares de seguridad de Pods de Kubernetes?
Los estándares de seguridad de Pods de Kubernetes son políticas y pautas para mantener la seguridad y la integridad de los contenedores en los clústeres de Kubernetes. Los estándares definen tres perfiles con distintos niveles de restricción para garantizar que las cargas de trabajo en contenedores estén protegidas contra las escaladas de privilegios conocidas y cumplan con las prácticas recomendadas actuales para reforzar la seguridad de los Pods:
Privileged: ofrece una política sin restricciones.
Baseline: ofrece medidas de protección con restricciones mínimas y evita las escaladas de privilegios conocidas.
Restricted: sigue las prácticas recomendadas actuales para reforzar la seguridad de los Pods, pero puede limitar la compatibilidad.
Cumplir con estos estándares ayuda a garantizar que las aplicaciones en contenedores satisfagan los requisitos de seguridad estándar del sector en entornos de Kubernetes. Para lograrlo, Kubernetes ofrece un controlador de admisión Pod Security integrado que verifica los niveles de aislamiento de los Pods con respecto a estos estándares de seguridad.
En versiones anteriores de Kubernetes, esa función correspondía a PodSecurityPolicy. Sin embargo, Kubernetes dejó de admitir esta función en la versión 1.21 y la eliminó por completo en la versión 1.25. En una publicación de blog, Kubernetes SIG Security explicó que el controlador de admisión original tenía “graves problemas de usabilidad”. PodSecurityPolicy era confuso, podía conceder por error permisos más amplios de lo previsto y dificultaba determinar qué permisos se aplicaban en una situación específica. Adaptar PodSecurityPolicy para resolver estos problemas habría sido un proyecto complejo que podría haber interrumpido otras funciones, por lo que se dejó de admitir y se reemplazó.
Los estándares de seguridad de Pods se basan en los niveles estándar de la obsoleta PodSecurityPolicy, lo que simplifica la transición para los sistemas heredados que la usan. El controlador de admisión Pod Security integrado aplica esos estándares en los clústeres o espacios de nombres.
Cómo trabajar con el controlador de admisión Pod Security
Una vez que habilitamos el controlador de admisión Pod Security e instalamos el webhook, podemos configurar el modo de control de admisión en nuestros espacios de nombres:
Enforce: rechaza los Pods que infringen las políticas.
Audit: permite los Pods que infringen las políticas, pero agrega una anotación de auditoría al registro del evento de auditoría.
Warn: permite los Pods que infringen las políticas, pero muestra advertencias a los usuarios.
Para configurar el controlador de admisión Pod Security, hay que identificar dos etiquetas:
Level: Privileged, baseline o restricted.
Mode: enforce, audit o warn.
Del mismo modo, podemos establecer varias comprobaciones de seguridad en cualquier espacio de nombres. También podemos especificar la versión y hacer la comprobación con la política incluida en esa versión secundaria específica de Kubernetes.
Por ejemplo, si queremos saber si el espacio de nombres “my-namespace” no cumple con la versión más reciente del nivel baseline de los estándares de seguridad de Pods, podemos configurar esta advertencia:
Y si queremos aplicar la seguridad del nivel “baseline”, pero recibir notificaciones en los registros para auditar el nivel de seguridad y comprobar si podemos cumplir con el estándar del nivel Restricted, podemos configurarlo así:
Uso del perfil de seguridad Privileged
Como el perfil de seguridad Privileged permite las escaladas de privilegios conocidas, debemos usarlo solo en casos de uso limitados en los que únicamente usuarios de confianza ejecuten cargas de trabajo de infraestructura crítica.
El perfil de políticas Privileged de los estándares de seguridad de Pods de Kubernetes ofrece permisos sin restricciones, necesarios para administrar cargas de trabajo sensibles con la flexibilidad de realizar tareas complejas en sistemas críticos. Por ejemplo, imaginemos una organización que administra información financiera sensible. En este caso, los usuarios privilegiados y de confianza deben administrar las cargas de trabajo de sistemas e infraestructura de la organización para garantizar su seguridad.
Aunque este tipo de acceso a veces es necesario, la organización solo debe conceder acceso abierto a los usuarios que realmente lo necesiten como parte de sus funciones. Al adoptar un enfoque más flexible, como el perfil Privileged, es fundamental limitar el alcance de los permisos.
Al usar un perfil de seguridad Privileged, también es importante incluir los modos de advertencia y auditoría del nivel Restricted del controlador de admisión Pod Security. Este enfoque advierte activamente a los usuarios sobre el estado de cada acción y agrega anotaciones de auditoría a todas las entradas relevantes de los registros de eventos.
Por último, es fundamental implementar otras prácticas recomendadas que vayan más allá de las medidas específicas para Pods. Por ejemplo, podrías exigir autenticación multifactor (MFA) para mitigar los posibles riesgos de conceder permisos amplios.
Uso del perfil de seguridad Baseline
La política Baseline es ideal para operadores de aplicaciones y desarrolladores de aplicaciones no críticas que quieren proteger su entorno sin volverlo demasiado complejo. La política Baseline permite administrar las cargas de trabajo habituales en contenedores y, al mismo tiempo, protege contra las escaladas de privilegios conocidas.
Por ejemplo, imaginemos que nuestra organización de ejemplo ejecuta varios microservicios no críticos en su infraestructura para respaldar sus operaciones comerciales. El perfil de políticas Baseline ayuda a proteger estas cargas de trabajo sin exigir un esfuerzo adicional significativo a los operadores de aplicaciones o desarrolladores. La organización limita los posibles riesgos al implementar esta medida de seguridad con restricciones mínimas, que impide que los atacantes maliciosos obtengan privilegios elevados mediante vulnerabilidades en imágenes de contenedores u otros vectores de ataque.
Supongamos que la organización de ejemplo utiliza el servicio de un proveedor externo que requiere acceso de solo lectura a los datos almacenados en los clústeres de Kubernetes. La política de seguridad de Pods Baseline restringe el acceso privilegiado que exceda las necesidades del proveedor y deniega los intentos no autorizados del proveedor (o de cualquier otra persona) de elevar sus permisos por encima de los requisitos del nivel baseline.
El perfil de seguridad Baseline también ofrece flexibilidad a las organizaciones con cargas de trabajo estándar, incluidas las API y las aplicaciones web. Estas organizaciones no necesitarán medidas de configuración adicionales, a menos que las consideren necesarias después de realizar más pruebas y análisis.
Es importante tener en cuenta que el perfil de seguridad Baseline es intencionalmente genérico para abarcar una amplia variedad de cargas de trabajo. Por eso, suele incluir restricciones poco útiles para casos de uso específicos. En lugar de usar de forma predeterminada el perfil Privileged, ya que conceder acceso root generalizado sería inseguro, probablemente tendrás que configurar controles específicos para cada aplicación según tu caso de uso.
Uso del perfil de seguridad Restricted
El perfil de políticas Restricted es el más seguro de los tres, ya que aplica las prácticas recomendadas actuales para reforzar la seguridad de los Pods.
Supongamos que nuestra organización de ejemplo implementa varias cargas de trabajo en contenedores para procesar transacciones financieras sensibles. Sin embargo, también tiene sistemas heredados que ejecutan aplicaciones no basadas en contenedores y que no siguen los estándares de seguridad modernos. La política de seguridad de Pods Restricted garantiza que todos los contenedores cumplan con las prácticas recomendadas, que incluyen el aislamiento en sandbox, la restricción de cuentas de usuario y el control de los privilegios de red.
Con el perfil de seguridad Restricted, los operadores de aplicaciones y desarrolladores de aplicaciones críticas para la seguridad pueden garantizar, entre otras medidas, que:
Todos los contenedores que se ejecutan dentro de un Pod sean de solo lectura.
Las capacidades de Linux se limiten a las necesarias para el funcionamiento del contenedor.
El nombre de host de cada contenedor se establezca explícitamente mediante una variable de entorno.
Al crear Pods, se especifiquen los recursos que consume cada proceso del contenedor, como la CPU y la memoria.
El perfil de políticas seguro Restricted ofrece mayor visibilidad de las posibles superficies de ataque, especialmente a las organizaciones que gestionan cargas de trabajo vulnerables. La política aplica las prácticas recomendadas actuales para reforzar la seguridad de los Pods y ayudar a protegerlos contra escaladas de privilegios y otras actividades maliciosas.
Puedes aumentar la seguridad mediante mecanismos de protección por capas que actúen desde distintos puntos, como reducir las funciones innecesarias de las aplicaciones que no sean esenciales y emplear capacidades avanzadas de mitigación de amenazas.
Cómo trabajar con los estándares de seguridad de Pods
Los estándares de seguridad de Pods de Kubernetes ayudan a los desarrolladores a proteger sus aplicaciones en contenedores en el entorno de Kubernetes. Los tres perfiles de seguridad —Privileged, Baseline y Restricted— tienen distintos niveles de restricción según las necesidades de los usuarios. El controlador de admisión Pod Security habilita estos estándares en los clústeres o espacios de nombres mediante la aplicación de políticas, la auditoría o las advertencias, según el nivel seleccionado. También permite especificar una versión, si lo deseas.
Las organizaciones pueden usar los estándares de seguridad de Pods para garantizar el cumplimiento de los requisitos de seguridad estándar del sector y protegerse contra posibles escaladas de privilegios y otras actividades maliciosas. En definitiva, aplicar los estándares de seguridad de Pods mediante el controlador de admisión Pod Security simplifica el proceso de desarrollo y protege todas las cargas de trabajo que se ejecutan en los clústeres de Kubernetes.
Una vez que hayas configurado los estándares de seguridad de Pods en Kubernetes, descubre cómo Snyk Container te ayuda a encontrar y corregir vulnerabilidades en contenedores durante todo el proceso de desarrollo, con información y recomendaciones para mantener seguros tus contenedores.
Seguridad de contenedores centrada en los desarrolladores
Snyk encuentra y corrige automáticamente vulnerabilidades en imágenes de contenedores y cargas de trabajo de Kubernetes.
