Ejecutando DataSunrise en Kubernetes Usando Helm Chart

Desplegar aplicaciones en Kubernetes puede ser complejo, ya que requiere un conocimiento detallado de sus varios componentes y sus funciones. Helm simplifica este proceso, haciendo que el despliegue en Kubernetes sea sencillo y manejable. En lugar de crear y mantener manualmente múltiples manifiestos YAML para cada objeto de Kubernetes, Helm consolida todo en un solo paquete que se puede desplegar fácilmente en tu cluster de Kubernetes. Esto reduce significativamente el tiempo y la complejidad involucrados en gestionar aplicaciones en Kubernetes.

DataSunrise ha creado un Helm Chart para facilitar la instalación y operación fácil de DataSunrise en Kubernetes. Helm optimiza la gestión de aplicaciones en Kubernetes, simplificando y unificando el proceso de despliegue para DataSunrise. Con Helm, puedes fácilmente instalar y actualizar DataSunrise según sea necesario en cualquiera de tus ambientes de Kubernetes, incluyendo los proveedores de nube AWS EKS, Azure AKS y los clusters GKE de Google Cloud. El chart soporta múltiples casos de uso basados en los valores proporcionados.

Las características clave del Helm Chart de DataSunrise incluyen la funcionalidad de proxy, donde se usa un proxy en cada nodo y Kubernetes gestiona el balanceo de carga entre ellos. También soporta el escalado automático, utilizando el poderoso Descubrimiento de Datos Sensibles para añadir automáticamente nuevos pods al cluster durante cargas pico. Además, el Helm Chart puede ser instalado fácilmente a través de la aplicación Artifact Hub, simplificando el despliegue y gestión de DataSunrise en Kubernetes.

Requisitos Previos

Nuestro helm chart funciona tanto con Kubernetes estándar como con servicios manejados de Kubernetes tales como el EKS de AWS, el AKS de Azure y el GKE de Google Cloud. Para este artículo, usaremos el EKS de AWS para demostrar los pasos siguientes.

Necesitaremos tener los siguientes componentes en nuestro ambiente. También puedes encontrar los comandos usados para instalar los componentes necesarios en la siguiente sección.

1. Crear un cluster EKS y pods en tu AWS.
2. Helm 3.6+
3. Kubernetes 1.21+ – Esta es la versión más temprana de Kubernetes probada. Es posible que este chart funcione con versiones anteriores.
4. Bases de datos externas para cargas de trabajo en producción y modo de Alta Disponibilidad (HA).

¿Por qué necesitamos bases de datos externas en modo HA?

DataSunrise usa dos tipos clave de bases de datos para almacenar sus datos operativos: la Base de Datos de Auditoría y la Base de Datos de Diccionario. Para garantizar alta disponibilidad y escalabilidad, DataSunrise puede configurarse en múltiples servidores. Al desplegar DataSunrise en una configuración multiserver, se usa una base de datos PostgreSQL, MySQL/MariaDB o MS SQL Server para almacenar los datos comunes del Diccionario y la Auditoría.

La Base de Datos de Auditoría en DataSunrise es esencial para almacenar registros detallados de todas las actividades de bases de datos monitoreadas, incluidas consultas SQL, acciones de usuario y eventos de seguridad. Esta base de datos proporciona una extensa pista de auditoría y facilita el monitoreo de seguridad detectando actividades sospechosas. DataSunrise soporta PostgreSQL, MySQL, MariaDB y MS SQL Server para la Base de Datos de Auditoría. Es crucial asignar almacenamiento suficiente y gestionar políticas de retención para manejar el posible crecimiento significativo de los datos de auditoría.

La Base de Datos de Diccionario almacena la configuración y metadatos necesarios para operar DataSunrise, como información sobre instancias de bases de datos, reglas de seguridad, reglas de auditoría y roles de usuario. Asegura que DataSunrise pueda funcionar sin problemas al mantener toda la configuración requerida. Al igual que la Base de Datos de Auditoría, DataSunrise soporta PostgreSQL, MySQL, MariaDB y MS SQL Server para la Base de Datos de Diccionario. Esta base de datos debería ser altamente disponible y segura con contraseñas fuertes porque es vital para el funcionamiento ininterrumpido de DataSunrise.

Para más información sobre las instrucciones para preparar las bases de datos externas para usar como las bases de datos de auditoría y configuración, consulte el Capítulo 4 de la Guía de Administración: Configuración MultiServidor (modo de Alta Disponibilidad). Al usar bases de datos externas tanto para las Bases de Datos de Auditoría como de Diccionario, DataSunrise puede proporcionar alta disponibilidad robusta, asegurando operación continua y monitoreo de seguridad consistente en tu entorno de bases de datos.

Imagen 1. Estructura de Despliegue de DataSunrise en K8S con Helm Chart

Cómo preparar un cluster AWS EKS

Paso – 1: Cuando el cluster EKS y el nodo donde deseas instalar DataSunrise estén listos para usar, instala:

• kubectl: Interactúa directamente con los clusters de Kubernetes, esencial para la gestión de cluster y aplicaciones.
• Helm: Administra aplicaciones de Kubernetes mediante charts, simplificando despliegues y actualizaciones.
• AWS CLI: Administra recursos de AWS, útil para automatizar tareas de AWS e integrar servicios.

#kubectl

1. curl -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl
2. chmod +x ./kubectl
3. sudo mv ./kubectl /usr/local/bin/kubectl

#helm

1. curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash

#awscli

1. curl “https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip” -o “awscliv2.zip”
2. unzip awscliv2.zip
3. sudo ./aws/install

Paso – 2: Ahora podemos configurar credenciales en awscli:

Ejecuta este comando: aws configure

Después de ejecutarlo, se te pedirá ingresar tu ID de Clave de Acceso de AWS, Clave de Acceso Secreta de AWS, nombre de región predeterminado y formato de salida preferido.

ID de Clave de Acceso de AWS [Ninguno]: ************

Clave de acceso secreta de AWS [Ninguno]: ************

Nombre de Región predeterminado [Ninguno]: us-east-2

Paso – 3: A continuación, configura tu kubectl para interactuar con el cluster EKS especificado en la región dada. Después de actualizar el kubeconfig, verifica la actualización comprobando el estado de los pods en el espacio de nombres kube-system.

1. aws eks update-kubeconfig –region –name
2. kubectl get pods -n kube-system -l k8s-app=aws-node -o wide

Instalación de DataSunrise usando HELM

Paso – 1: Descarga el archivo values.yaml del HELM chart manualmente desde https://artifacthub.io/packages/helm/datasunrise/datasunrise o instala el HELM chart usando el comando:

1. helm repo add datasunrise https://www.datasunrise.com/helm-chart
2. helm install my-datasunrise datasunrise/datasunrise –version 1.2.14


Imagen 2. Instalación del Paquete Helm de DataSunrise

La estructura del directorio debería ser la siguiente:

my-chart/

├── Chart.yaml

├── charts/

├── templates/

├── values.yaml

3. Abre y edita el archivo values.yaml. Edita los siguientes valores:
• enVars – para configurar tus propiedades de base de datos de diccionario y auditoría.
• Cambia el tipo de uiService de ClusterIp a LoadBalancer.
• Habilita el ingreso.

Es crucial usar contraseñas fuertes en la configuración de tu aplicación. Una contraseña fuerte debe tener más de 8-12 caracteres y debe incluir una combinación de mayúsculas, minúsculas, dígitos y caracteres especiales. Por ejemplo, P@ssw0rd#2024!. La demostración del uso del Administrador de Secretos de AWS también se describe en el siguiente sub-artículo.

apiVersion: secrets-store.csi.x-k8s.io/v1alpha1
kind: SecretProviderClass
metadata:
  name: aws-secrets
  namespace: default #Cambiar a tu namespace preferido
spec:
  provider: aws
  secretObjects:
  - secretName: k8s-secret
    type: Opaque
    data: 
    - objectName: db_password
      key: password_for_ds
  parameters:
    objects:
      - objectName: arn:aws:secretmanager:us-east-1:xxxxxx:secret:MySecret
        objectType: secretmanager
        jmesPath:
          - path: password_for_ds
          objectAlias: db_password

envVars##
envVars: {}
  # Ejemplos:
  # - name: DICTIONARY_TYPE
  #   value: "postgresql"
  #
  # - name: DICTIONARY_PASS
  #   valueFrom:
  #     secretKeyRef:
  #       name: db-secret
  #       key: password
 
  - name: DICTIONARY_TYPE
    value: "postgresql" 
  - name: DICTIONARY_HOST
    value: "your_dictionary_host" 
  - name: DICTIONARY_PORT
    value: "5432" 
  - name: DICTIONARY_DB_NAME
    value: "dictionarydb" 
  - name: DICTIONARY_LOGIN
    value: "postgres" 
  - name: DICTIONARY_PASS
    valueFrom:
        secretKeyRef:
            name: k8s-secret
            key: password_for_ds
  - name: AUDIT_TYPE
    value: "postgresql" 
  - name: AUDIT_HOST
    value: "your_audit_host" 
  - name: AUDIT_PORT
    value: "5432" 
  - name: AUDIT_DB_NAME
    value: "auditdb" 
  - name: AUDIT_LOGIN
    value: "postgres" 
  - name: AUDIT_PASS
    valueFrom:
        secretKeyRef:
            name: k8s-secret
            key: password_for_ds 

uiService:
  type: LoadBalancer
  port: 11000
  annotations: {}

ingress:
  enabled: true
  className: “”

Nota: Si tu pod se congela en el estado “Pending”, desactiva el volumen:

localSettingsPersistentVolume:
  ## Si 'true', se creará/usará una Reclamación de Volumen Persistente.
  ## Si 'false', se usará emptyDir.
  enabled: false

Paso – 2: Para conectarse a la interfaz web de DataSunrise, necesitamos configurar el ingreso:

helm upgrade –install ingress-nginx ingress-nginx –repo https://kubernetes.github.io/ingress-nginx –namespace ingress-nginx –create-namespace

Este comando extrae el chart ingress-nginx desde el repositorio especificado y lo instala en el namespace ingress-nginx, creando el namespace si ya no existe. Esta configuración te permitirá gestionar el acceso externo a tus servicios de DataSunrise a través de recursos Ingress de Kubernetes.

Luego, necesitamos establecer el host para tu Ingress. Para encontrar el enlace al balanceador de carga, navega al panel de control de tu cluster AWS EKS. Luego, ve a “Recursos” -> “Servicio y redes” -> “Servicio” -> “ingress-nginx-controller”, y copia la URL del LoadBalancer. Una vez que tengas la URL, úasla para establecer el campo host (“-host”) en tu configuración de Ingress.

Imagen 3. Cómo encontrar el enlace al balanceador de carga en AWS EKS (1)

Imagen 4. Cómo encontrar el enlace al balanceador de carga en AWS EKS (2)

ingress:
  enabled: false
  className: "nginx"
  ## Se necesitan algunas anotaciones adicionales para el ingreso.
  ## Si estás usando nginx, las anotaciones necesarias ya están presentes abajo.
  ## Si usas un ingreso diferente, necesitas encontrar anotaciones similares para tu clase.
  ## las anotaciones del backend HTTPS y 'sticky session' son necesarias
  annotations:
    nginx.ingress.kubernetes.io/backend-protocol: "HTTPS"
    nginx.ingress.kubernetes.io/affinity: "cookie"
    nginx.ingress.kubernetes.io/affinity-mode: "persistent"
    # kubernetes.io/ingress.class: nginx
    # kubernetes.io/tls-acme: "true"
  hosts:
    - host: #inserta aquí tu URL del loadbalancer
      paths:
        - path: /
          pathType: ImplementationSpecific

Paso – 3: Después de configurar el host, puedes instalar DataSunrise usando Helm. Asegúrate de estar en el directorio que contiene el script del Helm chart. Luego, ejecuta el siguiente comando:

“helm install ds .”

Para seguir el estado de la instalación, usa el siguiente comando:

“kubectl get pods”

Verifica los logs del pod si el pod no está iniciando:

“kubectl logs ”

Paso – 4: Una vez que el pod de datasunrise esté en funcionamiento, deberías poder conectarte a la interfaz web de DataSunrise con el enlace anterior del LoadBalancer. O, puedes comprobar usando este comando: kubectl get services.

Imagen 5. Resultados de Muestra de ‘kubectl get services’

Imagen 6. Conectándose a la Consola Web de DataSunrise

Paso – 5: Si deseas actualizar DataSunrise a una versión más reciente, necesitas modificar la versión especificada en el archivo values.yaml a la versión deseada. Una vez que hayas realizado los cambios necesarios, ejecuta el siguiente comando para actualizar DataSunrise: “helm upgrade ds .”

Configurar Conexión con la Base de Datos Objetivo

Cuando tu cluster de DataSunrise, construido con Kubernetes y Docker, esté en funcionamiento, puedes configurar Reglas de DataSunrise para auditar, proteger o enmascarar las columnas sensibles de tu base de datos. Ve la sección “Casos de Uso de DataSunrise” de la Guía del Usuario de DataSunrise.

DataSunrise interactúa con una base de datos objetivo y recibe toda la información requerida para la operación a través de una cuenta de usuario de esta base de datos (la cuenta, nombre de usuario y contraseña de la cual se especifican en el perfil de la base de datos objetivo en la Consola Web). Puedes usar la cuenta del administrador de la base de datos para la conexión, pero también es posible usar cualquier otra cuenta de usuario con privilegios suficientes. La sección de la guía del usuario: 5.2 Creación de Usuarios de Base de Datos Requeridos para Obtener los Metadatos de la Base de Datos describe las acciones necesarias para establecer una conexión entre DataSunrise y varias bases de datos. Después de configurar el usuario de la base de datos para recuperar los metadatos de la base de datos, los siguientes pasos pueden proceder para conectarse con DataSunrise a través de la consola web.

1. Inicia sesión en la Consola Web de DataSunrise.

   Usa la dirección IP externa obtenida del paso anterior para acceder a la Consola Web de DataSunrise.

2. Agregar Instancia de Base de Datos Objetivo.
• Navega a la Configuración > selecciona Instancias de Bases de Datos.
• Haz clic en “Agregar Nueva Instancia” y llena los detalles requeridos:
• Nombre Lógico: Un nombre de referencia para la base de datos.
• Nombre de Host o IP: La dirección de la base de datos objetivo.
• Método de Autenticación: Elige el método apropiado (por ejemplo, nombre de usuario/contraseña de base de datos, Active Directory).
• Tipo de Base de Datos: Selecciona el tipo de tu base de datos objetivo (por ejemplo, MS SQL, PostgreSQL).
• Puerto: El número de puerto en el que la base de datos está funcionando.
• Nombre de la Base de Datos: El nombre de la base de datos objetivo.
3. Prueba de Conexión.
• Haz clic en el botón “Test” para asegurarte de que DataSunrise puede conectarse exitosamente a la base de datos objetivo.
• Una vez que la prueba de conexión sea exitosa, haz clic en “Guardar” para agregar la instancia de base de datos a DataSunrise.
4. Configura Reglas de Seguridad y Auditoría.

Navega a la sección de Reglas en la Consola Web de DataSunrise. Crea y configura reglas para auditoría, seguridad y enmascaramiento de datos según tus requisitos.

Imagen 7. Prueba de Conexión en DataSunrise

Imagen 8. Estableciendo Conexión de Proxy en DataSunrise

Conclusión

El Helm Chart proporcionado por DataSunrise con Kubernetes simplifica el proceso de despliegue, ofreciendo características clave como la funcionalidad de proxy y escalado automático, asegurando un rendimiento y fiabilidad óptimos. Además, al adherirse a las mejores prácticas como configurar bases de datos externas y utilizar contraseñas fuertes, las organizaciones pueden mejorar la postura de seguridad de sus despliegues. Con DataSunrise desplegado en Kubernetes, las organizaciones pueden proteger con confianza sus datos sensibles mientras se benefician de la escalabilidad y flexibilidad de los entornos containerizados.

Integrando AWS Secret Manager con AWS EKS

AWS Secrets Manager es una herramienta robusta que ofrece cifrado en reposo y rotación de secretos, lo que la convierte en una opción ideal para gestionar de forma segura información sensible. Dado que cuenta con la aprobación de muchos equipos de seguridad, es una solución confiable para manejar secretos dentro de ambientes en la nube. Por lo tanto, para mejorar la seguridad en los despliegues de AWS, como con Amazon EKS, puedes aprovechar AWS Secrets Manager para asegurar que tus aplicaciones permanezcan seguras y cumplan con las mejores prácticas.

Hay múltiples formas de usar el servicio AWS Secrets Manager en Pods de EKS.

Usando el Driver CSI del Almacén de Secretos de Kubernetes

Si bien se ofrecen múltiples implementaciones personalizadas de flexibilidad, también requieren un esfuerzo significativo de desarrollo, mantenimiento y operación. Un enfoque más estandarizado y eficiente es utilizar el Driver CSI del Almacén de Secretos de Kubernetes. Este driver integra almacenes de secretos con Kubernetes a través de una Interfaz de Almacenamiento de Contenedores (CSI) y permite que los secretos de AWS Secrets Manager se monten directamente en el pod.

El Driver CSI del Almacén de Secretos simplifica el proceso de gestión de secretos al proporcionar una interfaz Kubernetes nativa para la gestión de secretos. Reduce la sobrecarga asociada con soluciones personalizadas y asegura un método consistente y seguro para manejar secretos dentro de tu entorno Kubernetes.

Imagen 9. AWS Secrets Manager

Puedes consultar estos enlaces para explorar más sobre el driver y su uso. Las instrucciones para instalar estos requisitos también se mencionan a continuación.

1. Driver CSI del Almacén de Secretos de Kubernetes
2. Proveedor de Secretos y Configuración de AWS

Pasos a seguir

1. Instala el Driver CSI del Almacén de Secretos. Debes asegurarte de que el driver secrets-store.csi.k8s.io esté instalado en tu cluster de Kubernetes. Este driver permite que Kubernetes interactúe con sistemas externos de gestión de secretos.

“helm repo add secrets-store-csi-driver https://kubernetes-sigs.github.io/secrets-store-csi-driver/charts”

“helm install csi-secrets-store secrets-store-csi-driver/secrets-store-csi-driver –namespace kube-system –set syncSecret.enabled=true”

2. Crea un secreto dentro de AWS Secrets Manager en la misma región que tu cluster usando la CLI de AWS (Interfaz de Línea de Comando). También puedes hacerlo en la Consola de Administración de AWS.

3.1: Establece dos variables de ambiente REGION y CLUSTERNAME. Estas variables definen la región de AWS y el nombre del cluster EKS.

REGION=

CLUSTERNAME=

3.2: Crea el secreto en AWS Secrets Manager. Incluye objetos JSON de tus credenciales o secretos. Después de ejecutar este comando, la variable SECRET_ARN contendrá el ARN (Nombre de Recurso de Amazon) del secreto creado.

SECRET_ARN=$(aws –query ARN –output text secretsmanager create-secret –name –secret-string ‘{““:”“, ““:”“}’ –region “$REGION”)

3. Crea políticas IAM ejecutando el siguiente comando. Después de ejecutar el comando, la variable POLICY_ARN contendrá el ARN de la política IAM creada.

POLICY_ARN=$(aws --region "$REGION" --query Policy.Arn --output text iam create-policy --policy-name  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [ {
        "Effect": "Allow",
        "Action": ["secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret"],
        "Resource": ["$SECRET_ARN"]
    } ]
}')

4. Crea una cuenta de servicio asociada con la política IAM que creaste anteriormente usando `eksctl`. Antes de ejecutar el comando, asegúrate de tener eksctl instalado y configurado en tu máquina.

eksctl create iamserviceaccount –name –region=”$REGION” –cluster “$CLUSTERNAME” –attach-policy-arn “$POLICY_ARN” –approve –override-existing-serviceaccounts

El flag –approve confirma la creación de la cuenta de servicio sin pedir confirmación, y –override-existing-serviceaccounts permite que el comando sobrescriba cuentas de servicio existentes con el mismo nombre.

5. Crea una Clase de Proveedor de Secretos de AWS.

apiVersion: secrets-store.csi.x-k8s.io/v1alpha1
kind: SecretProviderClass
metadata:
  name: 
spec:
  provider: aws
  parameters:
    objects: |
      - objectName: ""
        objectType: "secretsmanager"
        jmesPath:
          - path: 
            objectAlias: 
          - path: 
            objectAlias: 

SECRET_ARN=$(aws --query ARN --output text secretsmanager
create-secret --name  --secret-string '{"":"", "":""}'
--region "$REIGON")

6. Modifica el values.yaml usando los secretos que creamos en el paso-2. Debes especificar el parámetro envVarsSecretProviderClassName con el nombre de la Clase de Proveedor de Secretos que creaste en el paso-5. Después de modificar todos los campos necesarios en values.yaml, puedes continuar con el despliegue de helm.


Imagen 10. Especificar Parámetro

Nota: Si creas un secreto de k8s usando el manifiesto yaml, debes incluir el secreto en codificación base64. Mira el ejemplo a continuación:

your_secret_file.yaml:

apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  password: cGFzc3dvcmQxMjMK # password1234 en codificación base64
-------------------------
values.yaml:


- name: DICTIONARY_PASS
  valueFrom:
  secretKeyRef:
     name: db-secret
     key: password

Conclusión

Usar contraseñas fuertes junto con un servicio de gestión de secretos como AWS Secrets Manager mejora significativamente la postura de seguridad de tus despliegues. Siguiendo estos pasos, puedes gestionar e inyectar con seguridad secretos desde AWS Secrets Manager en tus aplicaciones DataSunrise desplegadas a través de Helm en EKS.