Esecuzione di DataSunrise su Kubernetes utilizzando Helm Chart

Introduzione

Distribuire le applicazioni in Kubernetes può risultare complesso, poiché richiede una conoscenza dettagliata dei suoi molteplici componenti e delle rispettive funzioni. Helm semplifica questo processo, rendendo la distribuzione in Kubernetes diretta e gestibile. Invece di creare e mantenere manualmente molti manifest YAML per ogni oggetto di Kubernetes, Helm consolida tutto in un unico pacchetto che può essere facilmente distribuito nel cluster Kubernetes. Ciò riduce in modo significativo il tempo e la complessità necessari per gestire le applicazioni in Kubernetes.

DataSunrise ha creato un Helm Chart per facilitare l’installazione e il funzionamento di DataSunrise su Kubernetes. Helm semplifica la gestione delle applicazioni in Kubernetes, unificando e semplificando il processo di distribuzione di DataSunrise. Con Helm Lei può facilmente installare e aggiornare DataSunrise, secondo le necessità, in qualsiasi ambiente Kubernetes, inclusi fornitori cloud come AWS EKS, Azure AKS e i cluster Google Cloud GKE. Il chart supporta molteplici casi d’uso in base ai valori forniti.

Caratteristiche principali dell’Helm Chart di DataSunrise

L’Helm Chart di DataSunrise include diverse funzionalità chiave che ne migliorano la funzionalità e la facilità d’uso:

• Funzionalità di Proxy: Un proxy viene utilizzato su ogni nodo, e Kubernetes gestisce il bilanciamento del carico tra di essi, garantendo una distribuzione efficiente del traffico e prestazioni migliorate.

• Autoscaling: Utilizza una potente Sensitive Data Discovery per aggiungere automaticamente nuovi pod al cluster durante i picchi di carico, assicurando un’ottimale allocazione delle risorse e prestazioni costanti.

• Installazione Semplice: L’Helm Chart può essere facilmente installato tramite l’applicazione Artifact Hub, semplificando la distribuzione e la gestione di DataSunrise su Kubernetes.

Prerequisiti

Il nostro Helm chart funziona sia con Kubernetes vanilla che con servizi gestiti di Kubernetes, come AWS EKS, Azure AKS e Google Cloud GKE. Per questa guida verrà utilizzato AWS EKS per dimostrare i passaggi per la distribuzione.

Lei dovrà disporre dei seguenti componenti nel suo ambiente:

1. Cluster EKS: Crei un cluster EKS e pod nel suo ambiente AWS
2. Helm 3.6+: Necessario per la gestione dei chart
3. Kubernetes 1.21+: Questa è la versione minima testata, anche se il chart potrebbe funzionare con versioni precedenti
4. Database Esterni: Richiesti per carichi di lavoro in produzione e per la modalità High Availability (HA)

Perché sono necessari database esterni per la modalità HA

DataSunrise utilizza due tipologie chiave di database per memorizzare i dati operativi: il Database Audit e il Database Dictionary. Per garantire alta disponibilità e scalabilità, DataSunrise può essere configurato su più server. Durante la distribuzione di DataSunrise in una configurazione multi-server, viene utilizzato un database PostgreSQL, MySQL/MariaDB o MS SQL Server per memorizzare i dati comuni del Dictionary e dell’Audit.

Database Audit

Il Database Audit in DataSunrise è essenziale per memorizzare i log dettagliati di tutte le attività monitorate sul database, incluse query SQL, azioni degli utenti ed eventi di sicurezza. Questo database fornisce una traccia di audit completa e facilita il monitoraggio della sicurezza rilevando attività sospette. DataSunrise supporta PostgreSQL, MySQL, MariaDB e MS SQL Server per il Database Audit. È fondamentale allocare spazio di memorizzazione sufficiente e gestire le politiche di conservazione per far fronte alla potenziale crescita significativa dei dati di audit.

Database Dictionary

Il Database Dictionary contiene la configurazione e i metadati necessari per il funzionamento di DataSunrise, inclusi le informazioni relative alle istanze di database, alle regole di sicurezza, alle regole di audit e ai ruoli utente. Esso assicura il regolare funzionamento di DataSunrise memorizzando tutti i dati di configurazione richiesti. Come per il Database Audit, DataSunrise supporta PostgreSQL, MySQL, MariaDB e MS SQL Server per il Database Dictionary. Questo database deve essere altamente disponibile e protetto da password robuste, in quanto è vitale per il funzionamento ininterrotto di DataSunrise.

Per ulteriori informazioni sulla preparazione dei database esterni da utilizzare come database di audit e configurazione, si consulti il Capitolo 4 della Guida Amministratore: Configurazione MultiServer (modalità High Availability). Utilizzando database esterni sia per l’Audit che per il Dictionary, DataSunrise può garantire un’alta disponibilità robusta, assicurando il funzionamento continuo e un monitoraggio della sicurezza costante nell’ambiente del database.

Figura 1. Struttura di Distribuzione di DataSunrise su K8S con Helm Chart

Preparazione del Cluster AWS EKS

Passo 1: Installare gli Strumenti Richiesti

Dopo che il cluster EKS e il nodo sul quale intende installare DataSunrise sono pronti, installi i seguenti strumenti:

• kubectl: Interagisce direttamente con i cluster Kubernetes, essenziale per la gestione del cluster e delle applicazioni
• Helm: Gestisce le applicazioni in Kubernetes tramite chart, semplificando distribuzioni e aggiornamenti
• AWS CLI: Gestisce le risorse AWS, utile per automatizzare le operazioni su AWS e integrare i servizi

Installare 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

Installare Helm

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

Installare AWS CLI

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

Passo 2: Configurare le Credenziali AWS

Configuri le sue credenziali AWS eseguendo il seguente comando:

aws configure

Dopo aver eseguito questo comando, le verrà richiesto di inserire il suo AWS Access Key ID, AWS Secret Access Key, il nome della regione predefinita e il formato di output preferito:

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

Passo 3: Configurare kubectl per EKS

Configuri kubectl per interagire con il cluster EKS specificato nella regione indicata. Dopo aver aggiornato il kubeconfig, verifichi l’aggiornamento controllando lo stato dei pod nel namespace kube-system:

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

Installare DataSunrise utilizzando Helm

Passo 1: Scaricare e Installare l’Helm Chart

Lei può scaricare manualmente il file values.yaml dell’Helm chart da Artifact Hub oppure installare l’Helm chart utilizzando i seguenti comandi:

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

La struttura della directory dovrebbe essere la seguente:

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

Passo 2: Configurare values.yaml

Aperti ed editi il file values.yaml. Dovrà modificare i seguenti valori:

• envVars: Configuri le proprietà del suo database dictionary e audit
• uiService: Modifichi il tipo da ClusterIP a LoadBalancer
• ingress: Abiliti la configurazione dell’ingress

Importante Nota di Sicurezza: È fondamentale utilizzare password robuste nella configurazione dell’applicazione. Una password forte dovrebbe essere composta da oltre 8-12 caratteri e includere una combinazione di lettere maiuscole e minuscole, cifre e caratteri speciali. Ad esempio: P@ssw0rd#2024!

Esempio di Configurazione per AWS Secrets Manager

apiVersion: secrets-store.csi.x-k8s.io/v1alpha1
kind: SecretProviderClass
metadata:
  name: aws-secrets
  namespace: default # Modifichi con il suo namespace preferito
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

Configurazione delle Variabili d’Ambiente

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 

Configurazione del Servizio UI

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

Configurazione dell’Ingress

ingress:
  enabled: true
  className: ""

Nota: Se il suo pod rimane in stato “Pending”, disabiliti il volume:

localSettingsPersistentVolume:
  ## Se 'true', verrà creato/usato un Persistent Volume Claim.
  ## Se 'false', verrà usato emptyDir.
  enabled: false

Passo 3: Configurare l’Ingress

Per connettersi all’interfaccia web di DataSunrise, è necessario configurare l’ingress:

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

Questo comando scarica l’Helm chart ingress-nginx dal repository specificato e lo installa nel namespace ingress-nginx, creando il namespace se non esiste già. Questa configurazione consentirà di gestire l’accesso esterno ai servizi DataSunrise tramite le risorse Ingress di Kubernetes.

Successivamente, è necessario impostare l’host per l’Ingress. Per trovare il link del load balancer, visiti il dashboard del suo cluster AWS EKS, quindi vada su “Resources” → “Service and networking” → “Service” → “ingress-nginx-controller” e copi l’URL del LoadBalancer. Una volta ottenuto l’URL, usi questo per impostare il campo host nella configurazione dell’Ingress.

Figura 3. Come trovare il link del load balancer in AWS EKS (1)

Figura 4. Come trovare il link del load balancer in AWS EKS (2)

Configurazione Completa dell’Ingress

ingress:
  enabled: true
  className: "nginx"
  ## Alcune annotazioni aggiuntive sono necessarie per l’ingress.
  ## Se si utilizza nginx, le annotazioni necessarie sono già presenti qui sotto.
  ## Se si utilizza un altro ingress, è necessario trovare annotazioni analoghe per la propria classe.
  ## Le annotazioni per il backend HTTPS e per la "sticky session" sono necessarie.
  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: # Inserisca qui il link del suo load balancer
      paths:
        - path: /
          pathType: ImplementationSpecific

Passo 4: Installare DataSunrise

Dopo aver configurato l’host, può installare DataSunrise utilizzando Helm. Assicuri di essere nella directory contenente lo script dell’Helm chart, quindi esegua il seguente comando:

helm install ds .

Per verificare lo stato dell’installazione, usi il seguente comando:

kubectl get pods

Se il pod non si avvia, controlli i log:

kubectl logs <pod_name>

Passo 5: Accedere all’Interfaccia Web di DataSunrise

Dopo che il pod di DataSunrise è in esecuzione, dovrebbe essere in grado di connettersi all’interfaccia web di DataSunrise utilizzando il link del LoadBalancer ottenuto nel passo precedente. In alternativa, può controllare i servizi utilizzando questo comando:

kubectl get services

Figura 5. Esempio di risultati di “kubectl get services”

Figura 6. Connessione alla Console Web di DataSunrise

Passo 6: Aggiornare DataSunrise

Se desidera aggiornare DataSunrise a una versione più recente, modifichi la versione specificata nel file values.yaml con quella desiderata. Dopo aver apportato le modifiche necessarie, esegua il seguente comando per aggiornare DataSunrise:

helm upgrade ds .

Configurare la Connessione al Database di Destinazione

Quando il suo cluster DataSunrise basato su Kubernetes e Docker è in esecuzione, Lei potrà configurare le regole di DataSunrise per effettuare audit, garantire la sicurezza o mascherare le colonne sensibili del suo database. Veda la sezione “DataSunrise Use Cases” della Guida Utente di DataSunrise per ulteriori informazioni.

DataSunrise interagisce con un database di destinazione e riceve tutte le informazioni richieste per il suo funzionamento tramite un account utente di tale database. L’account, il nome utente e la password sono specificati nel profilo del database di destinazione nella Console Web. È possibile utilizzare l’account dell’amministratore del database per la connessione, ma è anche possibile utilizzare qualsiasi altro account utente con privilegi sufficienti. La sezione “5.2 Creating Database Users Required for Getting the Database’s Metadata” della guida utente descrive le azioni necessarie per stabilire una connessione tra DataSunrise e i vari database.

Dopo aver configurato l’utente database per il recupero dei metadati, proceda con i seguenti passaggi per connettersi a DataSunrise tramite la console web:

Passo 1: Accedere alla Console Web di DataSunrise

Utilizzi l’indirizzo IP esterno ottenuto dal passo precedente per accedere alla Console Web di DataSunrise.

Passo 2: Aggiungere l’Istanze del Database di Destinazione

1. Navigare su Configurazione → Istanze Database
2. Clicchi su “Aggiungi Nuova Istanza” e compili i dettagli richiesti:
   • Nome Logico: Un nome di riferimento per il database
   • Hostname o IP: L’indirizzo del database di destinazione
   • Metodo di Autenticazione: Scelga il metodo appropriato (ad es. username/password del database, Active Directory)
   • Tipo di Database: Selezioni il tipo del suo database di destinazione (ad es. MS SQL, PostgreSQL)
   • Porta: Il numero di porta su cui il database è in esecuzione
   • Nome Database: Il nome del database di destinazione

Passo 3: Testare la Connessione

1. Clicchi sul pulsante “Test” per verificare che DataSunrise possa connettersi con successo al database di destinazione
2. Una volta che il test di connessione è andato a buon fine, clicchi su “Salva” per aggiungere l’istanza del database a DataSunrise

Passo 4: Configurare Regole di Sicurezza e Audit

Navighi nella sezione Regole della Console Web di DataSunrise. Crei e configuri le regole per l’audit, la sicurezza e il mascheramento dei dati in base alle sue esigenze.

Figura 7. Testare la Connessione in DataSunrise

Figura 8. Stabilire una Connessione Proxy in DataSunrise

Integrare AWS Secrets Manager con AWS EKS

AWS Secrets Manager è uno strumento robusto che offre la crittografia a riposo e la rotazione dei segreti, rendendolo una scelta ideale per la gestione sicura delle informazioni sensibili. Data la sua approvazione da parte di molti team di sicurezza, è una soluzione affidabile per la gestione dei segreti negli ambienti cloud. Per migliorare la sicurezza nelle distribuzioni AWS, come ad esempio con Amazon EKS, Lei può sfruttare AWS Secrets Manager per garantire che le sue applicazioni restino sicure e in linea con le best practices.

Ci sono molteplici modalità per utilizzare il servizio AWS Secrets Manager nei Pod di EKS.

Utilizzo del Driver CSI per Kubernetes Secrets Store

Pur essendo possibili molte implementazioni personalizzate, le quali offrono flessibilità, esse richiedono notevoli sforzi in termini di sviluppo, manutenzione e operatività. Un approccio più standardizzato ed efficiente è utilizzare il Kubernetes Secrets Store CSI Driver. Questo driver integra i secrets store con Kubernetes tramite un volume Container Storage Interface (CSI), permettendo di montare i segreti provenienti da AWS Secrets Manager direttamente sul pod.

Il Secrets Store CSI Driver semplifica il processo di gestione dei segreti fornendo un’interfaccia nativa per Kubernetes, riducendo il sovraccarico associato a soluzioni personalizzate e garantendo un metodo coerente e sicuro per gestire i segreti all’interno del suo ambiente Kubernetes.

Figura 9. AWS Secrets Manager

Per ulteriori informazioni sul driver e sul suo utilizzo, consulti le seguenti risorse:

1. Kubernetes Secrets Store CSI Driver
2. AWS Secrets and Configuration Provider

Passaggi di Implementazione

Passo 1: Installare il CSI Secrets Store Driver

È necessario assicurarsi che il driver CSI secrets-store.csi.k8s.io sia installato nel suo cluster Kubernetes. Questo driver permette a Kubernetes di interagire con sistemi esterni di gestione dei segreti.

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

Passo 2: Creare un Segreto in AWS Secrets Manager

Crei un segreto all’interno di AWS Secrets Manager, nella stessa regione del suo cluster, usando l’AWS CLI o attraverso la AWS Management Console.

Passo 3: Impostare le Variabili d’Ambiente

Imposti due variabili d’ambiente: REGION e CLUSTERNAME. Queste variabili definiscono la regione AWS e il nome del cluster EKS.

REGION=<your_eks_region>
CLUSTERNAME=<your_cluster_name>

Passo 4: Creare il Segreto

Crei il segreto in AWS Secrets Manager. Includa oggetti JSON contenenti le credenziali o i segreti. Dopo l’esecuzione di questo comando, la variabile SECRET_ARN conterrà l’ARN (Amazon Resource Name) del segreto creato.

SECRET_ARN=$(aws --query ARN --output text secretsmanager create-secret --name <your_secret_name> --secret-string '{"<key1>":"<value1>", "<key2>":"<value2>"}' --region "$REGION")

Passo 5: Creare la Policy IAM

Crei una policy IAM eseguendo il comando sottostante. Dopo l’esecuzione del comando, la variabile POLICY_ARN conterrà l’ARN della policy IAM creata.

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

Passo 6: Creare un Service Account

Crei un service account associato alla policy IAM creata precedentemente utilizzando eksctl. Prima di eseguire il comando, si assicuri di avere eksctl installato e configurato sulla sua macchina.

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

Il flag --approve conferma la creazione del service account senza richiedere conferma, mentre --override-existing-serviceaccounts consente di sovrascrivere eventuali account esistenti con lo stesso nome.

Passo 7: Creare la Classe Provider di Segreti AWS

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

Passo 8: Modificare values.yaml

Modifichi il file values.yaml utilizzando i segreti creati al Passo 4. Dovrà specificare il parametro envVarsSecretProviderClassName con il nome della SecretProviderClass creata al Passo 7. Dopo aver modificato tutti i campi necessari in values.yaml, potrà procedere con la distribuzione tramite Helm.

Figura 10. Specifica Parametro

Nota: Se crea un segreto Kubernetes utilizzando un manifest YAML, includa il segreto in codifica base64. Veda l’esempio riportato di seguito:

# your_secret_file.yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-secret
type: Opaque
data:
  password: cGFzc3dvcmQxMjMK # password1234 in codifica base64

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

Conclusione

L’Helm Chart fornito da DataSunrise per Kubernetes semplifica il processo di distribuzione, offrendo funzionalità chiave quali la funzionalità di proxy ed l’autoscaling, garantendo prestazioni e affidabilità ottimali. Inoltre, seguendo le best practices quali la configurazione di database esterni e l’utilizzo di password robuste, le organizzazioni possono migliorare la postura di sicurezza delle loro distribuzioni. Con DataSunrise distribuito su Kubernetes, le organizzazioni possono proteggere con fiducia i dati sensibili, beneficiando allo stesso tempo della scalabilità e flessibilità degli ambienti containerizzati.

L’utilizzo di password robuste, in combinazione con un servizio di gestione dei segreti come AWS Secrets Manager, migliora notevolmente la sicurezza delle distribuzioni. Seguendo questi passaggi, Lei potrà gestire in modo sicuro ed iniettare i segreti da AWS Secrets Manager nelle sue applicazioni DataSunrise distribuite tramite Helm su EKS.