Konfigurieren des securityContext für Task-Container, die in Dynamic Engine-Umgebungen ausgeführt werden

Überschreiben Sie den securityContext des Standard-Containers, um Tasks mit spezifischen Benutzer-IDs und Gruppen-IDs auszuführen. Dies ermöglicht eine detaillierte Berechtigungssteuerung, verbessert die Sicherheitsposition und erfüllt die Compliance-Anforderungen, ohne Container-Images für verschiedene Benutzer-IDs oder Gruppen-IDs neu erstellen zu müssen.

Vorbereitungen

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

Warum und wann dieser Vorgang ausgeführt wird

Dieses Muster ist entscheidend für sicherheitssensible Umgebungen, auf Compliance gestützte Implementierungen und Szenarien, in denen gemountete Volumes spezifische UID/GID-Übereinstimmung erfordern.

Prozedur

Bestimmen Sie die korrekte Benutzer-ID (UID) und Gruppen-ID (GID) für Ihre Container.

Wählen Sie eine UID/GID-Kombination entsprechend Ihren Anforderungen. Einzelheiten zu den Anforderungen für den securityContext und Best Practices finden Sie in der Dokumentation zu Kubernetes Security Context.

Erstellen Sie eine Helm-Wertedatei, welche den securityContext konfiguriert.

Example

Erstellen Sie eine Datei mit dem Namen security-context-values.yaml:

configuration:
  # For Data Integration and Big Data Job tasks
  jobDeployment:
    additionalSpec:
      enabled: true
      securityContext:
        runAsUser: <user_ID>
        runAsGroup: <group_ID>
        fsGroup: <group_ID>
        runAsNonRoot: true

  # For Data Service and Route tasks
  dataServiceRouteDeployment:
    additionalSpec:
      enabled: true
      securityContext:
        runAsUser: <user_ID>
        runAsGroup: <group_ID>
        fsGroup: <group_ID>
        runAsNonRoot: true

Weitere Informationen zur Bedeutung der einzelnen Felder im securityContext finden Sie in der Dokumentation zu Kubernetes Security Context.

Implementieren oder aktualisieren Sie Ihre Dynamic Engine-Umgebung mit der securityContext-Konfiguration.
```
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 \
  -f security-context-values.yaml
```
Ersetzen Sie $DYNAMIC_ENGINE_ENVIRONMENT_ID mit Ihrer Umgebungs-ID und ${DYNAMIC_ENGINE_VERSION} mit der Version Ihrer Umgebung.

Mit diesem Befehl werden die Dynamic Engine-Umgebung und der zugeordnete Namespace qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID erstellt und die securityContext-Konfiguration auf Task-Container angewendet. Da securityContext eine Pod-Spec-Konfiguration (und keine getrennte Kubernetes-Ressource) ist, kann sie direkt in diesem einen Schritt angewendet werden.

Überprüfen Sie den securityContext in laufenden Pods.

kubectl get pod <pod_name> -n qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID \
  -o jsonpath='Pod Security Context: {.spec.securityContext}{"\n"}Container Security Context: {.spec.containers[0].securityContext}{"\n"}'

Die erwartete Ausgabe zeigt Ihren konfigurierten securityContext:

Pod Security Context: {"fsGroup":<group_id>,"runAsGroup":<group_id>,"runAsNonRoot":true,"runAsUser":<user_id>}
Container Security Context: {"allowPrivilegeEscalation":false,"capabilities":{"drop":["ALL"]},"runAsNonRoot":true,"seccompProfile":{"type":"RuntimeDefault"}}

Ergebnisse

Ihre Dynamic Engine-Job-Tasks (Datenintegration, Big Data und Datenservices) und Routen-Tasks werden jetzt mit beschränkten Nicht-Stammbenutzeridentitäten ausgeführt, wie im securityContext angegeben. Dies verbessert den Sicherheitsstatus, gewährleistet die Einhaltung von Sicherheitsstandards und verhindert, dass nicht berechtigte Container auf sensible Ressourcen zugreifen.

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