Accueil
Actualités Professionnelles
Exécution de DataSunrise sur Kubernetes en utilisant le Tableau de Helm

Exécution de DataSunrise sur Kubernetes en utilisant le Tableau de Helm

Le déploiement d’applications dans Kubernetes peut être complexe, nécessitant une connaissance détaillée de ses divers composants et de leurs fonctions. Helm simplifie ce processus, rendant le déploiement de Kubernetes simple et gérable. Au lieu de créer et de maintenir manuellement plusieurs manifests YAML pour chaque objet Kubernetes, Helm consolide tout en un seul paquet qui peut être facilement déployé sur votre cluster Kubernetes. Cela réduit considérablement le temps et la complexité impliqués dans la gestion des applications Kubernetes.

DataSunrise a créé un tableau Helm pour faciliter l’installation et l’exploitation de DataSunrise sur Kubernetes. Helm simplifie la gestion des applications Kubernetes, simplifiant et unifiant le processus de déploiement pour DataSunrise. Avec Helm, vous pouvez facilement installer et mettre à jour DataSunrise au besoin dans n’importe lequel de vos environnements Kubernetes, y compris les fournisseurs de cloud AWS EKS, Azure AKS, et les clusters Google Cloud GKE. Le tableau prend en charge plusieurs cas d’utilisation en fonction des valeurs fournies.

Les principales caractéristiques du tableau DataSunrise Helm incluent la fonctionnalité de proxy, où un proxy est utilisé sur chaque nœud et Kubernetes gère l’équilibrage de charge entre eux. Il prend également en charge l’auto-dimensionnement, en utilisant la puissante Découverte de données sensibles pour ajouter automatiquement de nouveaux pods au cluster pendant les charges de pointe. De plus, le tableau Helm peut être facilement installé via l’application Artifact Hub, simplifiant le déploiement et la gestion de DataSunrise sur Kubernetes.

Pré-requis

Notre tableau helm fonctionne à la fois avec les services Kubernetes vanille et gérés tels que l’EKS d’AWS, l’AKS d’Azure et le GKE de Google Cloud. Pour cet article, utilisons l’EKS d’AWS pour illustrer les étapes suivantes.

Nous devrons avoir les composants suivants dans notre environnement. Vous pouvez également trouver les commandes utilisées pour installer les composants nécessaires dans la section suivante.

Créer le cluster EKS et les pods dans votre AWS.
Helm 3.6+
Kubernetes 1.21+ – C’est la version la plus ancienne de Kubernetes testée. Il est possible que ce tableau fonctionne avec des versions antérieures.
Des bases de données externes pour les charges de travail de production et le mode HA

Pourquoi avons-nous besoin de bases de données externes en mode HA?

DataSunrise utilise deux types principaux de bases de données pour stocker ses données opérationnelles: la base de données d’audit et la base de données de dictionnaire. Pour assurer une haute disponibilité et une scalabilité, DataSunrise peut être configuré sur plusieurs serveurs. Lors du déploiement de DataSunrise dans une configuration multi-serveur, une base de données PostgreSQL, MySQL/MariaDB ou MS SQL Server est utilisée pour stocker les données communes du dictionnaire et de l’audit.

La base de données d’audit de DataSunrise est essentielle pour stocker des journaux détaillés de toutes les activités de la base de données surveillées, y compris les requêtes SQL, les actions des utilisateurs et les événements de sécurité. Cette base de données offre une piste d’audit complète et facilite la surveillance de la sécurité en détectant les activités suspectes. DataSunrise prend en charge PostgreSQL, MySQL, MariaDB et MS SQL Server pour la base de données d’audit. Il est essentiel d’allouer un stockage suffisant et de gérer les politiques de rétention pour faire face à la croissance potentiellement importante des données d’audit.

La base de données de dictionnaire contient les configurations et métadonnées nécessaires pour faire fonctionner DataSunrise, telles que des informations sur les instances de base de données, les règles de sécurité, les règles d’audit et les rôles des utilisateurs. Elle assure le bon fonctionnement de DataSunrise en conservant toutes les données de configuration requises. Comme la base de données d’audit, DataSunrise supporte PostgreSQL, MySQL, MariaDB et MS SQL Server pour la base de données du dictionnaire. Cette base de données doit être hautement disponible et sécurisée par des mots de passe forts car elle est essentielle pour le fonctionnement ininterrompu de DataSunrise.

Pour plus d’informations sur les instructions de préparation des bases de données externes à utiliser en tant que bases de données d’audit et de configuration, veuillez vous référer au chapitre 4 du guide d’administration: Configuration multi-serveur(mode haute disponibilité). En utilisant des bases de données externes pour les bases de données d’audit et de dictionnaire, DataSunrise peut fournir une haute disponibilité robuste, assurant un fonctionnement continu et une surveillance de la sécurité cohérente dans votre environnement de base de données.

Illustration 1. Structure de déploiement de DataSunrise sur K8S avec le tableau Helm

Comment préparer le cluster AWS EKS

Étape – 1 : Après que le cluster EKS et le nœud où vous souhaitez installer DataSunrise sont prêts à être utilisés, installez :

kubectl: Interagit directement avec les clusters Kubernetes, essentiel pour la gestion du cluster et des applications.
Helm: Gère les applications Kubernetes via des tableaux, simplifiant les déploiements et les mises à jour.
AWS CLI: Gère les ressources AWS, utile pour automatiser les tâches AWS et intégrer les services.

#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

Étape – 2 : Nous pouvons maintenant configurer les identifiants dans awscli :

Exécutez cette commande: aws configure

Après l’avoir exécutée, il vous sera demandé de saisir votre identifiant de clé d’accès AWS, votre clé d’accès secrète AWS, le nom de la région par défaut et le format de sortie préféré.

ID de clé d’accès AWS [Auncun] : ************

Clé d’accès secrète AWS [Auncun] : ************

Nom de la région par défaut [Auncun] : us-east-2

Étape – 3 : Ensuite, configurez votre kubectl pour interagir avec le cluster EKS spécifié dans la région donnée. Après la mise à jour du kubeconfig, vérifiez la mise à jour en vérifiant l’état des pods dans l’espace de noms kube-system.

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

Installation de DataSunrise en utilisant HELM

Étape – 1 : Téléchargez manuellement le fichier values.yaml du tableau HELM à partir de https://artifacthub.io/packages/helm/datasunrise/datasunrise ou installez le tableau HELM en utilisant la commande :

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

Illustration 2. Installation du paquet Helm Datasunrise

La structure du répertoire doit être la suivante :

my-chart/

├── Chart.yaml

├── charts/

├── templates/

├── values.yaml

Ouvrez et modifiez le fichier values.yaml. Modifiez les valeurs suivantes :

enVars – pour configurer les propriétés de votre base de données de dictionnaire et d’audit.
Changez le type de service ui de ClusterIp à LoadBalancer.
Activez l’ingress.

Il est crucial d’utiliser des mots de passe forts dans votre configuration d’application. Un mot de passe fort doit comporter plus de 8-12 caractères et comprendre une combinaison de lettres majuscules et minuscules, de chiffres et de caractères spéciaux. Par exemple, P@ssw0rd#2024!. La démonstration de l’utilisation du gestionnaire de secrets AWS est également décrite dans le prochain sous-article.

apiVersion: secrets-store.csi.x-k8s.io/v1alpha1
kind: SecretProviderClass
metadata:
  name: aws-secrets
  namespace: default #Change to your preferred namespace
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: {}
  # Examples:
  # - 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: “”

Note: Si votre pod se bloque en état “En attente”, désactivez le volume:

localSettingsPersistentVolume:
  ## If 'true', then Persistent Volume Claim will be created/used.
  ## If 'false', then emptyDir will be used.
  enabled: false

Étape – 2: Pour se connecter à l’interface Web de Datasunrise, nous devons configurer l’ingress :

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

Cette commande télécharge le tableau ingress-nginx à partir du référentiel spécifié et l’installe dans l’espace de noms ingress-nginx, créant l’espace de noms s’il n’existe pas déjà. Cette configuration vous permet de gérer l’accès externe à vos services DataSunrise via des ressources Ingress Kubernetes.

Ensuite, nous devons définir l’hôte pour votre Ingress. Pour trouver le lien de l’équilibrage de charge, allez sur votre tableau de bord du cluster AWS EKS. Ensuite, allez à “Ressources” -> “Service and networking” -> “Service” -> “ingress-nginx-controller”, et copiez l’URL du LoadBalancer. Une fois que vous avez l’URL, utilisez-la pour définir le champ hôte (“-host”) dans votre configuration Ingress.

Photo 3. Comment trouver le lien de l’équilibrage de charge dans AWS EKS (1)

Photo 4. Comment trouver le lien de l’équilibrage de charge dans AWS EKS (2)

ingress:
  enabled: false
  className: "nginx"
  ## Certaines annotations supplémentaires sont nécessaires pour l'ingress.
  ## Si vous utilisez nginx, les annotations nécessaires sont déjà présentes ci-dessous.
  ## Si vous utilisez un autre ingress, vous devez trouver des annotations similaires pour votre classe.
  ## les annotations 'backend HTTPS' et 'session collante' sont nécessaires
  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: #insérez votre URL de loadbalancer ici
      paths:
        - path: /
          pathType: ImplementationSpecific

Étape – 3: Après la configuration de l’hôte, vous pouvez installer DataSunrise en utilisant Helm. Assurez-vous que vous êtes dans le répertoire contenant le script Helm chart. Ensuite, exécutez la commande suivante:

“helm install ds .”

Pour suivre l’état de l’installation, utilisez la commande suivante:

“kubectl get pods”

Vérifiez les journaux du pod si le pod ne démarre pas:

“kubectl logs ”

Étape – 4: Une fois que le pod datasunrise est en cours d’exécution, vous devriez pouvoir vous connecter à l’interface Web de Datasunrise avec le lien LoadBalancer précédent. Ou, vous pouvez vérifier en utilisant cette commande: kubectl get services.

Photo 5. Exemples de résultats de ‘kubectl get services’

Photo 6. Connexion à la console Web DataSunrise

Étape – 5: Si vous souhaitez mettre à jour DataSunrise vers une version plus récente, vous devez modifier la version spécifiée dans le fichier values.yaml à la version souhaitée. Une fois que vous avez apporté les modifications nécessaires, exécutez la commande suivante pour mettre à niveau DataSunrise: “helm upgrade ds .”

Configurer la connexion à la base de données cible

Lorsque votre cluster DataSunrise construit avec Kubernetes et Docker est en marche, vous pouvez configurer les règles DataSunrise pour auditer, sécuriser ou masquer vos colonnes de base de données sensibles. Consultez la section “Cas d’utilisation de DataSunrise” du guide de l’utilisateur de DataSunrise.

DataSunrise interagit avec une base de données cible et reçoit toutes les informations nécessaires pour son fonctionnement via un compte d’utilisateur de cette base de données (le compte, le nom d’utilisateur et le mot de passe sont spécifiés dans le profil de la base de données cible dans la console Web). Vous pouvez utiliser le compte de l’administrateur de la base de données pour la connexion, mais il est également possible d’utiliser tout autre compte d’utilisateur avec des privilèges suffisants. La section du guide de l’utilisateur: 5.2 Création d’utilisateurs de base de données requis pour obtenir les métadonnées de la base de données décrit les actions nécessaires pour établir une connexion entre DataSunrise et diverses bases de données. Après avoir configuré l’utilisateur de la base de données pour récupérer les métadonnées de la base de données, les étapes suivantes peuvent être suivies pour se connecter à DataSunrise via la console web.

Connectez-vous à la console Web de DataSunrise.
Utilisez l’adresse IP externe obtenue à l’étape précédente pour accéder à la console Web DataSunrise.
Ajoutez l’instance de la base de données cible.

Naviguez vers Configuration > sélectionnez Instances de base de données.
Cliquez sur “Ajouter une nouvelle instance” et remplissez les détails requis:

Nom logique : Un nom de référence pour la base de données.
Nom d’hôte ou IP : L’adresse de la base de données cible.
Méthode d’authentification : Choisissez la méthode appropriée (par exemple, nom d’utilisateur/mot de passe de la base de données, Active Directory).
Type de base de données : Sélectionnez le type de votre base de données cible (par exemple, MS SQL, PostgreSQL).
Port : Le numéro de port sur lequel la base de données est exécutée.
Nom de la base de données : Le nom de la base de données cible.

Tester la connexion.

Cliquez sur le bouton “Test” pour vous assurer que DataSunrise peut se connecter avec succès à la base de données cible.
Une fois le test de connexion réussi, cliquez sur “Enregistrer” pour ajouter l’instance de la base de données à DataSunrise.

Mettre en place des règles de sécurité et d’audit.

Naviguez vers la section Règles dans la console Web DataSunrise. Créez et configurez des règles pour l’audit, la sécurité et le masquage des données selon vos besoins.

Photo 7. Test de connexion dans DataSunrise

Photo 8. Établissement de la connexion Proxy dans DataSunrise[/caption>

Conclusion

Le tableau Helm fourni par DataSunrise simplifie le processus de déploiement, offrant des caractéristiques clés telles que la fonctionnalité de proxy et l’autodimensionnement, assurant des performances optimales et une fiabilité. De plus, en respectant les meilleures pratiques telles que la configuration des bases de données externes et l’utilisation de mots de passe forts, les organisations peuvent améliorer la posture de sécurité de leurs déploiements. Avec DataSunrise déployé dans Kubernetes, les organisations peuvent protéger en toute confiance leurs données sensibles tout en bénéficiant de la scalabilité et de la flexibilité des environnements conteneurisés.

Intégration d’AWS Secret Manager avec AWS EKS

AWS Secrets Manager est un outil robuste qui offre le chiffrement au repos et la rotation des secrets, ce qui en fait un choix idéal pour la gestion sécurisée des informations sensibles. Étant donné son approbation par de nombreuses équipes de sécurité, c’est une solution de confiance pour la gestion des secrets dans les environnements cloud. Par conséquent, pour renforcer la sécurité dans les déploiements AWS, comme avec Amazon EKS, vous pouvez utiliser AWS Secrets Manager pour vous assurer que vos applications restent sécurisées et conformes aux meilleures pratiques.

Il y a plusieurs façons d’utiliser le service AWS Secrets Manager dans les Pods EKS.

Utilisation du pilote CSI du magasin de secrets Kubernetes

Alors que plusieurs implémentations personnalisées offrent de la flexibilité, elles nécessitent également des efforts significatifs de développement, de maintenance et d’exploitation. Une approche plus standardisée et efficace consiste à utiliser le pilote CSI du magasin de secrets Kubernetes. Ce pilote intègre les magasins de secrets avec Kubernetes via une interface de stockage conteneur (CSI), permettant d’introduire directement des secrets provenant d’AWS Secrets Manager sur le pod.

Le pilote CSI du magasin de secrets simplifie le processus de gestion des secrets en fournissant une interface native de Kubernetes pour la gestion des secrets. Il réduit la surcharge associée aux solutions personnalisées et assure une méthode cohérente et sécurisée pour la gestion des secrets dans votre environnement Kubernetes.

[caption id="attachment_20577" align="alignnone" width="924"]

Photo 9. Gestionnaire de secrets AWS

Vous pouvez consulter ces liens pour en savoir plus sur le pilote et son utilisation. Les instructions pour installer ces exigences sont mentionnées ci-dessous aussi.

Étapes à suivre

Installez le pilote CSI du magasin de secrets. Vous devez vous assurer que le pilote secrets-store.csi.k8s.io CSI est installé dans votre cluster Kubernetes. Ce pilote permet à Kubernetes d’interagir avec des systèmes externes de gestion des secrets.

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

Créez un secret dans AWS Secrets Manager dans la même région que votre cluster en utilisant l’interface de ligne de commande AWS (CLI). Vous pouvez également le faire dans la console de gestion AWS.

3.1: Définissez deux variables d’environnement REGION et CLUSTERNAME. Ces variables définissent la région AWS et le nom du cluster EKS.

REGION=

CLUSTERNAME=

3.2: Créez le secret dans AWS Secrets Manager. Il comprend des objets JSON de vos identifiants ou secrets. Après avoir exécuté cette commande, la variable SECRET_ARN contiendra l’ARN (Amazon Resource Name) du secret créé.

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

Créez une politique IAM en exécutant la commande ci-dessous. Après avoir exécuté la commande, la variable POLICY_ARN contiendra l’ARN de la politique IAM créée.

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"]
    } ]
}')

Créez un compte de service associé à la politique IAM que vous avez créée précédemment en utilisant `eksctl`. Avant d’exécuter la commande, assurez-vous que vous avez eksctl installé et configuré sur votre machine.

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

Le drapeau –approve confirme la création du compte de service sans demander de confirmation, et –override-existing-serviceaccounts permet à la commande d’écraser les comptes de service existants ayant le même nom.

Créer la classe de fournisseur de secret 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")

Modifiez le values.yaml en utilisant les secrets que nous avons créés à l’étape-2. Vous devrez spécifier le paramètre envVarsSecretProviderClassName avec le nom de la SecretProviderClass que vous avez créée à l’étape-5. Après avoir modifié tous les champs nécessaires dans values.yaml, vous pouvez continuer avec le déploiement de helm.

Photo 10. Spécifiez le paramètre

Note: Si vous créez un secret k8s en utilisant le manifeste yaml, vous devez inclure le secret en encodage base64. Voir l’exemple ci-dessous:

votre_fichier_secret.yaml:

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


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

Conclusion

L’utilisation de mots de passe forts en conjonction avec un service de gestion des secrets comme AWS Secrets Manager renforce considérablement la posture de sécurité de vos déploiements. En suivant ces étapes, vous pouvez gérer et injecter de manière sécurisée des secrets provenant de AWS Secrets Manager dans vos applications DataSunrise déployées via Helm sur EKS.