ON THIS PAGE

DID THIS PAGE HELP YOU?

If you find any issues with this page or its content – a typo, a missing step, or a technical error – please let us know!

Configuring securityContext for task containers running in Dynamic Engine environments

Override default container securityContext to run tasks with specific user IDs and group IDs. This enables fine-grained permission control, improving security posture, and meeting compliance requirements without rebuilding container images for different user IDs or group IDs.

Before you begin

See Prerequisites and Important considerations.

About this task

This pattern is essential for security-sensitive environments, compliance-driven deployments, and scenarios where mounted volumes require specific UID/GID matching.

Procedure

Determine the appropriate user ID (UID) and group ID (GID) for your containers.

Choose a UID/GID combination based on your needs. For details on securityContext requirements and best practices, see Kubernetes Security Context documentation.

Create a Helm values file that configures the securityContext.

Example

Create a file named 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

For information on what each field in securityContext means, see Kubernetes Security Context documentation.

Deploy or upgrade your Dynamic Engine environment with securityContext configuration.
```
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
```
Replace $DYNAMIC_ENGINE_ENVIRONMENT_ID with your environment ID and ${DYNAMIC_ENGINE_VERSION} with your environment's version.

This command creates the Dynamic Engine environment and its associated namespace qlik-processing-env-$DYNAMIC_ENGINE_ENVIRONMENT_ID, and applies the securityContext configuration to task containers. Since securityContext is a pod spec configuration (not a separate Kubernetes resource), it can be applied directly in this single step.

Verify the securityContext in running 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"}'

Expected output shows your configured 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"}}

Results

Your Dynamic Engine Job (Data Integration, Big Data, and Data Services) and Routes tasks now execute with restricted, non-root user identities as specified by the securityContext. This improves security posture, ensures compliance with security standards, and prevents unprivileged containers from accessing sensitive resources.

Did this page help you?

If you find any issues with this page or its content – a typo, a missing step, or a technical error – please let us know!

Leave your feedback here