Utilizar una base de datos open source como PostgreSQL, basada en contenedores controlados por Kubernetes es una forma eficaz de llevar a cabo una transformación digital integral utilizando el modelo 4C (cloud, cluster container, code).
¿Qué es Kubernetes?
Kubernetes es una orquestador open source que ejecuta cargas de trabajo contenerizadas en la nube. Su uso es una excelente elección cuando se trabaja hacia una transformación digital de datos administrable y rentable.
Kubernetes ofrece una solución bien estructurada que es fácil de escalar, mantener y facturar para modelos comerciales sólidos.
Una buena forma de aprovechar esto es con PostgreSQL. Una base de datos relacional que cumple con las propiedades ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad).
Soluciones para Postgres de EnterpriseDB
PostgreSQL es una de las bases datos open source más avanzadas.
EDB Postgres Advanced Server es una base de datos enterprise que extiende las funcionalidades de seguridad y rendimiento de Postgres.
Además, dado que EPAS dispone de una capa de compatibilidad de Oracle llamada SPL, facilita las migraciones desde Oracle al no tener que reescribir todo el PL/SQL con el apoyo de la herramienta Migration Toolkit de EDB.
¿Qué es Cloud Native PostgreSQL?
Cloud Native PostgreSQL es un operador para Kubernetes y Openshift distribuido por EDB, que facilita el despliegue y administración de bases de datos PostgreSQL o EDB Postgres Advanced (EPAS); que soporta la arquitectura de primary-standby con la replicación de nativa de streaming replication (SR).
Este operador es nativo de Kubernetes e interactúa directamente con el Servidor API y está escrito en Go al igual que Kubernetes.
Además cabe destacar que las imágenes de los contenedores se almacenan en Quay.io y tienen la licencia limitada de EDB.
¿Qué hace único a Cloud Native PostgreSQL ?
La elección de Cloud Native PostgreSQL se basa en el concepto del uso de “Immutable Application Containers” (Contenedores de aplicaciones inmutables).
Configuración declarativa
La configuración de Cloud Native PostgreSQL se define en un archivo .YAML que permite crear, modificar y eliminar recursos de Kubernetes como pods, despliegues, servicios…
Este tipo de configuración declarativa se centra en una mentalidad de DevOps, de forma que objetivo es definir el estado deseado del cluster de PostgreSQL, en lugar de una lista de pasos o cambios que deban ejecutar en secuencia.
Aplicaciones vs Sistema de contenedores
Otro de los aspectos más importantes de este operador es que despliega contenedores de aplicaciones inmutables utilizando sistemas operativos ligeros.
Un contenedor de aplicación está diseñado para ejecutar un único proceso de punto de entrada principal, como PostgreSQL, lo cual difiere de un contenedor de sistema, en el que se ejecutan múltiples servicios al mismo tiempo (por ejemplo, PostgreSQL, SSH, Syslog, etc.). Los contenedores de sistema se asemejan a las máquinas virtuales tradicionales o servidores físicos, pero tienden a no encajar adecuadamente en Kubernetes.
El operador de EDB despliega contenedores de aplicaciones que no requieren del usuario root se ejecute o acceda al almacenamiento, de manera que se reduce el riesgo de incidencias debido a estos privilegios. Además de que permite la implementación de importantes Políticas de Seguridad de Pods (PSP) en el sistema.
Inmutabilidad
Los contenedores de aplicaciones inmutables no permiten actualizaciones del software a partir de “yum update” o “apt upgrade”. Las actualizaciones requieren el despliegue de una nueva imágen, pero dado que Kubernetes ha sido diseñado para trabajar con contenedores de aplicaciones inmutables, esta preparado para realizar despliegues y/o actualizaciones de tales aplicaciones de forma continua sin tiempo de inactividad. De forma que el PGDATA definido en un volúmen persistente se reutiliza para las actualizaciones.
El modelo de seguridad 4C en Kubernetes
El modelo de seguridad 4C adoptado por la Comunidad de Kubernetes se basa en varios factores entre los que destaca una evaluación exhaustiva de la infraestructura de seguridad que proporciona Kubernetes.
El enfoque de modelo multicapa conocido como «4C», inspirado en el modelo Defense in Depth (DiD) se organiza en cuatro capas:
- Cloud (Nube)
- Cluster (Clúster)
- Container (Contenedor)
- Code (Código)
Cada uno de estas capas está protegida por la capa circundante y proporciona sus propias capacidades y características para la seguridad, tal como se ilustra en la siguiente imágen:
Fuente: Gabriele Bartolini on the EDB blog.
A continuación se definen con más detalle cada una de las capas.
La capa Cloud
La capa Cloud es la más externa y una de las más críticas. Las medidas de seguridad que se deben adoptar depende de si un administrador está gestionando un clúster de Kubernetes propio o si Kubernetes se está ejecutando en un proveedor de Cloud de terceros como Amazon Web Services, Azure o Google, cada uno con su propio conjunto de recomendaciones y mejores prácticas.
Una vez se concede el acceso a un clúster de Kubernetes, éste ya debería haber sido evaluado adecuadamente por los administradores de Kubernetes y de la infraestructura habiendo tenido en cuenta la documentación de Kubernetes.
La capa Cluster
El nivel de Cluster constituye la segunda capa, lo que significa que todos los componentes de Kubernetes tanto en el control plane como en los nodos workers están protegidos, empezando por el más crítico: el kube-api-server.
Los componentes de Kubernetes como, los son usuarios nativos, utilizan comunicaciones cifradas y requieren de certificados TLS para la autenticación entre ellos. La interfaz principal de Kubernetes, el servidor kube-api, es por defecto sólo accesible a través de HTTPS y puede ser protegida por autenticación (que también puede ser delegada a proveedores de identidad externos, incluyendo OpenID Connect).
Además la autorización del servidor API se implementa normalmente con reglas flexibles de Control de Acceso Basado en Roles (RBAC), que también pueden ser ampliadas y personalizadas. Esto significa que no es necesario el acceso a Secure Shell (SSH) para administrar un clúster de Kubernetes y las aplicaciones (workloads) que se ejecutan en él.
Por otro lado, cabe destacar que Kubernetes también proporciona a los administradores y usuarios varias técnicas y recursos nativos para controlar y proteger el clúster y las aplicaciones que se ejecutan en él, como las pod networks, las network policies, los namespaces, las pod security policies o los security contexts etc.
El operador Cloud Native PostgreSQl ha sido diseñado para cooperar con la API de Kubernetes. El operador depende de una service account para autenticarse con el servidor de la API y de un security context de forma que se ejecuta como un usuario sin privilegios.
De forma similar cada clúster de Postgres que se despliega con el operador también tiene su propia service account para comunicarse constantemente con el servidor de la API y proporcionar información de estado.
La capa Container
El siguiente nivel de seguridad interior es el de los contenedores. Las imágenes de los contenedores pueden ser escaneadas en busca de vulnerabilidades. En concreto, las imágenes de Quay.io se escanean continuamente y se reconstruyen una vez al día en caso de que surjan nuevas imágenes de RedHat UB, que es la imagen base utilizada por el software Cloud Native. Las imágenes de contenedores pueden construirse siguiendo el paradigma de contenedor de aplicación inmutable, y por lo tanto tienen un único proceso de punto de entrada que no requiere privilegios de root.
Las imágenes de contenedores permiten un control de versiones estricto y una gestión de parches eficaz, ya que los contenedores no se actualizan, sino que simplemente se sustituyen. Es importante actualizar periódicamente los sistemas desde el punto de vista de la seguridad. Gracias a los despliegues de Kubernetes, esto puede hacerse sin tiempo de inactividad, a través de las actualizaciones continuas y la configuración declarativa, lo que aporta beneficios reales en términos de control de la gestión de cambios.
La capa Code
La última “C” representa el código. En este ámbito, es importante que las organizaciones se apoyen en integraciones continuas (Continuous Integration) o integraciones de pipeline de entrega contínua (Continuous Delivery (CI/CD) pipeline integrations).
Al construir el operador, EDB ha seguido principios, prácticas y capacidades consolidadas de Lean/DevOps, como el control de versiones, el desarrollo trunk-based, la rama de entrega continua, la revisión peer, la automatización de pruebas y el escaneo de código.
Caso de estudio: “Single-sign on” en EEUU
KeyCloak es una aplicación de inicio de sesión único que ayuda a los ciudadanos de EEUU a acceder a los servicios gubernamentales. Esta aplicación esta desarrollada y desplegada con Kubernetes, los requisitos de las aplicaciones SSO son la escalabilidad, la seguridad y las prestaciones.
La solución propuesta mejora la experiencia de usuario de los ciudadanos que acceden a los sitios web y servicios gubernamentales. La entrega de la aplicación es rentable.
EDB ha aportado valor gracias a la velocidad y flexibilidad de Cloud Native Postgres.
De forma que Cloud Native PostgreSQL ha ayudado a crear un nuevo entorno de autoservicio para construir nuevas aplicaciones.
El plugin PostgreSQL nativo de la nube para kubectl
EDB lanzó Cloud Native PostgreSQL 1.1.0 a principios de febrero de 2021. No obstante, el equipo de DevOps introduce nuevas características de forma incremental, aproximadamente cada dos semanas (actualmente).
Una de las características más útiles introducidas recientemente es el plugin CNP para la herramienta kubectl. Esta herramienta amplía la capacidad del operador para hacer que la gestión de un clúster Cloud Native PostgreSQL (CNP) en Kubernetes sea más sencilla desde la perspectiva del usuario.
Fuente: Jonathan Battiato on the EDB blog.
El plugin CNP para kubectl se está convirtiendo en una herramienta esencial para los administradores que necesitan gestionar un clúster Cloud Native PostgreSQL dentro de Kubernetes. Una de las características más importantes que ofrece es la capacidad de mostrar el estado de un clúster CNP a través del subcomando status, que mostrará una lista de los nodos del clúster y sus condiciones en cualquier momento.
El comando “promote” es introducido en el plugin CNP. En la próxima versión, se añadirán dos subcomandos más: ‘status’ y ‘certificate’.
Puedes encontrar el artículo completo aquí.
Conclusiones
Hopla Software! es un socio comercial y proveedor de servicios profesionales y EDB es su proveedor de software principalmente en su área de influencia.
Hopla actúa como agente de EDB, detectando leads, trabajando con estos leads como cliente potencial, vendiendo suscripciones, proporcionando servicios profesionales y soporte de primero y segundo nivel en el idioma local.
De esta forma puede ayudar a las empresas a construir soluciones sólidas para la transformación digital a través de herramientas de código abierto.
Para más información sobre Hopla, echa un vistazo al sitio web de la empresa.
