# 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](https://help.qlik.com/talend/fr-FR/studio-user-guide/8.0/configuring-custom-java-keystore-for-artifact-signature). Note InformationsImportant : 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. ## Avant de commencer * Les définitions des ressources personnalisées dynamic-engine-crd doivent avoir été installées à l'aide du chart Helm oci://ghcr.io/talend/helm/dynamic-engine-crd. Si ce n'est pas le cas, exécutez les commandes suivantes pour l'installation : 1. Trouvez la version du chart à utiliser : * Exécutez la commande Helm suivante : ``` helm show chart oci://ghcr.io/talend/helm/dynamic-engine-crd --version ``` * Visualisez la version directement depuis Talend Management Console ou consultez le [Dynamic Engine journal de modification](https://help.qlik.com/talend/fr-FR/dynamic-engine-changelog/Cloud) de la version du chart dans votre version de Dynamic Engine. * Utilisez un appel d'API pour [l'endpoint de version de Dynamic Engine](https://talend.qlik.dev/apis/dynamic-engine/2021-03/#operation_return-all-supported-dynamic-engine-versions) (en anglais). 2. 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 ``` 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. * Votre Dynamic Engine doit avoir été déployé. Si ce n'est pas le cas, exécutez cette commande pour le déployer : ``` helm install dynamic-engine -f -helm-values/-values.yaml oci://ghcr.io/talend/helm/dynamic-engine ``` Ce déploiement est celui par défaut, car la personnalisation courante est nécessaire uniquement côté environnement du Dynamic Engine. Ainsi, aucune personnalisation n'a été configurée pour l'instance du Dynamic Engine. ## 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 1. Sur la machine de Kubernetes, décompressez le fichier ZIP de déploiement Helm précédemment téléchargé. 2. 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= export KEYSTORE_PASS= ``` Remplacez <location-to-your-keystore-file> et <your\_keystore\_password> par les valeurs réelles. 3. 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 < $DYNAMIC_ENGINE_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 $DYNAMIC\_ENGINE\_ENVIRONMENT\_ID par l'ID de son environnement. 4. Déployez l'environnement du Dynamic Engine avec votre configuration personnalisée du KeyStore. ``` helm install dynamic-engine-environment-$DYNAMIC_ENGINE_ENVIRONMENT_ID -f $DYNAMIC_ENGINE_ENVIRONMENT_ID-values.yaml \ -f $DYNAMIC_ENGINE_ENVIRONMENT_ID-custom-keystore-values.yaml \ oci://ghcr.io/talend/helm/dynamic-engine-environment \ --version $DYNAMIC_ENGINE_VERSION ``` Note InformationsConseil : Lorsque des modifications sont nécessaires, mettez à jour le contenu du fichier $DYNAMIC\_ENGINE\_ENVIRONMENT\_ID-custom-keystore-values.yaml et exécutez helm upgrade pour appliquer les modifications : ``` helm upgrade dynamic-engine-environment-$DYNAMIC_ENGINE_ENVIRONMENT_ID -f $DYNAMIC_ENGINE_ENVIRONMENT_ID-values.yaml \ -f $DYNAMIC_ENGINE_ENVIRONMENT_ID-custom-keystore-values.yaml \ oci://ghcr.io/talend/helm/dynamic-engine-environment \ --version $DYNAMIC_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 : 1. Créez le fichier de valeurs pour ce pod de test. Dans cet exemple, le fichier est nommé check-custom-keystore.yaml. ``` cat < 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 ``` 2. Appliquez le modèle du pod de test : ``` kubectl apply -n qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID -f check-custom-keystore.yaml ``` 3. Lister le contenu des KeyStore avec keytool : ``` kubectl exec -it check-custom-keystore -n qlik-processing-env-$DYNAMIC_ENGINE_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. 4. Supprimez le pod de test lorsque vous avez terminé : ``` kubectl delete -n qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID -f check-custom-keystore.yaml ```