Sécurité avec un KeyStore personnalisé pour les services d'environnement du Dynamic Engine

Utilisez un KeyStore personnalisé pour que votre environnement du Dynamic Engine vérifie les artefacts de Jobs d'intégration de données signés.

Pour savoir comment générer et gérer les KeyStores dans le Studio Talend, consultez Configurer un KeyStore Java personnalisé pour les signatures d'artefacts de Jobs.

Important : Configurer un KeyStore personnalisé pour les services d'environnement du Dynamic Engine n'est possible que lors du déploiement ou la mise à niveau du moteur.

Pourquoi et quand exécuter cette tâche

Par défaut, un environnement de Dynamic Engine utilise le KeyStore par défaut pour la vérification des signatures d'artefacts. Pour vérifier les artefacts de Jobs d'intégration de données signés par votre propre KeyStore, vous devez fournir le KeyStore personnalisé et son mot de passe lorsque vous déployez ou mettez à niveau l'environnement.

Vous n'avez besoin d'inclure que le certificat public de l'autorité de certification racine dans votre KeyStore personnalisé. Les clés privées et les certificats intermédiaires ne sont pas nécessaires.

Procédure

Utilisez le chart Helm dynamic-engine-crd pour installer les définitions de ressources personnalisées de Dynamic Engine d'une version de Helm donnée.
1. La version du graphique à utiliser est la même que celle de votre Dynamic Engine. Vous pouvez trouver cette version via les méthodes suivantes :
  - Exécutez la commande Helm suivante :
    helm show chart oci://ghcr.io/talend/helm/dynamic-engine --version <engine_version>
  - Visualisez la version directement depuis Talend Management Console ou consultez le Dynamic Engine journal de modification de la version du graphique dans votre version de Dynamic Engine.
  - Utilisez un appel d'API pour l'endpoint de version de Dynamic Engine (en anglais).
2. Dans le cluster Kubernetes, exécutez la commande suivante pour installer le chart Helm dans une version donnée :
```
helm install dynamic-engine-crd oci://ghcr.io/talend/helm/dynamic-engine-crd --version <helm_chart_version>
```
  Remplacez <helm_chart_version> par la version du chart supportée par votre version du Dynamic Engine.
  Si vous ne spécifiez pas la version, vous installez la dernière version disponible du chart dynamic-engine-crd.
Sur la machine de Kubernetes, décompressez le fichier ZIP de déploiement Helm précédemment téléchargé.
Configurez les variables d'environnement KEYSTORE_PATH et KEYSTORE_PASS pour l'emplacement de votre fichier KeyStore et son mot de passe d'accès.
Exemple
Par exemple, dans un système Linux :
```
export KEYSTORE_PATH=<location-to-your-keystore-file>
export KEYSTORE_PASS=<your_keystore_password>
```
Remplacez <location-to-your-keystore-file> et <your_keystore_password> par les valeurs réelles.

Créez un fichier de valeurs personnalisées pour votre environnement de Dynamic Engine avec le KeyStore encodé en Base64 et son mot de passe.

cat <<EOF > <environment-id>-custom-keystore-values.yaml
configuration:
  signature:
    keystore:
      # base64 string of the keystore to load, null by default (rely on the default signature bundle)
      data: |
        $(base64 -i $KEYSTORE_PATH)
      password: ${KEYSTORE_PASS}
EOF

Remplacez <environment-id> par l'ID de votre environnement.

Exécutez cette commande pour déployer l'instance du Dynamic Engine :
```
helm install dynamic-engine -f <engine-id>-helm-values/<engine-id>-values.yaml oci://ghcr.io/talend/helm/dynamic-engine
```
Ce déploiement est celui par défaut, car la personnalisation du KeyStore est nécessaire uniquement côté environnement du Dynamic Engine. Aucune personnalisation n'a été effectuée pour l'instance du Dynamic Engine.

Déployez l'environnement du Dynamic Engine avec votre configuration personnalisée du KeyStore.

helm install dyn-engine-env-<environment-id> -f <environment-id>-values.yaml  \
 -f <environment-id>-custom-keystore-values.yaml \
 oci://ghcr.io/talend/helm/dynamic-engine-environment \
 --version <engine-version>

Conseil : Lorsque des modifications sont nécessaires, mettez à jour le contenu du fichier <environment-id>-custom-keystore-values.yaml et exécutez helm upgrade pour appliquer les modifications :

helm upgrade dyn-engine-env-<environment-id> -f <environment-id>-values.yaml  \
 -f <environment-id>-custom-keystore-values.yaml \
 oci://ghcr.io/talend/helm/dynamic-engine-environment \
 --version <engine-version>

Résultats

Cela fait, les services d'environnement de Dynamic Engine sont installés dans votre cluster avec le KeyStore personnalisé et connectés au Dynamic Engine.

Dans Talend Management Console, le statut de cet environnement devient Ready (Prêt), confirmant qu'il est prêt à exécuter des tâches ou des plans.

Lorsqu'une tâche d'intégration de données s'exécute, la signature d'artefacts est d'abord vérifiée par rapport au KeyStore personnalisé, puis par rapport à celui par défaut. Si aucun ne peut authentifier la signature, l'exécution ne démarre pas et la tâche s'affiche en échec dans Talend Management Console.

Si l'exécution de la tâche échoue à cause de problèmes de signatures, créez un modèle de pod simple pour vérifier le KeyStore personnalisé dans l'environnement :

Créez le fichier de valeurs pour ce pod de test. Dans cet exemple, le fichier est nommé check-custom-keystore.yaml.

cat <<EOF > check-custom-keystore.yaml
apiVersion: v1
kind: Pod
metadata:
  labels:
    app.kubernetes.io/managed-by: kubectl
  name: check-custom-keystore
  
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 61000
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: runner
    image: ghcr.io/talend/jre21-base-minimal:4.0.32
    command:
      - cat
    tty: true
    securityContext:
      allowPrivilegeEscalation: false
      capabilities:
        drop:
          - ALL
    resources:
      requests:
        cpu: '0.3'
        memory: 256Mi
      limits:
        cpu: '0.5'
        memory: 256Mi
    volumeMounts:
    - mountPath: /tmp/signature/keystores/default
      name: signature-check-secret-volume
      readOnly: true
    - mountPath: /tmp/signature/keystores/custom
      name: custom-signature-check-secret-volume
      readOnly: true
  volumes:
    - name: signature-check-secret-volume
      secret:
        defaultMode: 420
        secretName: signature-check-secret
    - name: custom-signature-check-secret-volume
      secret:
        defaultMode: 420
        secretName: custom-signature-check-secret
EOF

Appliquez le modèle du pod de test :

kubectl apply -n qlik-processing-env-<environment-id> -f check-custom-keystore.yaml

Lister le contenu des KeyStore avec keytool :

kubectl exec -it check-custom-keystore -n qlik-processing-env-<environment-id> \
-- /usr/lib/jvm/jdk-21.0.5+11-jre/bin/keytool -list -v -keystore /tmp/signature/keystores/custom/custom-code-verify.jks \
-storepass \$(cat /tmp/signature/keystores/custom/custom-code-verify-jks-password)

Cette commande confirme que le KeyStore personnalisé est monté et lisible dans l'environnement.

Supprimez le pod de test lorsque vous avez terminé :

 kubectl delete -n qlik-processing-env-<environment-id> -f check-custom-keystore.yaml

Cette page vous a-t-elle aidé ?

Si vous rencontrez des problèmes sur cette page ou dans son contenu – une faute de frappe, une étape manquante ou une erreur technique – faites-le-nous savoir.

Laissez vos commentaires ici