# 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](https://help.qlik.com/talend/en-US/dynamic-engine-configuration-guide/Cloud/custom-kubernetes-resource-mounting).

## 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

1. 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](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/).
2. 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](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/).
3. 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.
4. 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 data integration tasks (including big data), 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.