Unos meses atrás hicimos una pequeña introducción al servicio de WAF donde, además de hablar superficialmente de que trata este servicio y algunas configuraciones básicas, también comentamos muy brevemente que uno de sus atractivos eran las reglas administradas por AWS.
Pues bien, hoy hablaremos de estas reglas administradas y cómo podemos activarlas en nuestras WAF ACL. Algunas nociones y configuraciones básicas no las explicaremos en esta ocasión para no alargarnos mucho, pero las puedes consultar en este otro post que publicamos.
OpenShift permite a los desarrolladores crear, implementar y administrar aplicaciones en contenedores de manera eficiente y escalable. Sin embargo, al trabajar con contenedores, es importante tener en cuenta la seguridad y la protección del sistema operativo subyacente.
En un artículo anterior, hablamos de seccomProfile como mecanismo de seguridad del kernel Linux con restricciones de llamadas al sistema. Hoy abordamos otro componente para mejorar la seguridad de nuestros contenedores en Openshift: los objetos SSC (SecurityContextConstraints).
¿Qué es SecurityContextConstraints?
SecurityContextConstraints (SCC) es una funcionalidad de OpenShift que permite definir políticas de seguridad para los contenedores que se ejecutan en la plataforma.
SCC permite a los administradores de la plataforma controlar los privilegios de los contenedores, limitando el acceso a ciertas acciones desde el contenedor que podrían comprometer la seguridad de la plataforma o de los datos de usuario.
Cloudflare y Amazon Cloudfront son algunos de los servicios que nuestros clientes suelen utilizar como Red de Distribución de Contenido o CDN (del inglés Content Delivery Network).
Ambas nos ayudan a acelerar la entrega y mejorar por tanto los tiempos de carga de contenido, generando grandes beneficios en lo que se refiere a experiencia de usuario, SEO, etc.
A lo largo del artículo expondremos las características principales de cada una de las partes para ver qué opción se adapta más a nuestras necesidades.
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.
A pesar de ello, una parte importante de la información con la que trabajamos en nuestro día a día es delicada, ya sean contraseñas, certificados o ficheros con datos sensibles, y no podrían tratarse de cualquier forma.
¿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.
AWS WAF permite controlar el tráfico que llega a las aplicaciones. Crea reglas de seguridad para limitar las peticiones que puedan ser potencialmente peligrosas como patrones de ataque comunes (ejemplo las inyecciones SQL). También permite crear reglas personalizadas que posibilita filtrar patrones específicos que conozcamos de nuestros aplicativos que puedan ser susceptibles de ser explotados por agentes externos.
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”.
¡Ojo!, no es algo imposible y hay muchas formas de conseguirlo sin mucha sofisticación, pero a veces supone un sobreesfuerzo del desarrollador que para “aplicar un parchecito”, no siempre compensa.
La solución a este problema, aplicable a muchos otros, es integrar el mecanismo de despliegue en la propia infraestructura. De esta forma, se consigue hacer transparente el proceso al equipo de desarrolladores sin hacerles pasar un mal rato cada vez que aplican una mejora o nueva funcionalidad en el software de producción.
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? ¿Por qué se pierde servicio si hay alta disponibilidad y tengo varios nodos y varias réplicas?"
Un error muy común es pensar que el planificador de kubernetes va a distribuir sí o sí todas las réplicas de un pod en diferentes nodos. Esto suele ir seguido de una breve explicación por nuestra parte sobre kubernetes y la planificación de pods.
¡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í.
