Exécution de DataSunrise sur Kubernetes avec le Chart Helm

Le déploiement d’applications sur 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 sur 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 package qui peut être facilement déployé sur votre cluster Kubernetes. Cela réduit considérablement le temps et la complexité liés à la gestion des applications Kubernetes.

DataSunrise a créé un Chart Helm pour faciliter l’installation et l’opération de DataSunrise sur Kubernetes. Helm rationalise la gestion des applications Kubernetes, simplifiant et unifiant le processus de déploiement pour DataSunrise. Avec Helm, vous pouvez facilement installer et mettre à niveau DataSunrise en fonction de vos besoins dans n’importe quel environnement Kubernetes, y compris les fournisseurs de cloud comme AWS EKS, Azure AKS et les clusters Google Cloud GKE. Le chart supporte plusieurs cas d’utilisation en fonction des valeurs fournies.

Les caractéristiques clés du Chart Helm de DataSunrise 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 supporte également l’auto-scalability, utilisant une puissante découverte de données sensibles pour ajouter automatiquement de nouveaux pods au cluster lors des charges maximales. De plus, le Chart Helm peut être facilement installé via l’application Artifact Hub, simplifiant le déploiement et la gestion de DataSunrise sur Kubernetes.

Prérequis

Notre chart Helm fonctionne à la fois avec Kubernetes standard et des services Kubernetes 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 démontrer les étapes suivantes.

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

1. Créer un cluster EKS et des pods dans votre AWS.
2. Helm 3.6+
3. Kubernetes 1.21+ – C’est la version la plus ancienne de Kubernetes testée. Il est possible que ce chart fonctionne avec des versions antérieures.
4. 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 clés 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 garantir une haute disponibilité et une scalabilité, DataSunrise peut être configuré sur plusieurs serveurs. Lors du déploiement de DataSunrise en configuration multi-serveurs, une base de données PostgreSQL, MySQL/MariaDB ou MS SQL Server est utilisée pour stocker les données communes de Dictionnaire et d’Audit.

La base de données d’audit dans DataSunrise est essentielle pour stocker des logs détaillés de toutes les activités de 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 fournit un journal d’audit complet et facilite la surveillance de la sécurité en détectant les activités suspectes. DataSunrise supporte PostgreSQL, MySQL, MariaDB et MS SQL Server pour la base de données d’Audit. Il est crucial d’allouer un stockage suffisant et de gérer les politiques de rétention pour gérer la croissance potentiellement importante des données d’audit.

La base de données de Dictionnaire contient la configuration et les métadonnées nécessaires au fonctionnement de DataSunrise, telles que les 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 que DataSunrise peut fonctionner sans problème en maintenant toutes les données de configuration nécessaires. Comme la base de données d’audit, DataSunrise supporte PostgreSQL, MySQL, MariaDB et MS SQL Server pour la base de données de Dictionnaire. Cette base de données doit être hautement disponible et sécurisée avec des mots de passe forts car elle est vitale pour le fonctionnement ininterrompu de DataSunrise.

Pour plus d’informations sur les instructions pour préparer les bases de données externes à utiliser comme bases de données d’audit et de configuration, veuillez vous référer au chapitre 4 du guide d’administration : Configuration MultiServeurs (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, garantissant un fonctionnement continu et une surveillance de la sécurité cohérente dans votre environnement de base de données.

Comment préparer un cluster AWS EKS

Étape – 1 : Une fois 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 des clusters et des applications.
• Helm : Gère les applications Kubernetes via des charts, simplifiant les déploiements et les mises à niveau.
• AWS CLI : Gère les ressources AWS, utile pour automatiser les tâches AWS et intégrer les services.

#kubectl

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

#helm

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

#awscli

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

Étape – 2 : Configurez maintenant les informations d’identification dans awscli :

Exécutez cette commande : aws configure

Après l’avoir exécutée, on vous demandera d’entrer votre AWS Access Key ID, AWS Secret Access Key, le nom de la région par défaut et le format de sortie préféré.

AWS Access Key ID [None] : ************

AWS Secret access key [None] : ************

Nom de la région par défaut [None] : 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 avoir mis à jour le kubeconfig, vérifiez la mise à jour en vérifiant le statut des pods dans l’espace de noms kube-system.

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

Installation de DataSunrise en utilisant HELM

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

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



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

mon-chart/

├── Chart.yaml

├── charts/

├── templates/

├── values.yaml

3. 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 uiService de ClusterIp à LoadBalancer.
• Activez l’ingress.

Il est crucial d’utiliser des mots de passe forts dans la configuration de votre application. Un mot de passe fort doit comporter plus de 8-12 caractères et inclure 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 de l’AWS Secret Manager est également décrite dans l’article suivant.

apiVersion: secrets-store.csi.x-k8s.io/v1alpha1
kind: SecretProviderClass
metadata:
  name: aws-secrets
  namespace: default #Changer à votre espace de noms préféré
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: {}
  # Exemples :
  # - 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 reste bloqué en statut “Pending”, désactivez le volume :

localSettingsPersistentVolume:
  ## Si 'vrai', alors une demande de Volume Persistant sera créée/utilisée.
  ## Si 'faux', alors emptyDir sera utilisé.
  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 récupère le chart ingress-nginx depuis le dépôt 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 permettra de gérer l’accès externe à vos services DataSunrise à travers les ressources Ingress de Kubernetes.

Ensuite, nous devons définir l’hôte pour votre Ingress. Pour trouver le lien du load balancer, rendez-vous sur le tableau de bord de votre cluster AWS EKS. Ensuite, allez dans “Ressources” -> “Service et mise en réseau” -> “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.

ingress:
  enabled: false
  className: "nginx"
  ## Quelques 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 devrez trouver des annotations similaires pour votre classe.
  ## les annotations HTTPS backend et 'sticky session' 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 l'URL de votre loadbalancer ici
      paths:
        - path: /
          pathType: ImplementationSpecific

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

“helm install ds .”

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

“kubectl get pods”

Consultez les logs du pod si le pod ne démarre pas :

“kubectl logs ”

Étape – 4 : Après que le pod de datasunrise soit 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.

É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 vers 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 opérationnel, vous pouvez configurer les règles DataSunrise pour auditer, sécuriser ou masquer vos colonnes de base de données sensibles. Voir 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 au fonctionnement via un compte utilisateur de cette base de données (le compte, le nom d’utilisateur et le mot de passe duquel sont spécifiés dans le profil de la base de données cible dans la console web). Vous pouvez utiliser le compte administrateur de la base de données pour la connexion, mais il est également possible d’utiliser tout autre compte utilisateur doté de 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 base de données pour récupérer les métadonnées de la base de données, les étapes suivantes peuvent être poursuivies pour se connecter avec DataSunrise via la console web.

1. Connectez-vous à la console web de DataSunrise.

Utilisez l’adresse IP externe obtenue à l’étape précédente pour accéder à la console web de DataSunrise.

2. Ajoutez une instance de base de données cible.
• Accédez à la 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 fonctionne.
• Nom de la base de données : Le nom de la base de données cible.
3. Testez 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 base de données à DataSunrise.
4. Configurez des règles de sécurité et d’audit.

Accédez à la section Règles dans la console web de DataSunrise. Créez et configurez des règles pour l’audit, la sécurité et le masquage des données selon vos besoins.

Conclusion

Le Chart Helm fourni par DataSunrise avec Kubernetes simplifie le processus de déploiement, offrant des fonctionnalités clés telles que la fonctionnalité de proxy et l’auto-scalability, garantissant des performances et une fiabilité optimales. De plus, en suivant les meilleures pratiques telles que la configuration de 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é sur Kubernetes, les organisations peuvent protéger en toute confiance leurs données sensibles tout en bénéficiant de l’évolutivité et de la flexibilité des environnements containerisés.

Intégration du gestionnaire de secrets AWS 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 gérer en toute sécurité les informations sensibles. Approuvé 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 améliorer la sécurité dans les déploiements AWS, comme avec Amazon EKS, vous pouvez utiliser AWS Secrets Manager pour garantir que vos applications restent sécurisées et conformes aux meilleures pratiques.

Il existe de nombreuses façons d’utiliser le service AWS Secrets Manager dans les pods EKS.

Utilisation du driver Kubernetes Secrets Store CSI

Bien que de nombreuses implémentations personnalisées offrent une 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 Kubernetes Secrets Store CSI Driver. Ce driver intègre les magasins de secrets avec Kubernetes via une interface de stockage par conteneur (CSI) volume, permettant de monter directement les secrets de AWS Secrets Manager sur le pod.

Le Secrets Store CSI Driver simplifie le processus de gestion des secrets en fournissant une interface native 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 au sein de votre environnement Kubernetes.

Vous pouvez consulter ces liens pour explorer davantage le driver et son utilisation. Les instructions pour installer ces exigences sont également mentionnées ci-dessous.

1. Kubernetes Secrets Store CSI Driver
2. Fournisseur de secrets et configuration AWS

Étapes à suivre

1. Installez le driver CSI Secrets Store. Vous devez vous assurer que le driver CSI secrets-store.csi.k8s.io est installé dans votre cluster Kubernetes. Ce driver permet à Kubernetes d’interagir avec les systèmes de gestion de secrets externes.

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

2. Créez un secret à l’intérieur d’AWS Secrets Manager dans la même région que votre cluster en utilisant l’AWS CLI (interface en ligne de commande). Vous pouvez aussi 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 inclut 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”)

3. Créez une policy IAM en exécutant la commande ci-dessous. Après avoir exécuté la commande, la variable POLICY_ARN contiendra l’ARN de la policy 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"]
    } ]
}')

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

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

Le flag –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 du même nom.

5. Créez une classe de fournisseur de secrets 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")

6. Modifiez le fichier 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.



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

Utiliser des mots de passe forts en conjonction avec un service de gestion des secrets comme AWS Secrets Manager améliore considérablement la sécurité de vos déploiements. En suivant ces étapes, vous pouvez gérer en toute sécurité et injecter les secrets d’AWS Secrets Manager dans vos applications DataSunrise déployées via Helm sur EKS.