Hoy hablamos de seccomProfile, (acrónimo elegido de Secure Computing), que implementa parte de la seguridad de los procesos Linux, para filtrar las llamadas al sistema de los contenedores en función de las reglas definidas. Se introdujo en la versión v1.19 a través de la definición de los securityContext, desactivado por defecto para dar compatibilidad a versiones anteriores.
Los tipos de profiles disponibles son:
Unconfined (por defecto): seccomp desactivado.
RuntimeDefault: seccomp activado con opciones por defecto.
Localhost: seccomp en modo local indicando el path a utilizar <kubelet-root-dir>/seccomp en kubelet.
En su momento, cuando comenzamos a trabajar con Ansible como una de nuestras herramientas principales para la gestión de los sistemas y configuraciones de nuestros clientes, también implementamos el uso de repositorios para contener esta información. Así, nuestro equipo podría trabajar de forma dinámica con Ansible teniendo un control de versiones de los diferentes cambios que se iban realizando.
¿Quién no ha tenido que lidiar con un ataque contra sus aplicativos web o API?
En Amazon Web Services (AWS), uno de los servicios encargados de mitigar los ataques web y de bots es AWS Web Application Firewall (AWS WAF). Este tipo de ataques comunes pueden generar problemas de seguridad o un consumo elevado de los recursos de la arquitectura afectando a la disponibilidad del servicio.
Conseguir despliegues automáticos sin caídas en producción es el sueño de todo desarrollador experto, o mejor aún, que exista un despliegue continuo donde no se “lanzan despliegues”.
En varias ocasiones algunos de nuestros clientes nos han planteado la misma inquietud: "¿Por qué si hay varias réplicas de un pod y hay varios nodos, la pérdida de un nodo ha llegado a provocar la caída de algún servicio?
Una de las cosas que realizamos en STR con mucha frecuencia es la migración de sistemas, ya sea entre distintos proveedores o dentro de un mismo proveedor por cambio de versión, servicio o cualquier otra razón.
Recientemente se nos ha presentado un reto con el siguiente contexto:
Un punto importante de los sistemas en producción es el uso de los discos y su ocupación. Como no siempre trabajamos en arquitecturas desplegadas en proveedores que permiten modificar los discos en caliente, nosotros optamos por usar LVM para gestionar los puntos de montaje que requieren estar siempre montados, minimizando así pérdidas de servicio en operaciones sobre los mismos.
¡Usamos cookies propias y de terceros para mejorar tu experiencia en esta web! Si sigues navegando, consientes y aceptas estas cookies en tu ordenador, móvil o tablet.
Más información sobre las cookies y cómo cambiar su configuración en tu navegador aquí.