
Esecuzione di DataSunrise su Kubernetes Utilizzando Helm Chart
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 su Kubernetes diretto e gestibile. Invece di creare e mantenere manualmente più manifesti YAML per ciascun oggetto Kubernetes, Helm consolida tutto in un unico pacchetto che può essere facilmente distribuito al cluster Kubernetes. Questo riduce significativamente il tempo e la complessità coinvolti nella gestione delle applicazioni Kubernetes.
DataSunrise ha creato un Helm Chart per facilitare l’installazione e l’operazione di DataSunrise su Kubernetes in modo semplice. Helm semplifica la gestione delle applicazioni Kubernetes, unificando il processo di deployment per DataSunrise. Con Helm, è possibile installare e aggiornare DataSunrise facilmente secondo necessità in qualsiasi ambiente Kubernetes, comprese le piattaforme cloud AWS EKS, Azure AKS e Google Cloud GKE. Il chart supporta più casi d’uso in base ai valori forniti.
Le caratteristiche principali del DataSunrise Helm Chart includono la funzionalità proxy, dove un proxy viene utilizzato su ciascun nodo e Kubernetes gestisce il bilanciamento del carico tra loro. Supporta anche l’autoscaling, utilizzando un potente Discovery dei Dati Sensibili per aggiungere automaticamente nuovi pod al cluster durante i picchi di carico. Inoltre, l’Helm Chart può essere facilmente installato tramite l’applicazione Artifact Hub, semplificando il deployment e la gestione di DataSunrise su Kubernetes.
Prerequisiti
Il nostro helm chart funziona sia con Kubernetes vanilla che con servizi Kubernetes gestiti come AWS’s EKS, Azure’s AKS e Google Cloud’s GKE. Per questo articolo, utilizziamo AWS’s EKS per dimostrare i passaggi successivi.
Avremo bisogno dei seguenti componenti nel nostro ambiente. Può trovare anche i comandi utilizzati per installare i componenti necessari nella sezione successiva.
- Creare cluster EKS e pod nel tuo AWS.
- Helm 3.6+
- Kubernetes 1.21+ – Questa è la versione più antica di Kubernetes testata. È possibile che questo chart funzioni con versioni precedenti.
- Database esterni per carichi di lavoro di produzione e modalità HA
Perché abbiamo bisogno di database esterni in modalità HA?
DataSunrise utilizza due tipi principali di database per memorizzare i suoi dati operativi: l’Audit Database e il Dictionary Database. Per garantire alta disponibilità e scalabilità, DataSunrise può essere configurato su più server. Durante il deployment 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.
L’Audit Database in DataSunrise è essenziale per memorizzare log dettagliati di tutte le attività monitorate del database, comprese 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 l’Audit Database. È fondamentale allocare spazio di archiviazione sufficiente e gestire le politiche di retention per gestire la potenziale crescita significativa dei dati di audit.
Il Dictionary Database contiene la configurazione e i metadati necessari per operare DataSunrise, come informazioni sulle istanze del database, regole di sicurezza, regole di audit e ruoli utente. Garantisce che DataSunrise possa funzionare senza problemi mantenendo tutti i dati di configurazione richiesti. Come per l’Audit Database, DataSunrise supporta PostgreSQL, MySQL, MariaDB e MS SQL Server per il Dictionary Database. Questo database dovrebbe essere altamente disponibile e protetto con password forti perché è vitale per l’operazione ininterrotta di DataSunrise.
Per ulteriori informazioni sulle istruzioni per preparare i database esterni da utilizzare come database di audit e configurazione, si prega di fare riferimento al Capitolo 4 della Guida dell’Amministratore: Configurazione MultiServer (modalità Alta Disponibilità). Utilizzando database esterni per entrambi i database Audit e Dictionary, DataSunrise può fornire un’elevata disponibilità robusta, garantendo operazioni continue e un monitoraggio della sicurezza coerente nella tua ambiente database.

Immagine 1. Struttura di Deployment di DataSunrise su K8S con Helm Chart
Come preparare il cluster AWS EKS
Passaggio – 1: Dopo che il cluster EKS e il nodo dove si desidera installare DataSunrise sono pronti per l’uso, installare:
- kubectl: Interagisce direttamente con i cluster Kubernetes, essenziale per la gestione di cluster e applicazioni.
- Helm: Gestisce le applicazioni Kubernetes tramite chart, semplificando i deployment e gli aggiornamenti.
- AWS CLI: Gestisce le risorse AWS, utile per automatizzare le attività AWS e integrare i 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
Passaggio – 2: Ora possiamo configurare le credenziali in awscli:
Esegui questo comando: aws configure
Dopo averlo eseguito, le verrà chiesto di inserire il suo AWS Access Key ID, AWS Secret Access Key, nome della regione di default e formato output preferito.
AWS Access Key ID [None]: ************
AWS Secret access key [None]: ************
Nome della Regione di Default [None]: us-east-2
Passaggio – 3: Successivamente, configurare il suo kubectl per interagire con il cluster EKS specificato nella regione data. Dopo aver aggiornato il kubeconfig, verificare 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 utilizzando HELM
Passaggio – 1: Scaricare manualmente il file values.yaml dell’HELM chart da https://artifacthub.io/packages/helm/datasunrise/datasunrise o Installare l’HELM chart utilizzando il comando:
- helm repo add datasunrise https://www.datasunrise.com/helm-chart
- helm install my-datasunrise datasunrise/datasunrise –version 1.2.14
- Aprire e modificare il file values.yaml. Modificare i seguenti valori:
- enVars – per configurare le proprietà del tuo dictionary e audit database.
- Cambiare il tipo di uiService da ClusterIp a LoadBalancer.
- Abilitare l’ingress.

Immagine 2. Installazione del Pacchetto Datasunrise Helm
La struttura della directory dovrebbe essere la seguente:
my-chart/
├── Chart.yaml
├── charts/
├── templates/
├── values.yaml
È cruciale utilizzare password forti nella configurazione della sua applicazione. Una password forte dovrebbe essere lunga oltre 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 dell’AWS Secret Manager è anche descritta nel seguente sotto-articolo.
apiVersion: secrets-store.csi.x-k8s.io/v1alpha1 kind: SecretProviderClass metadata: name: aws-secrets namespace: default #Cambiare al 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 nello stato “Pending”, disabilitare il volume:
localSettingsPersistentVolume: ## Se 'true', allora verrà creato/usato il Persistent Volume Claim. ## Se 'false', allora verrà usato emptyDir. enabled: false
Passaggio – 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 estrae il chart ingress-nginx dal repository specificato e lo installa nel namespace ingress-nginx, creando il namespace se non esiste già. Questa configurazione le consentirà di gestire l’accesso esterno ai suoi servizi DataSunrise attraverso risorse Ingress di Kubernetes.
Dopo, dobbiamo impostare l’host per il suo Ingress. Per trovare il link del bilanciatore di carico, navigare nella dashboard del cluster AWS EKS. Successivamente, andare a “Risorse” -> “Servizio e rete” -> “Servizio” -> “ingress-nginx-controller”, e copiare l’URL del LoadBalancer. Una volta che ha l’URL, utilizzarlo per impostare il campo host (“-host”) nella configurazione del tuo Ingress.

Immagine 3. Come trovare il link del bilanciatore di carico in AWS EKS (1)

Immagine 4. Come trovare il link del bilanciatore di carico in AWS EKS (2)
ingress: enabled: false className: "nginx" ## Alcune annotazioni aggiuntive sono necessarie per l'ingress. ## Se sta utilizzando nginx, le annotazioni necessarie sono già presenti di seguito. ## Se utilizza un diverso ingress, bisogna trovare annotazioni simili per la tua classe. ## Le annotazioni di backend HTTPS e 'sessione sticky' 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: #inserisci qui l'URL del tuo bilanciatore di carico paths: - path: / pathType: ImplementationSpecific
Passaggio – 3: Dopo aver configurato l’host, può installare DataSunrise utilizzando Helm. Assicurarsi di essere nella directory che contiene lo script Helm chart. Quindi, eseguire il seguente comando:
“helm install ds .”
Per tracciare lo stato dell’installazione, utilizzare il seguente comando:
“kubectl get pods”
Controllare i log del pod se il pod non si avvia:
“kubectl logs
Passaggio – 4: Dopo che il pod datasunrise è in esecuzione, dovrebbe essere in grado di connettersi alla web-UI di DataSunrise con il precedente link del LoadBalancer. Oppure, può controllare utilizzando questo comando: kubectl get services.

Immagine 5. Risultati Campione di ‘kubectl get services’

Immagine 6. Connessione alla Console Web di DataSunrise
Passaggio – 5: Se desidera aggiornare DataSunrise a una versione più recente, deve modificare la versione specificata nel file values.yaml alla versione desiderata. Una volta apportate le modifiche necessarie, eseguire 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 è operativo, puoi configurare le Regole di DataSunrise per audit, sicurezza o mascheramento delle colonne sensibili del database. Veda la sezione “DataSunrise Use Cases” della Guida Utente di DataSunrise.
DataSunrise interagisce con un database di destinazione e riceve tutte le informazioni necessarie al funzionamento attraverso un account utente di questo 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 della guida utente: 5.2 Creazione di Utenti Database Necessari per Ottenere i Metadata del Database descrive le azioni richieste per stabilire una connessione tra DataSunrise e vari database. Dopo aver configurato l’utente del database per recuperare i metadata del database, i seguenti passaggi possono essere proceduti per connettersi con DataSunrise tramite console web.
- Accedere alla Console Web di DataSunrise.
Utilizzare l’indirizzo IP esterno ottenuto dal passaggio precedente per accedere alla Console Web di DataSunrise.
- Aggiungere Istanza di Database di Destinazione.
- Navigare in Configurazione > selezionare Istanze del Database.
- Cliccare su “Aggiungi Nuova Istanza” e compilare 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: Scegliere il metodo appropriato (ad esempio, nome utente/password del database, Active Directory).
- Tipo di Database: Selezionare il tipo del proprio database di destinazione (ad esempio, MS SQL, PostgreSQL).
- Porta: Il numero di porta su cui gira il database.
- Nome del Database: Il nome del database di destinazione.
- Testare la Connessione.
- Cliccare sul pulsante “Test” per assicurarsi che DataSunrise possa collegarsi correttamente al database di destinazione.
- Una volta che il test di connessione è riuscito, cliccare “Salva” per aggiungere l’istanza del database a DataSunrise.
- Impostare Regole di Sicurezza e Auditing.
Navigare nella sezione Regole nella Console Web di DataSunrise. Creare e configurare regole per l’audit, la sicurezza e il mascheramento dei dati secondo le proprie esigenze.

Immagine 7. Testare la Connessione in DataSunrise

Immagine 8. Stabilire la Connessione Proxy in DataSunrise
Conclusione
L’Helm Chart fornito da DataSunrise semplifica il processo di deployment, offrendo caratteristiche chiave come funzionalità proxy e autoscaling, garantendo prestazioni e affidabilità ottimali. Inoltre, seguendo le best practice 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 della flessibilità degli ambienti containerizzati.
Integrazione di AWS Secret Manager con AWS EKS
AWS Secrets Manager è uno strumento robusto che offre crittografia a riposo e rotazione dei segreti, rendendolo una scelta ideale per la gestione sicura delle informazioni sensibili. Dato che è approvato da molte squadre di sicurezza, è una soluzione affidabile per la gestione dei segreti negli ambienti cloud. Pertanto, per migliorare la sicurezza nelle deployment AWS, come con Amazon EKS, puoi sfruttare AWS Secrets Manager per garantire che le tue applicazioni rimangano sicure e conformi alle best practice.
Esistono più modi per utilizzare il servizio AWS Secrets Manager nei Pod EKS.
Utilizzo di Kubernetes Secrets Store CSI Driver
Mentre molte implementazioni personalizzate offrono flessibilità, richiedono anche significativi sforzi di sviluppo, manutenzione e operazionali. Un approccio più standardizzato ed efficiente è l’utilizzo del Kubernetes Secrets Store CSI Driver. Questo driver integra i segreti store con Kubernetes tramite un volume Container Storage Interface (CSI), permettendo ai segreti di AWS Secrets Manager di essere montati direttamente sul pod.
Il Secrets Store CSI Driver semplifica il processo di gestione dei segreti fornendo un’interfaccia nativa di Kubernetes per la gestione dei segreti. Riduce l’overhead associato a soluzioni personalizzate e garantisce un metodo coerente e sicuro per gestire i segreti all’interno del tuo ambiente Kubernetes.

Immagine 9. AWS Secrets Manager
Può controllare questi link per esplorare di più sul driver e il suo utilizzo. Le istruzioni per installare questi requisiti sono menzionate anche di seguito.
Passaggi da seguire
- Installare il CSI Secrets Store Driver. Bisogna garantire che il driver secrets-store.csi.k8s.io sia installato nel tuo cluster Kubernetes. Questo driver consente a Kubernetes di interagire con sistemi di gestione dei segreti esterni.
- Creare un segreto all’interno di AWS Secrets Manager nella stessa regione del tuo cluster usando l’AWS CLI (Command Line Interface). Può anche farlo nella Console di Gestione AWS.
- Creare una policy IAM eseguendo il comando qui sotto. Dopo aver eseguito il comando, la variabile POLICY_ARN conterrà l’ARN della policy IAM creata.
- Creare un account di servizio associato alla policy IAM che ha creato in precedenza utilizzando `eksctl`. Prima di eseguire il comando, assicurarsi di avere eksctl installato e configurato sulla sua macchina.
- Creare AWS Secret Provider Class.
- Modificare il values.yaml utilizzando i segreti che abbiamo creato nel passaggio 2. Sarà necessario specificare il parametro envVarsSecretProviderClassName con il nome del SecretProviderClass che ha creato nel passaggio 5. Dopo aver modificato tutti i campi necessari in values.yaml, può continuare con il deployment di helm.
“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”
3.1: Impostare due variabili di ambiente REGION e CLUSTERNAME. Queste variabili definiscono la regione AWS e il nome del cluster EKS.
REGION=
CLUSTERNAME=
3.2: Creare 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 (Amazon Resource Name) del segreto creato.
SECRET_ARN=$(aws –query ARN –output text secretsmanager create-secret –name
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"] } ] }')
eksctl create iamserviceaccount –name
L’opzione –approve conferma la creazione dell’account di servizio senza chiedere conferma, e –override-existing-serviceaccounts permette di sovrascrivere gli account di servizio esistenti con lo stesso nome.
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")

Immagine 10. Specificare il Parametro
Nota: Se crea un segreto k8s utilizzando il manifest yaml, dovrebbe includere il segreto in codifica base64. Vedi l’esempio 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
L’utilizzo di password forti insieme a un servizio di gestione dei segreti come AWS Secrets Manager migliora significativamente la postura di sicurezza dei tuoi deployment. Seguendo questi passi, può gestire e iniettare in sicurezza i segreti di AWS Secrets Manager nelle tue applicazioni DataSunrise distribuite tramite Helm su EKS.