Inicio
Noticias Profesionales
Ejecutando DataSunrise en Kubernetes con el Chart de Helm

Ejecutando DataSunrise en Kubernetes con el Chart de Helm

Introducción

El despliegue de aplicaciones en Kubernetes puede ser complejo, ya que requiere un conocimiento detallado de sus diversos componentes y de 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 único paquete que se puede desplegar fácilmente en tu clúster de Kubernetes. Esto reduce significativamente el tiempo y la complejidad involucrados en la gestión de aplicaciones en Kubernetes.

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

Características Clave del Chart de Helm de DataSunrise

El Chart de Helm de DataSunrise incluye varias características clave que mejoran su funcionalidad y facilidad de uso:

Funcionalidad de Proxy: Se utiliza un proxy en cada nodo, y Kubernetes gestiona el balanceo de carga entre ellos, asegurando una distribución eficiente del tráfico y un rendimiento mejorado.
Escalado Automático: Utiliza un potente Descubrimiento de Datos Sensibles para agregar automáticamente nuevos pods al clúster durante picos de carga, asegurando una utilización óptima de los recursos y un rendimiento consistente.
Instalación Sencilla: El Chart de Helm se puede instalar fácilmente a través de la aplicación Artifact Hub, lo que simplifica el despliegue y la gestión de DataSunrise en Kubernetes.

Requisitos Previos

Nuestro chart de Helm funciona tanto con Kubernetes vanilla como con servicios de Kubernetes gestionados como AWS EKS, Azure AKS y Google Cloud GKE. Para esta guía, utilizaremos AWS EKS para demostrar los pasos de despliegue.

Necesitarás los siguientes componentes en tu entorno:

Clúster EKS: Crea un clúster EKS y pods en tu entorno de AWS
Helm 3.6+: Requerido para la gestión del chart
Kubernetes 1.21+: Esta es la versión probada más temprana, aunque el chart puede funcionar con versiones anteriores
Bases de Datos Externas: Requeridas para cargas de trabajo en producción y para el modo de Alta Disponibilidad (HA)

Por Qué Se Requieren Bases de Datos Externas para el Modo HA

DataSunrise utiliza 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 multi-servidor, se utiliza una base de datos PostgreSQL, MySQL/MariaDB o MS SQL Server para almacenar los datos comunes del Diccionario y de Auditoría.

Base de Datos de Auditoría

La Base de Datos de Auditoría en DataSunrise es esencial para almacenar registros detallados de todas las actividades monitoreadas en la base de datos, incluidas consultas SQL, acciones de los usuarios y eventos de seguridad. Esta base de datos proporciona una pista de auditoría completa y facilita la monitorización de seguridad al detectar actividades sospechosas. DataSunrise es compatible con PostgreSQL, MySQL, MariaDB y MS SQL Server para la Base de Datos de Auditoría. Es crucial asignar suficiente almacenamiento y gestionar las políticas de retención para manejar el crecimiento potencialmente significativo de los datos de auditoría.

Base de Datos de Diccionario

La Base de Datos de Diccionario contiene la configuración y los metadatos necesarios para que DataSunrise funcione, incluyendo información sobre instancias de bases de datos, reglas de seguridad, reglas de auditoría y roles de usuario. Garantiza que DataSunrise pueda operar sin problemas al mantener todos los datos de configuración requeridos. Al igual que la Base de Datos de Auditoría, DataSunrise es compatible con PostgreSQL, MySQL, MariaDB y MS SQL Server para la Base de Datos de Diccionario. Esta base de datos debe ser altamente disponible y estar protegida con contraseñas fuertes, ya que es vital para el funcionamiento ininterrumpido de DataSunrise.

Para obtener más información sobre cómo preparar bases de datos externas para su uso como bases de datos de auditoría y de configuración, consulta el Capítulo 4: Configuración Multi-Servidor (modo de Alta Disponibilidad) de la Guía de Administración. Al utilizar bases de datos externas tanto para la auditoría como para el diccionario, DataSunrise puede proporcionar una alta disponibilidad robusta, asegurando una operación continua y una monitorización de seguridad consistente en tu entorno de base de datos.

Configuración
Figura 1. Estructura de Despliegue de DataSunrise en K8S con Chart de Helm

Preparando Tu Clúster AWS EKS

Paso 1: Instalar las Herramientas Requeridas

Después de que tu clúster EKS y el nodo donde deseas instalar DataSunrise estén listos, instala las siguientes herramientas:

kubectl: Interactúa directamente con los clústeres de Kubernetes, esencial para la gestión del clúster y de las aplicaciones
Helm: Gestiona aplicaciones en Kubernetes a través de charts, simplificando despliegues y actualizaciones
AWS CLI: Gestiona recursos en AWS, útil para automatizar tareas en AWS e integrar servicios

Instalar kubectl

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

Instalar Helm

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

Instalar AWS CLI

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

Paso 2: Configurar las Credenciales de AWS

Configura tus credenciales de AWS ejecutando el siguiente comando:

aws configure

Después de ejecutar este comando, se te pedirá ingresar tu AWS Access Key ID, AWS Secret Access Key, nombre de la región predeterminada y el formato de salida preferido:

AWS Access Key ID [None]: ************
AWS Secret Access Key [None]: ************
Default Region name [None]: us-east-2
Default output format [None]: json

Paso 3: Configurar kubectl para EKS

Configura tu kubectl para interactuar con el clúster EKS especificado en la región indicada. Después de actualizar el kubeconfig, verifica la actualización comprobando el estado de los pods en el espacio de nombres kube-system:

aws eks update-kubeconfig --region <nombre_de_la_región> --name <nombre_del_cluster>
kubectl get pods -n kube-system -l k8s-app=aws-node -o wide

Instalando DataSunrise Usando Helm

Paso 1: Descargar e Instalar el Chart de Helm

Puedes descargar manualmente el archivo values.yaml del chart desde el Artifact Hub o instalar el chart de Helm utilizando los siguientes comandos:

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

Figura 2. Instalación del Paquete Helm de DataSunrise

La estructura del directorio debe ser la siguiente:

my-chart/
├── Chart.yaml
├── charts/
├── templates/
├── values.yaml

Paso 2: Configurar values.yaml

Abre y edita el archivo values.yaml. Necesitarás editar los siguientes valores:

envVars: Configura las propiedades de tu base de datos de diccionario y auditoría
uiService: Cambia el tipo de ClusterIP a LoadBalancer
ingress: Habilita la configuración de ingreso

Nota Importante de Seguridad: Es crucial utilizar contraseñas fuertes en la configuración de tu aplicación. Una contraseña fuerte debe tener más de 8-12 caracteres e incluir una combinación de letras mayúsculas y minúsculas, dígitos y caracteres especiales. Por ejemplo: P@ssw0rd#2024!

Ejemplo de Configuración de AWS Secrets Manager

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

Configuración de Variables de Entorno

envVars:
  - 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

Configuración del Servicio de Interfaz de Usuario (UI Service)

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

Configuración del Ingreso (Ingress)

ingress:
  enabled: true
  className: ""

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

localSettingsPersistentVolume:
  ## Si es 'true', se creará/usará una Persistent Volume Claim.
  ## Si es 'false', se usará emptyDir.
  enabled: false

Paso 3: Configurar el Ingreso (Ingress)

Para conectarte a la interfaz web de DataSunrise, necesitas configurar el ingreso:

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

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

A continuación, necesitas establecer el host para tu Ingress. Para encontrar el enlace del balanceador de carga, navega al panel de control de tu clúster 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, utilízala para establecer el campo host en tu configuración de Ingress.

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

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

Configuración Completa del Ingreso

ingress:
  enabled: true
  className: "nginx"
  ## Se necesitan algunas anotaciones adicionales para el ingreso.
  ## Si usas nginx, las anotaciones necesarias ya se encuentran a continuación.
  ## Si utilizas otro ingreso, deberás encontrar anotaciones similares para tu clase.
  ## Se requieren las anotaciones para el backend HTTPS y la "sesión persistente".
  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í la URL de tu balanceador de carga
      paths:
        - path: /
          pathType: ImplementationSpecific

Paso 4: Instalar DataSunrise

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

helm install ds .

Para rastrear el estado de la instalación, utiliza el siguiente comando:

kubectl get pods

Si el pod no se está iniciando, revisa los registros:

kubectl logs <nombre_del_pod>

Paso 5: Acceder a la Interfaz Web de DataSunrise

Después de que el pod de DataSunrise esté en funcionamiento, deberías poder conectar a la interfaz web de DataSunrise utilizando el enlace del LoadBalancer obtenido en el paso anterior. Alternativamente, puedes verificar los servicios utilizando el siguiente comando:

kubectl get services

Figura 5. Resultados de Ejemplo de ‘kubectl get services’

Figura 6. Conectando a la Consola Web de DataSunrise

Paso 6: Actualizando DataSunrise

Si deseas actualizar DataSunrise a una versión más reciente, modifica la versión especificada en el archivo values.yaml a la versión deseada. Una vez realizados los cambios necesarios, ejecuta el siguiente comando para actualizar DataSunrise:

helm upgrade ds .

Configurando la Conexión a la Base de Datos de Destino

Cuando tu clúster de DataSunrise construido con Kubernetes y Docker esté en funcionamiento, podrás configurar las Reglas de DataSunrise para auditar, asegurar o enmascarar las columnas sensibles de tu base de datos. Consulta la sección “Casos de Uso de DataSunrise” de la Guía del Usuario de DataSunrise para obtener más información.

DataSunrise interactúa con una base de datos de destino y recibe toda la información necesaria para su operación a través de una cuenta de usuario de dicha base de datos. La cuenta, el nombre de usuario y la contraseña se especifican en el perfil de la base de datos de destino en la Consola Web. Puedes usar la cuenta del administrador de la base de datos para la conexión, pero también es posible utilizar 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 diversas bases de datos.

Después de configurar el usuario de la base de datos para recuperar los metadatos de la base de datos, procede con los siguientes pasos para conectar DataSunrise a través de la consola web:

Paso 1: Iniciar Sesión en la Consola Web de DataSunrise

Utiliza la dirección IP externa obtenida en el paso anterior para acceder a la Consola Web de DataSunrise.

Paso 2: Agregar la Instancia de la Base de Datos de Destino

Navega a Configuración → Instancias de Base de Datos
Haz clic en “Agregar Nueva Instancia” y completa 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 de destino
- Método de Autenticación: Elige el método apropiado (por ejemplo, usuario/contraseña de la base de datos, Active Directory)
- Tipo de Base de Datos: Selecciona el tipo de tu base de datos de destino (por ejemplo, MS SQL, PostgreSQL)
- Puerto: El número de puerto en el que la base de datos está en funcionamiento
- Nombre de la Base de Datos: El nombre de la base de datos de destino

Paso 3: Probar la Conexión

Haz clic en el botón “Probar” para asegurarte de que DataSunrise pueda conectarse exitosamente a la base de datos de destino
Una vez que la prueba de conexión sea exitosa, haz clic en “Guardar” para agregar la instancia de la base de datos a DataSunrise

Paso 4: Configurar las 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 requerimientos.

Probar Conexión
Figura 7. Probando la Conexión en DataSunrise

Figura 8. Estableciendo Conexión Proxy en DataSunrise

Integrando AWS Secrets Manager con AWS EKS

AWS Secrets Manager es una herramienta robusta que ofrece encriptación en reposo y rotación de secretos, lo que la convierte en una opción ideal para gestionar de forma segura la información sensible. Dada su aprobación por numerosos equipos de seguridad, es una solución confiable para el manejo de secretos en entornos en la nube. Para mejorar la seguridad en despliegues en AWS, como con Amazon EKS, puedes aprovechar AWS Secrets Manager para asegurar que tus aplicaciones permanezcan seguras y cumplan con las mejores prácticas.

Existen múltiples formas de utilizar el servicio AWS Secrets Manager en Pods de EKS.

Utilizando el Controlador CSI de Kubernetes Secrets Store

Si bien existen múltiples implementaciones personalizadas que ofrecen flexibilidad, también requieren importantes esfuerzos de desarrollo, mantenimiento y operaciones. Un enfoque más estandarizado y eficiente es utilizar el Controlador CSI de Kubernetes Secrets Store. Este controlador integra almacenes de secretos con Kubernetes a través de un volumen de Container Storage Interface (CSI), permitiendo que los secretos de AWS Secrets Manager se monten directamente en el pod.

El Controlador CSI de Secrets Store simplifica el proceso de gestión de secretos al proporcionar una interfaz nativa de Kubernetes para la administración de secretos. Reduce la sobrecarga asociada con soluciones personalizadas y garantiza un método consistente y seguro para el manejo de secretos dentro de tu entorno Kubernetes.

Figura 9. AWS Secrets Manager

Para obtener más información sobre el controlador y su uso, consulta estos recursos:

Pasos de Implementación

Paso 1: Instalar el Driver CSI de Secrets Store

Debes asegurarte de que el controlador CSI secrets-store.csi.k8s.io esté instalado en tu clúster de Kubernetes. Este controlador 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

Paso 2: Crear un Secreto en AWS Secrets Manager

Crea un secreto dentro de AWS Secrets Manager en la misma región que tu clúster, ya sea utilizando AWS CLI o a través de la Consola de Administración de AWS.

Paso 3: Establecer Variables de Entorno

Define dos variables de entorno: REGION y CLUSTERNAME. Estas variables definen la región de AWS y el nombre del clúster EKS.

REGION=<tu_región_eks>
CLUSTERNAME=<tu_nombre_del_cluster>

Paso 4: Crear el Secreto

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 (Amazon Resource Name) del secreto creado.

SECRET_ARN=$(aws --query ARN --output text secretsmanager create-secret --name <tu_nombre_del_secreto> --secret-string '{"<clave1>":"<valor1>", "<clave2>":"<valor2>"}' --region "$REGION")

Paso 5: Crear una Política IAM

Crea una política IAM ejecutando el siguiente comando. Después de ejecutarlo, 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 <tu_nombre_de_política> --policy-document '{
    "Version": "2012-10-17",
    "Statement": [ {
        "Effect": "Allow",
        "Action": ["secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret"],
        "Resource": ["'$SECRET_ARN'"]
    } ]
}')

Paso 6: Crear una Cuenta de Servicio

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

eksctl create iamserviceaccount --name <tu_nombre_de_cuenta_de_servicio> --region="$REGION" --cluster "$CLUSTERNAME" --attach-policy-arn "$POLICY_ARN" --approve --override-existing-serviceaccounts

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

Paso 7: Crear AWS Secret Provider Class

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

Paso 8: Modificar values.yaml

Modifica el archivo values.yaml utilizando los secretos que creaste en el Paso 4. Deberás especificar el parámetro envVarsSecretProviderClassName con el nombre del SecretProviderClass que creaste en el Paso 7. Después de modificar todos los campos necesarios en values.yaml, puedes continuar con el despliegue mediante Helm.

Figura 10. Especificar Parámetro

Nota: Si creas un secreto de Kubernetes utilizando un manifiesto YAML, debes incluir el secreto en codificación base64. Consulta el siguiente ejemplo:

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

---
# values.yaml
envVars:
  - name: DICTIONARY_PASS
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: password

Conclusión

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

Utilizar contraseñas fuertes junto con un servicio de gestión de secretos como AWS Secrets Manager mejora significativamente la seguridad de tus despliegues. Al seguir estos pasos, puedes gestionar e inyectar de forma segura los secretos de AWS Secrets Manager en tus aplicaciones DataSunrise desplegadas mediante Helm en EKS.