# Sicherheit mit einem benutzerdefinierten Schlüsselspeicher für Dynamic Engine-Umgebungsdienste Verwenden Sie einen benutzerdefinierten Schlüsselspeicher für Ihre Dynamic Engine-Umgebung, um signierte Jobartefakte der Datenintegration. Details zum Erzeugen und Verwalten von Schlüsselspeichern in Talend Studio finden Sie unter [Konfigurieren eines benutzerspezifischen Java KeyStore für die Signatur von Job-Artefakten](https://help.qlik.com/talend/en-US/studio-user-guide/8.0/configuring-custom-java-keystore-for-artifact-signature). InformationshinweisWichtig: Die Festlegung eines benutzerdefinierten Schlüsselspeichers für Dynamic Engine-Umgebungsdienste ist nur während der Engine-Bereitstellung zulässig. ## Vorbereitungen * Die benutzerdefinierten Ressourcendefinitionen dynamic-engine-crd müssen mit dem Helm-Chart oci://ghcr.io/talend/helm/dynamic-engine-crd installiert worden sein. Führen Sie andernfalls die folgenden Befehle für die Installation aus: 1. Suchen Sie die zu verwendende Diagrammversion: * Führen Sie den folgenden Helm-Befehl aus: ``` helm show chart oci://ghcr.io/talend/helm/dynamic-engine-crd --version ``` * Sehen Sie die Version direkt über Talend Management Console ein oder suchen Sie im [Dynamic Engine Änderungs-Log](https://help.qlik.com/talend/en-US/dynamic-engine-changelog/Cloud/dynamic-engine-v0-21-0-release-changelog?tr=de-DE) nach der in Ihrer Dynamic Engine-Version enthaltenen Diagrammversion. * Verwenden Sie einen API-Aufruf an [den Dynamic Engine-Versionsendpunkt](https://talend.qlik.dev/apis/dynamic-engine/2021-03/#operation_return-all-supported-dynamic-engine-versions). 2. Führen Sie den folgenden Befehl aus, um das Helm-Chart einer bestimmten Version zu installieren: ``` helm install dynamic-engine-crd oci://ghcr.io/talend/helm/dynamic-engine-crd --version ``` Ersetzen Sie <helm\_chart\_version> durch die Chart-Version, die von Ihrer Dynamic Engine-Version unterstützt wird. Wenn die Version nicht angegeben wird, installieren Sie die neueste verfügbare dynamic-engine-crd-Diagrammversion. * Ihre Dynamic Engine muss implementiert worden sein. Führen Sie andernfalls den folgenden Befehl aus, um sie zu implementieren: ``` helm install dynamic-engine -f -helm-values/-values.yaml oci://ghcr.io/talend/helm/dynamic-engine ``` Dies ist die Standardbereitstellung, da die aktuelle Anpassung nur auf der Dynamic Engine-Umgebungsseite benötigt wird. Aus diesem Grund wurde keine Anpassung für die Dynamic Engine-Instanz konfiguriert. ## Warum und wann dieser Vorgang ausgeführt wird Standardmäßig verwendet eine Dynamic Engine-Umgebung den Standard-Schlüsselspeicher für die Signaturverifizierung von Artefakten. Um Signatur-Artefakte der Datenintegration, die mit Ihrem eigenen Schlüsselspeicher signiert wurden, müssen Sie den benutzerdefinierten Schlüsselspeicher und sein Passwort bereitstellen, wenn Sie die Umgebung bereitstellen oder upgraden. Sie müssen nur das öffentliche Zertifikat der Stamm-Zertifizierungsstelle (ZS) in Ihrem benutzerdefinierten Schlüsselspeicher einschließen. Die privaten Schlüssel oder Zwischenzertifikate sind nicht notwendig. ## Prozedur 1. Entpacken Sie auf dem Kubernetes-Rechner die Helm-Implementierungs-ZIP-Datei, die Sie zuvor heruntergeladen haben. 2. Legen Sie die Umgebungsvariablen KEYSTORE\_PATH und KEYSTORE\_PASS für den Speicherort Ihrer Schlüsselspeicherdatei und ihr Zugriffspasswort fest. ### Example Beispielsweise für ein Linux-System: ``` export KEYSTORE_PATH= export KEYSTORE_PASS= ``` Ersetzen Sie <location-to-your-keystore-file> und <your\_keystore\_password> durch tatsächliche Werte. 3. Erstellen Sie eine benutzerdefinierte Werte-Datei für Ihre Dynamic Engine-Umgebung mit dem base64-codierten Schlüsselspeicher und seinem Passwort. ``` 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 ``` Ersetzen Sie $DYNAMIC\_ENGINE\_ENVIRONMENT\_ID durch Ihre Umgebungs-ID. 4. Stellen Sie die Dynamic Engine-Umgebung mit der Konfiguration Ihres benutzerdefinierten Schlüsselspeichers bereit. ``` 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 ``` InformationshinweisTipp: Falls Änderungen erforderlich sind, können Sie die Inhalte der Datei $DYNAMIC\_ENGINE\_ENVIRONMENT\_ID-custom-keystore-values.yaml aktualisieren und helm upgrade ausführen, um die Änderungen anzuwenden: ``` 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 ``` ## Ergebnisse Nach erfolgreicher Durchführung sind die Dynamic Engine-Umgebungsdienste mit dem benutzerdefinierten Schlüsselspeicher in Ihrem Cluster installiert und stellen eine Verbindung zur Dynamic Engine her. In Talend Management Console ändert sich der Status dieser Umgebung zu Ready (Bereit), was bestätigt, dass sie zum Ausführen von Tasks oder Plänen bereit ist. Wenn eine Datenintegrationsaufgabe ausgeführt wird, wird die Artefaktsignatur zunächst mit dem benutzerdefinierten Schlüsselspeicher und dann mit dem Standardspeicher verglichen. Wenn keiner der beiden die Signatur authentifizieren kann, beginnt die Ausführung nicht, und die Aufgabe wird in Talend Management Console als fehlgeschlagen angezeigt. Falls die Aufgabenausführung aufgrund von Signaturproblemen fehlschlägt, erstellen Sie eine einfache Pod-Vorlage, um den benutzerdefinierten Schlüsselspeicher in der Umgebung zu verifizieren: 1. Erstellen Sie die Wertedatei für diesen Testpod. In diesem Beispiel wird die Datei check-custom-keystore.yaml genannt. ``` 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. Wenden Sie die Testpodvorlage an: ``` kubectl apply -n qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID -f check-custom-keystore.yaml ``` 3. Listen Sie die Schlüsselspeicherinhalte mit keytool auf: ``` 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) ``` Dieser Befehl bestätigt den benutzerdefinierten Schlüsselspeicher in der Umgebung gemountet und lesbar ist. 4. Löschen Sie den Testpod nach Beendigung: ``` kubectl delete -n qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID -f check-custom-keystore.yaml ```