Homepage
Notizie Professionali
Esecuzione di DataSunrise su Kubernetes Utilizzando il Grafico Helm

Esecuzione di DataSunrise su Kubernetes Utilizzando il Grafico Helm

Il deployment delle applicazioni in Kubernetes può essere complesso, richiedendo una conoscenza dettagliata dei suoi vari componenti e delle loro funzioni. Helm semplifica questo processo, rendendo il deployment Kubernetes semplice e gestibile. Invece di creare e mantenere manualmente molteplici manifesti YAML per ogni oggetto Kubernetes, Helm consolida tutto in un unico pacchetto che può essere facilmente distribuito al tuo cluster Kubernetes. Questo riduce notevolmente il tempo e la complessità coinvolti nella gestione delle applicazioni Kubernetes.

DataSunrise ha creato un Grafico Helm per facilitare l’installazione e il funzionamento di DataSunrise su Kubernetes. Helm semplifica la gestione delle applicazioni Kubernetes, unificando e semplificando il processo di deployment per DataSunrise. Con Helm, puoi facilmente installare e aggiornare DataSunrise come necessario in qualsiasi dei tuoi ambienti Kubernetes, compresi i provider cloud AWS EKS, Azure AKS e Google Cloud GKE. Il grafico supporta molteplici casi d’uso basati sui valori forniti.

Le caratteristiche principali del Grafico Helm di DataSunrise includono la funzionalità proxy, in cui un proxy viene utilizzato su ciascun nodo e Kubernetes gestisce il bilanciamento del carico tra di essi. Supporta anche l’autoscaling, utilizzando il potente Sensitive Data Discovery per aggiungere automaticamente nuovi pod al cluster durante i picchi di carico. Inoltre, il Grafico Helm può essere facilmente installato tramite l’applicazione Artifact Hub, semplificando il deployment e la gestione di DataSunrise su Kubernetes.

Prerequisiti

Il nostro grafico helm funziona sia con Kubernetes vanilla che con servizi Kubernetes gestiti come EKS di AWS, AKS di Azure e GKE di Google Cloud. Per questo articolo, utilizziamo EKS di AWS per dimostrare i passaggi successivi.

Avremo bisogno di avere i seguenti componenti nel nostro ambiente. Puoi anche trovare i comandi utilizzati per installare i componenti necessari nella sezione successiva.

Crea un cluster EKS e i pod su AWS.
Helm 3.6+
Kubernetes 1.21+ – Questa è la versione più precoce testata di Kubernetes. È possibile che questo grafico funzioni con versioni precedenti.
Database esterni per carichi di lavoro in produzione e modalità HA

Perché abbiamo bisogno di database esterni in modalità HA?

DataSunrise utilizza due tipi chiave di database per memorizzare i suoi dati operativi: il Database di Audit e il Database di Dizionario. Per garantire alta disponibilità e scalabilità, DataSunrise può essere configurato su più server. Quando si distribuisce DataSunrise in una configurazione multi-server, viene utilizzato un database PostgreSQL, MySQL/MariaDB o MS SQL Server per memorizzare i dati comuni di Dizionario e Audit.

Il Database di Audit in DataSunrise è essenziale per memorizzare log dettagliati di tutte le attività del database monitorate, inclusi le query SQL, le azioni degli utenti e gli 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 di Audit. È cruciale allocare sufficiente spazio di archiviazione e gestire le politiche di retention per gestire la potenziale crescita significativa dei dati di audit.

Il Database di Dizionario contiene la configurazione e i metadati necessari per far funzionare DataSunrise, come informazioni sui database esistenti, regole di sicurezza, regole di audit e ruoli degli utenti. Garantisce che DataSunrise possa funzionare senza problemi mantenendo tutti i dati di configurazione richiesti. Come il Database di Audit, DataSunrise supporta PostgreSQL, MySQL, MariaDB e MS SQL Server per il Database di Dizionario. Questo database dovrebbe essere altamente disponibile e protetto con password forti perché è vitale per il funzionamento ininterrotto di DataSunrise.

Per ulteriori informazioni sulle istruzioni per preparare i database esterni da utilizzare come database di audit e di configurazione, si prega di consultare il Capitolo 4 della Guida Amministrativa: Configurazione MultiServer (modalità Alta Disponibilità). Utilizzando database esterni sia per i database di Audit che di Dizionario, DataSunrise può fornire una robusta alta disponibilità, garantendo un funzionamento continuo e un monitoraggio coerente della sicurezza all’interno del tuo ambiente di database.

Immagine 1. Struttura del Deployment di DataSunrise su K8S con Grafico Helm

Come preparare il cluster AWS EKS

Passo – 1: Dopo che il cluster EKS e il nodo dove si desidera installare DataSunrise sono pronti per l’uso, installi:

kubectl: Interagisce direttamente con i cluster Kubernetes, essenziale per la gestione dei cluster e delle applicazioni.
Helm: Gestisce le applicazioni Kubernetes attraverso grafici, semplificando installazioni e aggiornamenti.
AWS CLI: Gestisce le risorse AWS, utile per automatizzare i compiti AWS e integrare servizi.

#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

#helm

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

#awscli

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

Passo – 2: Ora possiamo configurare le credenziali in awscli:

Esegui questo comando: aws configure

Dopo averlo eseguito, ti verrà chiesto di inserire il tuo ID chiave di accesso AWS, la tua chiave di accesso segreta AWS, 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

Passo – 3: Successivamente, configura il tuo kubectl per interagire con il cluster EKS specificato nella regione data. Dopo aver aggiornato il kubeconfig, verifica l’aggiornamento controllando lo stato dei pod nel namespace kube-system.

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

Installazione di DataSunrise usando HELM

Passo – 1: Scarica il file values.yaml del grafico HELM manualmente da https://artifacthub.io/packages/helm/datasunrise/datasunrise o installa il grafico HELM usando il comando:

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

Immagine 2. Installazione del Pacchetto Helm di Datasunrise

La struttura della directory dovrebbe essere la seguente:

my-chart/

├── Chart.yaml

├── charts/

├── templates/

├── values.yaml

Apri ed edita il file values.yaml. Modifica i seguenti valori:

enVars – per configurare le proprietà del tuo database di dizionario e audit.
Cambia il tipo di uiService da ClusterIp a LoadBalancer.
Abilita l’ingress.

È cruciale utilizzare password forti nella configurazione dell’applicazione. Una password forte dovrebbe avere più di 8-12 caratteri e includere una combinazione di lettere maiuscole e minuscole, cifre e caratteri speciali. Ad esempio, P@ssw0rd#2024!. La dimostrazione dell’uso di AWS Secret Manager è descritta anche nel sottosuccessivo articolo.

apiVersion: secrets-store.csi.x-k8s.io/v1alpha1
kind: SecretProviderClass
metadata:
  name: aws-secrets
  namespace: default #Modifica con il tuo namespace preferito
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: {}
  # Esempi:
  # - 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: Se il tuo pod si blocca in stato “Pending”, disattiva volume:

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

Passo – 2: Per connettersi alla web-UI di Datasunrise, dobbiamo 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 il grafico ingress-nginx dal repository specificato e lo installa nel namespace ingress-nginx, creando il namespace se non esiste già. Questa configurazione ti permetterà di gestire l’accesso esterno ai tuoi servizi DataSunrise tramite le risorse Ingress di Kubernetes.

Successivamente, dobbiamo impostare l’host per il tuo Ingress. Per trovare il link del LoadBalancer, vai al tuo dashboard del cluster AWS EKS. Poi, vai su “Risorse” -> “Servizio e networking” -> “Servizio” -> “ingress-nginx-controller”, e copia l’URL del LoadBalancer. Una volta che hai l’URL, usalo per impostare il campo host (“-host”) nella tua configurazione Ingress.

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

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

ingress:
  enabled: false
  className: "nginx"
  ## Alcune annotazioni aggiuntive sono necessarie per l'ingress.
  ## Se stai usando nginx, le annotazioni necessarie sono già presenti qui sotto.
  ## Se usi un ingresso diverso, devi trovare annotazioni simili per la tua classe.
  ## sono necessarie le annotazioni del backend HTTPS e 'sticky session'.
  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: #inserisci qui l'URL del tuo loadbalancer
      paths:
        - path: /
          pathType: ImplementationSpecific

Passo – 3: Dopo aver configurato l’host, puoi installare DataSunrise usando Helm. Assicurati di essere nella directory contenente lo script del grafico Helm. Quindi, esegui il seguente comando:

“helm install ds .”

Per tracciare lo stato dell’installazione, usa il seguente comando:

“kubectl get pods”

Controlla i log del pod se il pod non si avvia:

“kubectl logs ”

Passo – 4: Dopo che il pod di datasunrise è in esecuzione, dovresti essere in grado di connetterti alla web-UI di Datasunrise con il precedente link del LoadBalancer. Oppure, puoi controllare utilizzando questo comando: kubectl get services.

Immagine 5. Risultati di esempio di ‘kubectl get services’

Immagine 6. Connessione alla Console Web di DataSunrise

Passo – 5: Se vuoi aggiornare DataSunrise a una versione più recente, devi modificare la versione specificata nel file values.yaml alla versione desiderata. Una volta apportate le modifiche necessarie, esegui il seguente comando per aggiornare DataSunrise: “helm upgrade ds .”

Configurare la Connessione al Database di Destinazione

Quando il tuo cluster DataSunrise costruito con Kubernetes e Docker è in esecuzione, puoi configurare le Regole DataSunrise per auditare, proteggere o mascherare le tue colonne di database sensibili. Vedi la sezione “DataSunrise Use Cases” della Guida Utente di DataSunrise.

DataSunrise interagisce con un database di destinazione e riceve tutte le informazioni richieste per l’operazione attraverso un account utente di questo database (l’account, il nome utente e la password, che sono specificati nel profilo del database di destinazione nella Console Web). Puoi utilizzare l’account dell’amministratore del database per la connessione, ma è anche possibile utilizzare qualsiasi altro account utente con privilegi sufficienti. La sezione della guida utente: 5.2 Creazione di Utenti del Database Necessari per Ottenere i Metadati del Database descrive le azioni richieste per stabilire una connessione tra DataSunrise e vari database. Dopo aver configurato l’utente del database per il recupero dei metadati del database, è possibile procedere con i seguenti passaggi per connettersi a DataSunrise tramite la console web.

Accedi alla Console Web di DataSunrise.
Utilizza l’indirizzo IP esterno ottenuto dal passaggio precedente per accedere alla Console Web di DataSunrise.
Aggiungi Istanze di Database di Destinazione.

Accedi alla Configurazione > seleziona Istanze di Database.
Fai clic su “Aggiungi Nuova Istanza” e compila i dettagli richiesti:

Nome Logico: Un nome di riferimento per il database.
Nome Host o IP: L’indirizzo del database di destinazione.
Metodo di Autenticazione: Scegli il metodo appropriato (e.g., username/password del database, Active Directory).
Tipo di Database: Seleziona il tipo del tuo database di destinazione (e.g., MS SQL, PostgreSQL).
Porta: Il numero di porta su cui è in esecuzione il database.
Nome del Database: Il nome del database di destinazione.

Test di Connessione.

Fai clic sul pulsante “Test” per garantire che DataSunrise possa connettersi con successo al database di destinazione.
Una volta che il test di connessione ha esito positivo, fai clic su “Salva” per aggiungere l’istanza di database a DataSunrise.

Imposta Regole di Sicurezza e Audit.

Accedi alla sezione Regole nella Console Web di DataSunrise. Crea e configura regole per auditing, sicurezza e mascheramento dei dati in base alle tue esigenze.

Immagine 7. Test di Connessione in DataSunrise

Immagine 8. Stabilire la Connessione Proxy in DataSunrise

Conclusione

Il Grafico Helm fornito da DataSunrise con Kubernetes semplifica il processo di deployment, offrendo funzionalità chiave come la funzionalità proxy e l’autoscaling, garantendo prestazioni ottimali e affidabilità. Inoltre, aderendo alle migliori pratiche come la configurazione di database esterni e l’utilizzo di password forti, le organizzazioni possono migliorare la postura di sicurezza dei loro deployment. Con DataSunrise distribuito in Kubernetes, le organizzazioni possono proteggere con fiducia i loro dati sensibili beneficiando della scalabilità e flessibilità degli ambienti containerizzati.

Integrazione del Gestore Segreti AWS con AWS EKS

AWS Secrets Manager è uno strumento robusto che offre crittografia a riposo e rotazione dei segreti, rendendolo una scelta ideale per gestire in modo sicuro le informazioni sensibili. Dato che è approvato da molti team di sicurezza, è una soluzione fidata per la gestione dei segreti all’interno degli ambienti cloud. Pertanto, per migliorare la sicurezza nei deployment AWS, come con Amazon EKS, puoi sfruttare AWS Secrets Manager per garantire che le tue applicazioni rimangano sicure e conformi alle migliori pratiche.

Ci sono vari modi di utilizzare il servizio AWS Secrets Manager nei Pod EKS.

Utilizzo del Driver CSI per il Negozio di Segreti di Kubernetes

Mentre molte implementazioni personalizzate offrono flessibilità, richiedono anche significativi sforzi di sviluppo, manutenzione e operativi. Un approccio più standardizzato ed efficiente è utilizzare il Driver CSI per il Negozio di Segreti di Kubernetes. Questo driver integra i negozi di segreti con Kubernetes tramite un volume Container Storage Interface (CSI), consentendo ai segreti di AWS Secrets Manager di essere montati direttamente sul pod.

Il Driver CSI per il Negozio di Segreti semplifica il processo di gestione dei segreti fornendo un’interfaccia Kubernetes nativa per la gestione dei segreti. Riduce il carico associato a soluzioni personalizzate e garantisce un metodo coerente e sicuro per gestire i segreti all’interno del tuo ambiente Kubernetes.

Immagine 9. Gestore dei Segreti AWS

Puoi controllare questi link per esplorare di più sul driver e sul suo utilizzo. Le istruzioni per installare questi requisiti sono menzionate anche di seguito.

Passi da Seguire

Installa il Driver CSI del Negozio di Segreti. Devi assicurarti che il driver CSI secrets-store.csi.k8s.io sia installato nel tuo cluster Kubernetes. Questo driver consente a Kubernetes di interagire con i sistemi di gestione dei segreti esterni.

“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”

Crea un segreto all’interno di AWS Secrets Manager nella stessa regione del tuo cluster utilizzando l’AWS CLI (Interfaccia a Riga di Comando). Puoi farlo anche nella Console di Gestione AWS.

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

REGION=

CLUSTERNAME=

3.2: Crea il segreto in AWS Secrets Manager. Include oggetti JSON delle tue credenziali o segreti. Dopo aver eseguito questo comando, la variabile SECRET_ARN conterrà l’ARN (Nome Risorsa Amazon) del segreto creato.

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

Crea una Policy IAM eseguendo il comando qui sotto. Dopo aver eseguito il 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  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [ {
        "Effect": "Allow",
        "Action": ["secretsmanager:GetSecretValue", "secretsmanager:DescribeSecret"],
        "Resource": ["$SECRET_ARN"]
    } ]
}')

Crea un account di servizio associato alla policy IAM che hai creato in precedenza utilizzando `eksctl`. Prima di eseguire il comando, assicurati di avere eksctl installato e configurato sulla tua macchina.

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

Il flag –approve conferma la creazione dell’account di servizio senza chiedere conferma, e –override-existing-serviceaccounts consente al comando di sovrascrivere gli account di servizio esistenti con lo stesso nome.

Crea AWS Secret Provider Class.

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")

Modifica il values.yaml utilizzando i segreti che abbiamo creato nel passo-2. Dovrai specificare il parametro envVarsSecretProviderClassName con il nome del SecretProviderClass creato nel passo-5. Dopo aver modificato tutti i campi necessari in values.yaml, puoi continuare con il deployment di helm.

Immagine 10. Specifica Parametro

Nota: Se crei un segreto k8s utilizzando il manifest yaml, dovresti includere il segreto in codifica base64. Vedi l’esempio qui sotto:

your_secret_file.yaml:

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

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

Conclusione

Utilizzare password forti in combinazione con un servizio di gestione dei segreti come AWS Secrets Manager migliora significativamente la sicurezza dei tuoi deployment. Seguendo questi passaggi, puoi gestire e inserire in modo sicuro i segreti da AWS Secrets Manager nelle tue applicazioni DataSunrise distribuite tramite Helm su EKS.