ProxySQL, una alternativa a la gestión de bases de datos SQL en Google Cloud Platform (GCP)

En el mundo del DevOps, es de vital importancia mantener un entorno en el que tus compañeros desarrolladores puedan sacar el mayor partido de las tecnologías disponibles, y a las que están acostumbrados sin abrir jugosas brechas de seguridad.

En este post hablaremos sobre cómo dar acceso a nuestras bases de datos a usuarios que la necesitan, en un entorno con un cluster de kubernetes y una base de datos en CLoudSQL de la manera más segura y eficiente haciendo uso del ProxySQL.

La gestión de datos es complicada

Realizar una gestión de base de datos dentro de la nube puede llegar a ser un dolor de cabeza para nuestros amigos programadores. Esto se debe a que tener nuestra base de datos dentro de una VPC que está solo accesible desde los microservicios que cuenten con las credenciales suficientes, es la alternativa de facto para mantener seguro nuestros valiosos datos. Eso implica que, si en entornos no productivos los desarrolladores necesitan realizar operaciones SQL dentro de la base de datos, se enfrentarán al problema de no contar con acceso directo desde sus entornos locales.

Para enfrentar este problema, surgen ante nosotros tres posibilidades, cada una con un nivel distinto de seguridad y de complejidad.

1. Acceso por parte de los desarrolladores a uno de los microservicios y realicen las operaciones por línea de comandos: este acceso se puede garantizar por herramientas de control Kubernetes como Rancher, o desde el mismo GCP. Con esta opción mantendremos la seguridad y aplicamos la regla del menor privilegio posible. Desgraciadamente, realizar una gestión de base de datos desde esos microservicios se vuelve una tarea demasiado manual, sobre todo hablando de datos.
2. Crear un microservicio que ejecute un simple servidor phpmyadmin que cuente con las credenciales necesarias para acceder a la base de datos: aquí podemos de nuevo tener control sobre las credenciales de acceso utilizando un Identity Aware Proxy y garantizar un entorno mucho más amigable que utilizar mysql en línea de comandos. Sin embargo, esta solución cuenta con la desventaja de que existen disponibles muchísimas más herramientas de gestión de base de datos y estamos forzando a realizar toda la gestión desde la misma entidad. Vamos, que esta solución se acerca, pero podemos hacerlo mejor.
3. Utilizar ProxySQL: la propuesta es bastante sencilla a priori, el ProxySQl será utilizado como una suerte de túnel entre el desarrollador y la base de datos. Basta con tener la base de datos con la opción de dirección IP pública que brinda GCP para CloudSQL y realizar la instalación local del Proxysql dependiendo del sistema operativo en cuestión. Si quieres saber un poco más sobre este proceso puedes verlo aquí.

Con todos estos pasos listos, basta con ejecutar el siguiente set de comandos el cual crea la conexión con la base de datos mediante una encriptación propietaria de ProxySQL y ya tendremos en nuestro puerto local un puerto con acceso la base de datos del que podemos tirar del hilo para hacer operaciones SQL.

Primero que nada, necesitamos el ID de la instancia, este lo podemos obtener por la CLI de GCP o desde la consola:

gcloud sql instances describe <nombre instancia SQL>

Después utilizamos este comando para crear la conexión. Recordar que se deben tener los permisos suficientes para acceder, eso se hace habilitando el role de Cloud SQL Client para el usuario IAM que estamos utilizando.

./cloud_sql_proxy -instances=<Id de la instancia>=tcp:0.0.0.0:<puerto a exponer>

Y ahora ya se puede hechar mano de su software de gestión de base de datos favorito a ese puerto.

La necesidad de una mayor seguridad

Sin embargo, hay algo que quizá no está del todo asegurado, en temas de compliance y seguridad aunque esa IP pública en CloudSQL y se encuentre restringida, al final es una IP que tenemos que gestionar y cuidar y en muchos escenarios, y  dependiendo de las reglas internas de la empresa esto no está permitido. Eso implica un gran obstáculo para nuestra configuración actual, puesto que el proxySQL la necesita para funcionar. Afortunadamente, existe una configuración en kubernetes que podemos habilitar para que nuestro despliegue funcione sin mayor problema, eso sí complicando un poco más el despliegue.

El salvador en este caso es nuestro amigo PortForward, el cual permite crear un mapeo de puertos entre un cluster kubernetes en remoto y el ordenador de un sujeto con credenciales de acceso suficiente.

Por tanto, lo que hacemos en este caso es crear un pod en nuestro despliegue, que de por sí tiene acceso a la misma VPC privada dentro de GCP. Existen imagenes ya listas del ProxySQL provistas y mantenidas por Google (https://github.com/GoogleCloudPlatform/cloudsql-proxy), las cuales con unos cuantos parámetros de configuración están listas para operar como un microservicio. Como dato adicional, ProxySQL puede servir de acceso también para el resto de microservicios en el cluster. Una vez hecho esto, simplemente habilitamos la opción de PortForward y ejecutamos este comando para tener acceso a nuestro Mapeo de Puertos.

Aquí la cuestión es que, para que nuestra arquitectura funcione se debe garantizar acceso al cluster Kubernetes a los desarrolladores. Si lo realizamos de esa manera no estaremos respetando el principio de Less Privileges, pues estaremos dando acceso a todo el hierro que soporta las aplicaciones que está ejecutando. Vamos, que el desarrollador no tendría por que tener acceso a los Ingress o los microservicios de caché.

La solución de nuevo es relativamente simple, utilizamos un namespace diferente para el microservicio que contiene el ProxySQL. Es decir, garantizamos permisos a los desarrolladores SOLAMENTE a dicho namespace por medio de un service account, un role creado en IAM y un role binding.

Como conclusión…

No podemos enfatizar lo suficiente en la importancia de asegurar los datos y de cumplir los requerimientos de seguridad. Eso sí, para tener el lujo de no tener una IP privada, el despliegue puede complicarse un poco, añadiendo más puntos de salto entre el entorno local y la base de datos, además de los parámetros de configuración.

Pero hemos de decir que esto vale la pena, pues solo se debe hacer una vez y tendremos todo listo y asegurado.

Las herramientas que existen son muchas y las interacciones hacen las posibilidades infinitas, por lo que podremos encontrar otras soluciones que se adecúen más a otros casos.

El próximo jueves, 19 de mayo no te pierdas el evento Digital Leaders Day: CLOUD & DATA: Construye, securiza y escala, en el que hablaremos sobre seguridad y datos,  destapando todo el poder de las soluciones de Google Cloud Platform (GCP) junto a nuestros clientes, Google y nuestros expertos, ¿te lo vas a perder? Apúntate a este evento presencial aquí.