Este documento ha sido traducido utilizando tecnología de traducción automática. Si bien nos esforzamos por proporcionar traducciones precisas, no ofrecemos garantías sobre la integridad, precisión o confiabilidad del contenido traducido. En caso de discrepancia, la versión original en inglés prevalecerá y constituirá el texto autorizado.

SUSE Rancher Prime Mejores Prácticas de Seguridad

Restringir el acceso público a la ruta /version y /rancherversion

La instancia de Rancher (local) upstream proporciona información sobre la versión de Rancher que está ejecutando y la versión de Go que se utilizó para construirla. Esa información es accesible a través de la ruta /version, que se utiliza para tareas como automatizar incrementos de versión o confirmar que un despliegue fue exitoso. La instancia upstream también proporciona información sobre la versión de Rancher accesible a través de la ruta /rancherversion.

Los adversarios pueden abusar de esta información para identificar la versión de Rancher en ejecución y relacionarla con posibles errores a explotar. Si tu instancia de Rancher upstream está disponible públicamente en la web, utiliza un firewall de Capa 7 para bloquear /version y /rancherversion.

Consulta OWASP Web Application Security Testing - Enumerar Infraestructura y Interfaces de Administración de Aplicaciones para más información sobre cómo proteger tu servidor.

Gestión de las sesiones

Algunos entornos pueden requerir controles de seguridad adicionales para la gestión de sesiones. Por ejemplo, puede que desees limitar las sesiones activas concurrentes de los usuarios o restringir desde qué geolocalizaciones se pueden iniciar esas sesiones. Tales características no son compatibles con Rancher de forma predeterminada.

Si requieres tales características, combina firewalls de Capa 7 con proveedores de autenticación externa.

Utiliza Balanceadores de Carga Externos para Proteger Puertos Vulnerables

Deberías proteger los siguientes puertos detrás de un balanceador de carga externo que tenga habilitada la descarga de SSL:

  • K3s: Puerto 6443, utilizado por la API de Kubernetes.

  • RKE2: El puerto 6443, utilizado por la API de Kubernetes, y el puerto 9345, utilizado para el registro de nodos.

Estos puertos tienen certificados TLS SAN que enumeran las direcciones IP públicas de los nodos. Un atacante podría utilizar esa información para obtener acceso no autorizado o monitorear la actividad en el clúster. Proteger estos puertos ayuda a mitigar el riesgo de que las direcciones IP públicas de los nodos sean divulgadas a posibles atacantes.

Política de Nombre de Usuario de Rancher

Por defecto, Kubernetes no proporciona mecanismos de aplicación para políticas básicas de nombres de usuario. En Rancher, esto significa que cualquier aplicación de formatos de nombres de usuario, convenciones de nomenclatura o políticas básicas se espera que sea manejada por las políticas del proveedor de identidad externo, si tales políticas están en vigor.

En Rancher, admin es el nombre de usuario predeterminado para el usuario administrador, como se destaca aquí

Ejemplos de políticas básicas potenciales incluyen:

  • Requerir que los nombres de usuario sigan una convención organizativa (por ejemplo, firstname.lastname)

  • Aplicar requisitos de longitud mínima o máxima

  • Prohibir ciertos caracteres especiales

  • Prevenir la suplantación prohibiendo nombres reservados (por ejemplo, admin, root)

Sin estos controles en la capa del proveedor de identidad, existe un riesgo de prácticas de nombres de usuario inconsistentes o inseguras, lo que puede complicar las auditorías de acceso y llevar a intentos de escalada de privilegios.

Rancher actualmente aplica solo un longitud mínima de contraseña.

Recomendación: Recomendamos encarecidamente que los clientes:

  • Revisen y configuren las políticas básicas de nombres de usuario directamente en sus proveedores de identidad externos (por ejemplo, LDAP, Active Directory, SAML o OIDC).

  • Aseguren que esas políticas se alineen con los requisitos de seguridad y cumplimiento de la organización.

  • Auditen regularmente las cuentas de usuario para detectar inconsistencias en los nombres o violaciones de políticas.

Para obtener más información, consulte:

Reglas de WAF

Rancher está diseñado para soportar una amplia gama de escenarios de despliegue, incluyendo entornos donde los clientes pueden automatizar programáticamente la creación o aprovisionamiento de un gran número de clústeres. Imponer límites estrictos a nivel de aplicación dentro de Rancher podría interferir con cargas de trabajo legítimas que requieren escalado dinámico.

Por ejemplo:

  • Las canalizaciones de CI/CD pueden crear y desmantelar clústeres con frecuencia.

  • Los portales de autoservicio podrían aprovisionar clústeres bajo demanda para los desarrolladores.

  • Los entornos de prueba pueden generar altos volúmenes de llamadas a la API.

Riesgo: Sin un límite de tasa apropiado, los adversarios podrían explotar puntos finales no autenticados o autenticados para:

  • Agotar recursos (Denegación de Servicio).

  • Inflar los costos de almacenamiento.

  • Degradar el rendimiento para los usuarios legítimos.

Recomendación: La forma más efectiva de mitigar este riesgo es implementar límites de tasa y protección contra abusos en la infraestructura o en la capa del Cortafuegos de Aplicaciones Web (WAF). Este enfoque permite ajustar los umbrales para el uso y las características de escalado esperadas de cada entorno. Algunos ejemplos de controles pueden ser:

  • Configurar un Cortafuegos de Aplicaciones Web o una Puerta de Enlace de API para hacer cumplir límites de tasa en operaciones sensibles, como la creación y aprovisionamiento de clústeres.

  • Definir umbrales basados en las expectativas de carga de trabajo base (por ejemplo, solicitudes máximas por minuto por cliente).

  • Monitorear registros y alertar sobre anomalías para detectar posibles abusos.

  • Aplicar una cuota de recursos, que es una característica de Rancher que limita los recursos disponibles para un proyecto o espacio de nombres.

Para obtener más información, consulte:

Política de Nombre de Usuario de Rancher

Por defecto, Kubernetes no proporciona mecanismos de aplicación para políticas básicas de nombres de usuario. En Rancher, esto significa que cualquier aplicación de formatos de nombres de usuario, convenciones de nomenclatura o políticas básicas se espera que sea gestionada por las políticas del proveedor de identidad externo, si tales políticas están en vigor.

En Rancher, admin es el nombre de usuario predeterminado para el usuario administrador, como se destaca aquí

Ejemplos de políticas básicas potenciales incluyen:

  • Requerir que los nombres de usuario sigan una convención organizativa (por ejemplo, firstname.lastname)

  • Aplicar requisitos de longitud mínima o máxima

  • Prohibir ciertos caracteres especiales

  • Prevenir la suplantación prohibiendo nombres reservados (por ejemplo, admin, root)

Sin estos controles en la capa del proveedor de identidad, existe un riesgo de prácticas de nombres de usuario inconsistentes o inseguras, lo que puede complicar las auditorías de acceso y llevar a intentos de escalada de privilegios.

Rancher actualmente aplica solo un longitud mínima de contraseña.

Recomendación: Recomendamos encarecidamente que los clientes:

  • Revisar y configurar las políticas básicas de nombres de usuario directamente en sus proveedores de identidad externos (por ejemplo, LDAP, Active Directory, SAML o OIDC).

  • Asegurar que esas políticas se alineen con los requisitos de seguridad y cumplimiento de la organización.

  • Auditar regularmente las cuentas de usuario para detectar inconsistencias en los nombres o violaciones de políticas.

Para obtener más información, consulte:

Reglas de WAF

Rancher está diseñado para admitir una amplia gama de escenarios de despliegue, incluyendo entornos donde los clientes pueden automatizar programáticamente la creación o aprovisionamiento de un gran número de clústeres. Imponer límites estrictos a nivel de aplicación dentro de Rancher podría interferir con cargas de trabajo legítimas que requieren escalado dinámico.

Por ejemplo:

  • Las canalizaciones de CI/CD pueden crear y desmantelar clústeres con frecuencia.

  • Los portales de autoservicio podrían aprovisionar clústeres bajo demanda para los desarrolladores.

  • Los entornos de prueba pueden generar altos volúmenes de llamadas a la API.

Riesgo: Sin un límite de tasa apropiado, los adversarios podrían explotar puntos finales no autenticados o autenticados para:

  • Agotar recursos (Denegación de Servicio).

  • Inflar los costos de almacenamiento.

  • Degradar el rendimiento para los usuarios legítimos.

Recomendación: La forma más efectiva de mitigar este riesgo es implementar límites de tasa y protección contra abusos en la infraestructura o en la capa del Cortafuegos de Aplicaciones Web (WAF). Este enfoque permite ajustar los umbrales para el uso y las características de escalado esperadas de cada entorno. Algunos ejemplos de controles pueden ser:

  • Configurar un Cortafuegos de Aplicaciones Web o una puerta de enlace de API para hacer cumplir límites de tasa en operaciones sensibles, como la creación y aprovisionamiento de clústeres.

  • Definir umbrales basados en las expectativas de carga de trabajo base (por ejemplo, solicitudes máximas por minuto por cliente).

  • Monitorear registros y alertar sobre anomalías para detectar posibles abusos.

  • Aplicar una cuota de recursos, que es una característica de Rancher que limita los recursos disponibles para un proyecto o espacio de nombres.

Para obtener más información, consulte: