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.

Wichtig: Die Festlegung eines benutzerdefinierten Schlüsselspeichers für Dynamic Engine-Umgebungsdienste ist nur während der Engine-Bereitstellung zulässig.

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

Verwenden Sie das Helm-Diagramm dynamic-engine-crd, um die benutzerdefinierten Dynamic Engine-Ressourcendefinitionen einer bestimmten Helm-Version zu installieren.
1. Die zu verwendende Diagrammversion entspricht Ihrer Dynamic Engine-Version. Sie finden diese Version anhand einer der folgenden Methoden:
  - Führen Sie den folgenden Helm-Befehl aus:
    helm show chart oci://ghcr.io/talend/helm/dynamic-engine --version <engine_version>
  - Sehen Sie die Version direkt über Talend Management Console ein oder suchen Sie im Dynamic Engine Änderungs-Log nach der in Ihrer Dynamic Engine-Version enthaltenen Diagrammversion.
  - Verwenden Sie einen API-Aufruf an den Dynamic Engine-Versionsendpunkt.
2. Führen Sie im Kubernetes-Cluster den folgenden Befehl aus, um das Helm-Diagramm einer bestimmten Version zu installieren:
```
helm install dynamic-engine-crd oci://ghcr.io/talend/helm/dynamic-engine-crd --version <helm_chart_version>
```
  Ersetzen Sie <helm_chart_version> durch die Diagrammversion, 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.
Entpacken Sie nach wie vor auf dem Kubernetes-Rechner die Helm-Bereitstellungs-ZIP-Datei, die Sie zuvor heruntergeladen haben.
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=<location-to-your-keystore-file>
export KEYSTORE_PASS=<your_keystore_password>
```
Ersetzen Sie <location-to-your-keystore-file> und <your_keystore_password> durch tatsächliche Werte.

Erstellen Sie eine benutzerdefinierte Werte-Datei für Ihre Dynamic Engine-Umgebung mit dem base64-codierten Schlüsselspeicher und seinem Passwort.

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

Ersetzen Sie <environment-id> durch die ID für Ihre Umgebung.

Führen Sie den folgenden Befehl aus, um die Dynamic Engine-Instanz bereitzustellen:
```
helm install dynamic-engine -f <engine-id>-helm-values/<engine-id>-values.yaml oci://ghcr.io/talend/helm/dynamic-engine
```
Dies ist die Standardbereitstellung, da die Anpassung des Schlüsselspeichers nur auf der Dynamic Engine-Umgebungsseite benötigt wird. Es wurde also keine Anpassung für die Dynamic Engine-Instanz vorgenommen.

Stellen Sie die Dynamic Engine-Umgebung mit der Konfiguration Ihres benutzerdefinierten Schlüsselspeichers bereit.

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>

Tipp: Falls Änderungen erforderlich sind, können Sie die Inhalte der Datei <environment-id>-custom-keystore-values.yaml aktualisieren und helm upgrade ausführen, um die Änderungen anzuwenden:

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>

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:

Erstellen Sie die Wertedatei für diesen Testpod. In diesem Beispiel wird die Datei check-custom-keystore.yaml genannt.

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

Wenden Sie die Testpodvorlage an:

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

Listen Sie die Schlüsselspeicherinhalte mit keytool auf:

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)

Dieser Befehl bestätigt den benutzerdefinierten Schlüsselspeicher in der Umgebung gemountet und lesbar ist.

Löschen Sie den Testpod nach Beendigung:

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

Hat diese Seite Ihnen geholfen?

Wenn Sie ein Problem mit dieser Seite oder ihrem Inhalt feststellen, sei es ein Tippfehler, ein ausgelassener Schritt oder ein technischer Fehler, informieren Sie uns bitte!

Geben Sie hier Ihr Feedback ab