Script Management for Worker Nodes

Run common maintenance and troubleshooting scripts directly from the application. This reduces the need for command line interface (CLI) access or coordination with support by providing an effective and easy way to execute critical scripts.

Note:

Script Management is currently under Public Preview starting in 202505.1.0. Please contact your account representative or OneTrust Support to request early access.

Important:

Script execution will be unavailable for any new worker nodes without current installations or any problematic worker nodes with non-functional dd-workernode-ops pod.



To access script management

  1. On the Data Discovery menu, select Setup > Worker Nodes. The Worker Nodes screen appears.

  2. Select a worker node from this list screen. The Worker Details screen appears.

  3. Navigate to the Administration tab.
  4. For the Script Name field, select a script from the available options (see the table below for full descriptions). The Script Content field will appear and populate the script information.
    Note:

    This content is read-only and cannot be edited.



    Script Name

    Description

    Purpose

    Environment Variables

    Migrate Workernode to Hardened Images

    Updates worker node with more hardened images.

    Triggers an update in upgrade.sh to harden images for improved security.

    None

    Purge Failed Pods

    Cleans up pods stuck in non-running state.

    To forcibly delete pods in states like Init:ContainerUnknown, ContainerUnknown, Evicted, OOMKilled.

    None

    Reinstall Workernode

    Reinstalls the worker node using upgrade.sh and deploy.sh.

    To reinstall deleted or missing resources or to apply the current version's Helm chart.

    None

    Reset Kafka

    Resets Kafka (and related components) by scaling down, deleting PVCs, and restoring.

    For long-running or stuck scans, Kafka failures or intermittent connectivity, or PVC failures causing unread messages in topics.

    Ensure no scans are running, as messages will be deleted.

    None

    Reset Loki

    Resets the Loki StatefulSet.

    For Issues related to Loki log usage, PVC consumption, file lock errors (especially on RWX storage class), or other Loki errors.

    Logs from the last 7 days will be lost.

    None

    Reset Postgres

    Resets the Postgres StatefulSet

    For Postgres errors, PVC consumption issues, or intermittent network connectivity problems.

    This will delete scan job metadata, so ensure you understand the impact on running jobs.

    None

    Reset Workernode

    Performs a full worker node reset including Kafka, Postgres, Loki, and core deployments.

    As last resort when worker node is unhealthy and restarting deployments/statefulsets doesn’t help.

    This will impact jobs in progress as scan data is cleaned up.

    None

    Restart Deployment

    Restarts a specified Kubernetes deployment

    To fix scan jobs stuck issues or pod scheduling errors

    DEPLOYMENT_NAME

    Restart Stateful

    Restarts a specified StatefulSet

    To fix scan job stuck issues, pod scheduling issues, or PVC mount errors.

    STATEFULSET_NAME

    Run command in scanner-extlib

    Executes a custom command inside scanner_extlib pod.

    For connectivity tests (e.g., nc, telnet, ping, nslookup, SSLPoke, dig) or using helper tools (vault-helper, kafka-helper)

    POD_EXEC_COMMAND

    • nslookup:

    • SSL Check:

    • Run any kubectl commands, like setting limits or requests for a container on the pod.

    Scale Deployment

    Scales a deployment to a specified replica count.

    To scale up scanner or Tika pods before scans.

    SCALE_REPLICAS, DEPLOYMENT_NAME

    • SCALE_REPLICAS - 5

    • DEPLOYMENT_NAME- rdbms-scanner

    Scale Kafka Partitions

    Scales Kafka partitions for a specified scanner.

    To increase partitions when scaling beyond 8 scanner pods. Default is 16 partitions to support 8 pods. For 12 pods, set to 24 partitions.

    Pods cannot be scaled down.

    PARTITION_COUNT, DEPLOYMENT_NAME

    • PARTITION_COUNT - 40

    • DEPLOYMENT_NAME - storage-scanner

    Set Environment Variable

    Adds/updates an environment variable in a deployment.

    To enable/disable specific features or adjust logging levels by setting environment variables dynamically.

    DEPLOYMENT_NAME, SET_ENV_VAR in KEY=VALUE format.

    • DEPLOYMENT_NAME - rdbms-scanner

    • SET_ENV_VAR - LOGGING_LEVEL_COM_ONETRUST=DEBUG

    Sync Environment Variable to Cloud

    Syncs a variable to the cloud configuration.

    To persist any environment variable updates made manually in terminal so they survive future upgrades or reinstalls.

    ENV_VALUE, IS_ENCRYPTED, ENV_VARIABLE

    • ENV_VALUE - 10

    • IS_ENCRYPTED - false

    • ENV_NAME - APACHE_TIKA_REPLICAS_COUNT

    Sync Environment Variable to Cloud

    Enforces Kafka KRaft for the worker node.

    To check if Zookeeper StatefulSet exists, delete if true, and enabling KRaft mode as true in the cloud environment.

    None

    View Workernode Diagnostics

    Scans the worker node namespace for resource metadata, usage, events

    To quickly inspect the namespace using kubectl get/describe output.

    None
  5. Depending on your chosen script, you may need to provide environment variables. Enable the setting to populate the Variable (filled by default) and Value fields. Use the Add icon to list multiple environment variables.


  6. Enable the Arguments setting to provide a custom value to be used as part of the script after the .sh scripts.


  7. Click the Execute button. A warning modal appears outlining the risks.
  8. Click to confirm, then click the Proceed button.


  9. A confirmation modal appears to indicate a successful script execution. The worker node status will be Down while the script is processing.


  10. Navigate to the Services tab to locate and select the log pod named k8s-script-job-for-<scriptname>-<guid> to view the execution log.
    Note:

    For scripts like reinstall_wn or reset_*, the application may temporarily become unresponsive. Logs will be accessible once pods recover.



Limitations

Scripts that attempt to delete and recreate PVCs may not fully clean up ReadWriteMany (RWX) type volumes, especially when:

  • The storage class is backed by NFS mounts across namespaces (e.g., via nfs-provisioner pods), or mounts are external (e.g., on a remote NFS server or EFS). In such cases, cleanup requires:

    • Manual deletion of the PVC and PV objects.

    • Manual cleanup of the backing directory (volume path) on the NFS/EFS server.

  • These actions cannot be performed by WMA scripts since:

    lack cross-namespace permissions

    The executing podsto access thenfs-provisionerorefs-provisioner.

    do not have shell access

    Theyinto provisioner pods or the NFS server directly.

RBAC/Permission-Related Failures

This feature relies on a service account to execute jobs within the namespace. If this service account does not have sufficient RBAC permissions, certain scripts may fail. Examples include:

  • Missing delete, create, or patch access on resources like pods, pvc, sts, deployments, etc.

  • Inability to exec into a running pod (for scripts that require in-pod command execution).

Attention:

reset* scripts are not supported in AWS Fargate due to above limitations. Other scripts will still continue to work as expected.