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.

Digital Ocean, al igual que muchos otros proveedores cloud, ofrece servicios de base de datos administrados, siendo uno de los motores de base de datos disponibles y de los más utilizados es MySQL.

La idea de este tipo de servicios es facilitar al usuario la creación y administración del mismo, con interfaces web intuitivas y limitadas a lo imprescindible. Además, incluye tareas administrativas como los backups, por lo que es un servicio que está listo para utilizar.

Jenkins es un software de integración continua de código abierto que se utiliza para automatizar el proceso de construcción, prueba y despliegue de software. 

Permite a los equipos de desarrollo integrar el código de manera rápida y eficiente, lo que ayuda a detectar y resolver los errores de manera temprana en el ciclo de vida del software.

A través de plugins y configuración es altamente personalizable y extensible, lo que significa que los desarrolladores pueden adaptarlo a sus necesidades específicas. Se integra con una variedad de herramientas y tecnologías, lo que facilita su uso en una amplia gama de proyectos.

Cuando nuestras bases de datos van creciendo, ya sea en número de tablas, en número de registros, o ambas cosas, es muy común que empecemos a apreciar una degradación en el tiempo de ejecución de las queries de lectura, especialmente si éstas son complejas y tienen que coger datos de diferentes tablas.

Por suerte, MySQL ofrece opciones para acelerar (optimizar) estas consultas.

Pero antes de pasar a explicar este proceso, vamos a empezar por comprender un concepto básico: ¿cómo elige InnoDB (el motor de almacenamiento que utiliza MySQL) el mejor camino a seguir a la hora de recoger datos? La respuesta es: sirviéndose del contenido almacenado en la tabla statistics.

Esta tabla, que se encuentra en la base de datos information_schema, almacena información sobre los índices de todas las tablas del conjunto entero de las bases de datos.

Todos conocemos (o deberíamos conocer) la recomendación de cambiar nuestras contraseñas cada cierto tiempo.

Sobre todo en entornos empresariales, esta sugerencia se extiende no sólo al cambio de contraseña de usuario, sino también de claves RSA para accesos SSH, cifrados, etc.

En este caso, venimos a hablaros de una necesidad de cambio de claves distinta, pero igualmente importante para nosotros. 

En STR Sistemas, intentamos automatizar el 100% de las infraestructuras (terraform) y configuración de Sistemas (ansible). En dichas automatizaciones, en ocasiones, es necesario incluir información sensible (contraseñas, certificados SSL, RSA's de usuarios, etc), la cual siempre ciframos para evitar tener en código/repositorio contraseñas en texto plano.

Dicho esto, en STR nos topamos con una situación la cual, una vez más, nos llevó a pensar en la automatización o en una solución programada.

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 esta tercera parte de nuestra serie sobre la alta disponibilidad en PostgreSQL con Patroni, vamos a ver cómo configurar un servicio de HAproxy para acceder al cluster de Patroni y a obtener más información sobre su API y patronictl.

Si no has visto la primera y la segunda parte de esta serie, te recomendamos que lo hagas para ver por qué estamos utilizando Patroni, y cómo hemos configurado el servicio.

Al finalizar el anterior artículo ya contábamos con un cluster funcional de Patroni, pero para conectar al servicio, lo teníamos que hacer nodo a nodo. Esto no es funcional ya que en caso de fallo de alguno de los nodos, deberíamos elegir el nuevo leader para conectar.