Injizieren von Umgebungsvariablen über Kubernetes Secret

Injizieren Sie sensible Daten (Passwörter, API-Schlüssel, Token) aus Kubernetes Secret als Umgebungsvariablen in Ihren Job-Tasks (Datenintegration, Big Data und Datenservices) und Routen-Tasks, damit sie leicht und sicher auf Anmeldedaten zugreifen können.

Wichtig: Ihre sensiblen Daten werden im Kubernetes Secret gespeichert und von der Sicherheitsrichtlinie Ihrer Organisation verwaltet. Das Dynamic Engine-Anpassungsmuster stellt nur den Zugriff auf diese Informationen für die Tasks bereit, die in Ihren Dynamic Engine-Umgebungen implementiert sind. Qlik verwaltet Ihre sensiblen Daten nicht.

Vorbereitungen

Weitere Informationen finden Sie unter „Voraussetzungen und wichtige Überlegungen“.

Prozedur

Erstellen Sie eine Kubernetes Secret-Ressourcendatei mit sensiblen Daten.
Erstellen Sie eine Datei mit dem Namen external-secret-as-env.yaml, die Ihre sensiblen Daten enthält:
```
cat <<EOF > external-secret-as-env.yaml
apiVersion: v1
kind: Secret
metadata:
  name: external-secret-as-env
  namespace: qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID
type: Opaque
stringData:
  DATABASE_PASSWORD: "mySecurePassword123"
  API_KEY: "your_key"
  AUTH_TOKEN: "Bearer your_token"
EOF
```
Ersetzen Sie die Beispiel-Anmeldedaten durch Ihre tatsächlichen sensiblen Daten.

Dynamic Engine verwaltet Ihre sensiblen Daten nicht. Weitere Informationen dazu, wie Daten in einem Kubernetes Secret codiert werden, finden Sie unter Secret in der Kubernetes-Dokumentation.
Erstellen Sie eine Helm-Wertedatei, die das Secret referenziert.

Erstellen Sie eine Datei, z. B. mit dem Namen secret-values.yaml. Wählen Sie den Ansatz, der zu Ihrem Anwendungsfall passt:
- Injizieren Sie alle Secret-Schlüssel als Umgebungsvariablen mit additionalSpec.envFrom (Masseninjektion):
```
configuration:
  jobDeployment:
    additionalSpec:
      enabled: true
      envFrom:
        - secretRef:
            name: external-secret-as-env
```
  Bei diesem Ansatz werden alle Schlüssel aus dem Secret als Umgebungsvariablen geladen: DATABASE_PASSWORD, API_KEY und AUTH_TOKEN.
- Injizieren Sie selektiv bestimmte Secret-Schlüssel mit additionalSpec.env (detaillierte Steuerung):
```
configuration:
  jobDeployment:
    additionalSpec:
      enabled: true
      env:
        - name: DATABASE_PASSWORD
          valueFrom:
            secretKeyRef:
              name: external-secret-as-env
              key: DATABASE_PASSWORD
        - name: API_KEY
          valueFrom:
            secretKeyRef:
              name: external-secret-as-env
              key: API_KEY
```
  Bei diesem Ansatz werden selektiv nur die benötigten Schlüssel injiziert, und alle anderen Secret-Schlüssel bleiben für den Pod nicht erreichbar.
Implementieren oder aktualisieren Sie Ihre Dynamic Engine-Umgebung, um den erforderlichen Namespace zu erstellen.
```
helm upgrade --install dynamic-engine-environment-$DYNAMIC_ENGINE_ENVIRONMENT_ID \
  oci://ghcr.io/talend/helm/dynamic-engine-environment \
  --version ${DYNAMIC_ENGINE_VERSION} \
  -f $DYNAMIC_ENGINE_ENVIRONMENT_ID-values.yaml
```
Ersetzen Sie ${DYNAMIC_ENGINE_VERSION} mit der Version Ihrer Umgebung.

Mit diesem Befehl werden die Dynamic Engine-Umgebung und ihr zugeordneter Namespace qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID erstellt.
Erstellen Sie das Secret im Namespace Ihrer Dynamic Engine-Umgebung.
```
kubectl apply -f external-secret-as-env.yaml
```
Mit diesem Befehl wird die Secret-Ressource in Ihrem Kubernetes-Cluster erstellt. Das Secret kann jetzt von allen Pods im Namespace der Umgebung verwendet werden.
Aktualisieren Sie Ihre Dynamic Engine-Umgebung mit der Secret-Konfiguration.
```
helm upgrade dynamic-engine-environment-$DYNAMIC_ENGINE_ENVIRONMENT_ID \
  oci://ghcr.io/talend/helm/dynamic-engine-environment \
  --version ${DYNAMIC_ENGINE_VERSION} \
  -f $DYNAMIC_ENGINE_ENVIRONMENT_ID-values.yaml \
  -f secret-values.yaml
```
Ersetzen Sie ${DYNAMIC_ENGINE_VERSION} mit der Version Ihrer Umgebung.

Mit diesem Befehl wird Ihre Secret-Konfiguration auf die Dynamic Engine-Umgebung angewendet. Sensible Daten sind jetzt als Umgebungsvariablen in allen implementierten Tasks verfügbar.
Überprüfen Sie, ob die Secret-Umgebungsvariablen in laufenden Pods verfügbar sind.
Überprüfen Sie, ob das Secret korrekt injiziert wurde, indem Sie den Befehl entsprechend der gewählten Injektionsmethode verwenden:

Wenn Sie Masseninjektion mit envFrom verwendet haben:
```
kubectl get pod -n qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID <pod-name> \
  -o jsonpath='{.spec.containers[*].envFrom}'
```
Die erwartete Ausgabe bestätigt die Secret-Referenz:
```
[{"secretRef":{"name":"external-secret-as-env"}}]
```
Wenn Sie selektive Injektion mit env verwendet haben:
```
kubectl get pod -n qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID <pod-name> \
  -o jsonpath='{.spec.containers[*].env}'
```
Die erwartete Ausgabe zeigt, dass Ihre ausgewählten Secret-Schlüssel als Umgebungsvariablen gemountet sind.

Ergebnisse

Tasks in der Dynamic Engine-Umgebung haben jetzt sicheren Zugriff auf sensible Anmeldedaten von Kubernetes Secrets. Sie können Anmeldedaten rotieren, indem Sie das Secret aktualisieren. Die Änderungen werden wie folgt angewendet:

Datenintegrations-Tasks (einschließlich Big Data-Tasks) sind einmalige Tasks. Die aktualisierten Werte werden gelesen, wenn die nächste Task-Ausführung beginnt.
Routen und Datenservices sind dauerhaft aktive Tasks; sie laden die Secret-Änderungen nicht automatisch. Aktualisieren Sie die Task in Talend Management Console, um eine erneute Implementierung in Ihrer Dynamic Engine-Umgebung auszulösen.

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