Uno de los trabajos que hemos realizado esta semana ha sido la puesta en marcha de una replicación nativa activo-pasivo de MySQL de uno de los servidores que contiene las bases de datos de las herramientas que usamos en el día a día. En este caso, nos gustaría compartir uno de los métodos que solemos utilizar para ello teniendo en cuenta que no hay parada de servicio.
La automatización de tareas es una parte esencial de la administración de sistemas y la gestión de infraestructuras, ¿qué duda cabe? Sus ventajas están más que demostradas, tanto para la calidad de vida de las personas como para la optimización de procesos empresariales, sobre todo en empresas que desarrollan la cultura devops en sus equipos.
Pero no siempre es así. Automatizar sistemas tiene un coste en esfuerzo, a veces elevado, que debe ser recompensado en ahorro y optimización del tiempo global empleado en la implantación y mantenimiento de forma recurrente de dichos sistemas. ¿Cuántas veces nos hemos encontrado con automatizaciones anidadas de tareas, que provisionan y configuran sistemas que han ralentizado tanto su ejecución, que se llega a cuestionar su utilidad y la vuelta a la implantación manual por los equipos de sysadmin?
Una de las herramientas con las que trabajamos diariamente es Terraform, pero ¿qué es?
Terraform es una herramienta de infraestructura como código (IaC) desarrollada por HashiCorp, siendo su objetivo principal permitirnos automatizar y gestionar la infraestructura de nuestros clientes de manera eficiente.
Una de las principales preguntas que hay que plantearse antes de comenzar a trabajar con Terraform es la organización del código, ya que lo normal en las arquitecturas es tener varios entornos: producción, preproducción, desarrollo o los que en cada caso existan.
Pues bien, para tener el código organizadopor cada entorno pueden existir infinitas formas de plantearlo, pero hoy nos centraremos en dos:
En entornos de Kubernetes, los volúmenes persistentes desempeñan un papel crucial en el almacenamiento de datos de aplicaciones. Tener un entorno dinámico donde los recursos se crean y se destruyen de forma automática, es tan útil como peligroso si nuestros datos persistentes están entre estos recursos del cluster.
Uno de los almacenamientos más utilizados en entornos AWS es Amazon Elastic Block Store (EBS). En entornos de Kubernetes, gracias al controlador de almacenamiento externo EBS-CSI (EBS Container Storage Interface), tenemos la opción de utilizar volúmenes persistentes de EBS de manera eficiente y segura. La base radica en la capacidad de crear snapshots de volúmenes asociados a recursos de Kubernetes para manejarlos con facilidad.
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.
¡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í.
