Lightweight Worker Node Google Cloud Deployment Troubleshooting

Overview

This guide covers deployment failures when creating a lightweight worker node through Google Cloud Platform Infrastructure Manager (Terraform) from the OneTrust platform.

The deployment uses the main.tf, variables.tf, and tf.auto.tfvars Terraform files and typically takes 15–25 minutes. It creates a VPC network, a subnetwork, firewall rules for SSH, egress, and proxy traffic, and a Compute Engine instance.

Prerequisites and GCP permissions

Required GCP roles

The deployment service account must have the following roles:

Role

Role ID

Purpose

Compute Instance Admin (v1)

roles/compute.instanceAdmin.v1

Create, update, and delete Compute Engine instances.

Service Account User

roles/iam.serviceAccountUser

Run an instance as a service account.

Compute Network Admin

roles/compute.networkAdmin

Read and create VPC networks, subnets, and firewall rules.

Compute Security Admin

roles/compute.securityAdmin

Manage firewall rules.

Config Admin

roles/config.admin

Control Infrastructure Manager resources.

Config Agent

roles/config.agent

Work with Infrastructure Manager deployments, revisions, logging, and Terraform state.

Where to check permissions

Go to GCP Console > IAM > Service Accounts, and select the deployment service account. Verify that all roles above are assigned.

Go to GCP Console > Infrastructure Manager and verify that the service account is authorized.

GCP quotas

Resource

Default limit

Where to check

CPUs per region

Varies (typically 24–100)

GCP Console > IAM > Quotas > filter by region

In-use IP addresses

8 per region

GCP Console > IAM > Quotas

Firewall rules per VPC

500

Networks per project

15

Subnets per VPC

300

Terraform parameters explained

Parameters set by the OneTrust platform

These parameters are automatically populated in tf.auto.tfvars when you select Activate worker node:

Variable

Description

Default

onetrust_token

Base64-encoded OneTrust configuration, including the VM name, tokens, and environment variables

Auto-populated

vm_name

VM name from the OneTrust token

Auto-populated

admin_username

SSH administrator username

ubuntu

admin_ssh_key

SSH public key

User-provided in the OneTrust platform

vm_operating_system

Operating system for the VM: ubuntu22 or ubuntu24

ubuntu24

vm_size

GCP machine type

e2-standard-16

project

GCP project ID

User-provided in the OneTrust platform

region

GCP region

User-provided in the OneTrust platform

zone

GCP zone

User-provided in the OneTrust platform

Optional parameters

Variable

Default

Description

use_existing_vpc

false

Use an existing VPC or create a new one.

existing_vpc_name

(blank)

Existing VPC name when use_existing_vpc is true.

existing_subnet_name

(blank)

Existing subnet name when use_existing_vpc is true.

enter_proxy

false

Configure an HTTP proxy.

proxy_ip

(blank)

Proxy server IP address.

proxy_port

8080

Proxy server port.

disk_type

pd-standard

Persistent disk type.

Deployment scenarios

use_existing_vpc

What happens

false (default)

Creates a new VPC network and subnetwork. Assigns an external IP to the VM for outbound access.

true

Uses the existing VPC and subnetwork. No external IP is assigned. The existing subnet must have Cloud NAT or another egress mechanism for the VM to reach OneTrust APIs.
Note:

When use_existing_vpc is true, the Terraform template does not assign an external IP to the VM.

Failure catalog

Infrastructure Manager failures

Deployment failed – required API not enabled

Console error:

CODE 
Infrastructure Manager API has not been used in project xxx before or it is disabled.

Where to check: GCP Console > APIs & Services > search for Infrastructure Manager or Compute Engine.

Root cause: One or more required APIs are not enabled in the project. This is rare on established projects, but can happen on recently created projects with restrictive organization policies.

Fix: Enable the required APIs:

CODE 
gcloud services enable compute.googleapis.com
gcloud services enable config.googleapis.com
gcloud services enable cloudresourcemanager.googleapis.com

Verify the status:

CODE 
gcloud services list --enabled --filter="name:compute.googleapis.com OR name:config.googleapis.com"

Retry the deployment from the OneTrust platform.

Deployment failed – service account not authorized

Console error:

CODE 
Permission denied on resource project xxx.
The caller does not have permission.

Where to check: GCP Console > Infrastructure Manager > Deployments > select the deployment > Logs.

Root cause: The service account selected during deployment lacks one or more required roles.

Fix: Go to GCP Console > IAM > Service Accounts and find the deployment service account. Ensure that all roles from the Required GCP roles section are assigned. Retry the deployment from the OneTrust platform.

Deployment failed – Terraform state lock error

Console error:

CODE 
Error acquiring the state lock.
Locking failed: ...

Where to check: GCP Console > Infrastructure Manager > Deployments > select the deployment > Logs.

Root cause: A previous deployment attempt left a Terraform state lock. This can happen if a deployment was canceled during the apply operation.

Fix: Go to GCP Console > Infrastructure Manager > Deployments and find the stuck deployment. Delete the deployment to release the lock, then retry the deployment from the OneTrust platform.

VPC and network failures

VPC creation failed – network name conflict

Console error:

CODE 
The resource 'projects/xxx/global/networks/<vm-name>' already exists.

Where to check: GCP Console > VPC network > check for existing networks with the same name.

Root cause: A previous deployment or failed attempt left an orphaned VPC with the same name as the VM.

Fix: Delete the orphaned VPC: GCP Console > VPC network > find <vm-name> > Delete. Ensure that no subnets or firewall rules reference it, then retry the deployment.

Subnet creation failed – IP range conflict

Console error:

CODE 
The IP range '10.0.0.0/24' conflicts with an existing subnetwork in region xxx.

Where to check: GCP Console > VPC network > Subnets > check for overlapping CIDR ranges.

Root cause: The default subnet CIDR 10.0.0.0/24 conflicts with an existing subnet in the same region.

Fix: Use an existing VPC and subnet by setting use_existing_vpc to true and providing the names, or delete the conflicting subnet if it is unused. The template does not expose the subnet CIDR as a parameter. Contact OneTrust Support for a custom CIDR.

Firewall rule creation failed – duplicate rule name

Console error:

CODE 
The resource 'projects/xxx/global/firewalls/<vm-name>-allow-ssh' already exists.

Root cause: Orphaned firewall rules remain from a previous deployment.

Fix: Go to GCP Console > VPC network > Firewall and find rules with the <vm-name> prefix. Delete the orphaned rules, then retry the deployment.

Compute instance failures

VM creation failed – quota exceeded

Console error:

CODE 
Quota 'CPUS' exceeded.
Limit: XX in region xxx.

Where to check: GCP Console > IAM > Quotas > filter by CPUs and region.

Root cause: The project does not have enough CPU quota for e2-standard-16, which requires 16 vCPUs.

Fix: Request a quota increase: GCP Console > IAM > Quotas > select CPUs > Request increase. Alternatively, use a smaller machine type, although this is not recommended because it is below the minimum specifications, or free up CPUs by stopping unused VMs in the region.

VM creation failed – machine type not available in zone

Console error:

CODE 
The machine type 'e2-standard-16' is not available in zone 'xxx'.

Where to check: GCP Console > Compute Engine > Machine types > filter by zone.

Root cause: Not all machine types are available in all zones.

Fix: Try a different zone in the same region, such as us-central1-b instead of us-central1-a. Check available machine types:

CODE 
gcloud compute machine-types list --filter="zone:us-central1-a" | grep e2-standard-16

VM creation failed – image not found

Console error:

CODE 
The resource 'projects/ubuntu-os-cloud/global/images/family/ubuntu-2404-lts-amd64'
  was not found.

Where to check: GCP Console > Compute Engine > Images > filter by ubuntu.

Root cause: The Ubuntu image family name has changed or is not available in the project.

Fix: Verify that the image family exists:

CODE 
gcloud compute images list --filter="family:ubuntu-2404-lts" --project=ubuntu-os-cloud

Try ubuntu22 instead of ubuntu24. If neither works, contact OneTrust Support.

VM creation failed – disk type not available

Console error:

CODE 
The disk type 'pd-standard' is not available in zone 'xxx'.

Root cause: Some zones may not support pd-standard.

Fix: Try pd-balanced or pd-ssd. Contact OneTrust Support to update the disk_type variable in the Terraform template.

Startup script failures

VM running, but the lightweight worker node shows the Awaiting activation status

Symptom: The GCP deployment succeeds, and the VM is running, but the OneTrust platform shows Awaiting activation.

Where to check: GCP Console > Compute Engine > VM instances > find the VM > Serial console (port 1). Alternatively, SSH to the VM:

CODE 
gcloud compute ssh <vm-name> --zone=<zone>

Check the startup log:

CODE 
cat /var/log/syslog | grep startup
journalctl

Check the installer log:

CODE 
cat /home/ubuntu/installer.log

Root causes:

  • The VM cannot reach <tenant>.onetrust.com because of a firewall or VPC egress issue.

  • The installer.sh download failed because of a network timeout.

  • The deploy.sh installation failed because of a K3s or Helm error.

  • The proxy is not configured correctly.

  • AppArmor or SELinux is blocking K3s. The template disables both, but the operation may fail on some images.

Fix: Test connectivity from the VM:

CODE 
curl -I https://<tenant>.onetrust.com

If you use an existing VPC, verify that Cloud NAT or another egress mechanism is configured. Check installer.log for the specific error. If AppArmor blocked K3s, run:

CODE 
sudo systemctl stop apparmor
sudo systemctl disable apparmor

Startup script – AppArmor or SELinux disable failed

Symptom: The VM is running, but K3s fails to start. The serial console shows AppArmor or SELinux errors.

Where to check: SSH to the VM and run sudo systemctl status apparmor or sudo sestatus.

Root cause: The startup script attempts to disable AppArmor on Ubuntu and SELinux on RHEL because they can interfere with K3s container isolation. If the disable operation fails, K3s may not start.

Fix: SSH to the VM and manually disable AppArmor:

CODE 
sudo systemctl stop apparmor
sudo systemctl disable apparmor
sudo apt-get purge -y apparmor apparmor-utils

Alternatively, manually disable SELinux if you use RHEL:

CODE 
sudo setenforce 0
sudo sed -i 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config

Re-run the installer:

CODE 
cd /home/ubuntu/onetrust-dd-installer-*/data-discovery/litenode-deployment/
./deploy.sh install skip-prompt

Startup script – installer download timeout

Symptom: installer.log shows a curl timeout or partial download.

Root cause: The installer downloads 5–10 GB of container images. On slow networks or through proxies, the download can time out.

Fix: Check network throughput from the VM:

JSON 
curl -o /dev/null -w "%{speed_download}" https://<tenant>.onetrust.com/api/discovery-scan-config/v1/installer-config/<id>/download

If you use an existing VPC without an external IP, verify that Cloud NAT is working. Manually re-run the installer:

CODE 
cd /home/ubuntu
curl -L -o installer.sh -H "Authorization: Bearer <TOKEN>" \
  "https://<tenant>.onetrust.com/api/discovery-scan-config/v1/installer-config/<WN_ID>/download"
chmod +x installer.sh
echo "1111" | ./installer.sh extract-zip
cd onetrust-dd-installer-*/data-discovery/litenode-deployment/
./deploy.sh install skip-prompt

Existing VPC-specific failures

VM has no external IP – cannot reach OneTrust

Symptom: A VM deployed with use_existing_vpc set to true has no external IP and cannot download the installer.

Root cause: When using an existing VPC, the template does not assign an external IP to the VM because the access_config block is conditional. The existing subnet must have Cloud NAT or another egress mechanism.

Fix: Go to GCP Console > VPC network > Cloud NAT and verify that NAT is configured for the subnet's region. If no NAT exists, create one: GCP Console > VPC network > Cloud NAT > Create. Alternatively, temporarily assign an external IP to the VM for installation, then remove it.

Existing VPC – firewall rules not applied

Symptom: A VM deployed in an existing VPC cannot be accessed through SSH or cannot access outbound services.

Root cause: The template creates firewall rules on the VPC specified by network_self_link. If the existing VPC has higher-priority deny rules, the OneTrust rules may not take effect.

Fix: Go to GCP Console > VPC network > Firewall and check for deny rules with a higher priority. The template creates rules with a default priority of 1000. A rule with a lower priority number takes precedence. Manually add higher-priority allow rules if needed.

AI Guard-specific failures

AI Guard port 4443 not reachable – known GCP gap

Symptom: AI Guard is enabled, but port 4443 is not reachable from outside.

Known gap: The GCP Terraform template does not currently create a firewall rule for inbound port 4443. AWS and Azure templates handle this automatically.

Where to check: GCP Console > VPC network > Firewall > search for <vm-name> rules.

Fix: Manually create a firewall rule:

  • Go to GCP Console > VPC network > Firewall > Create firewall rule.

  • Name: <vm-name>-allow-aiguard.

  • Network: <your-vpc>.

  • Direction: Ingress.

  • Source IP ranges: <your-trusted-cidr>.

  • Protocols: tcp:4443.

  • Target tags: <vm-name>.

Alternatively, use the gcloud CLI:

CODE 
gcloud compute firewall-rules create <vm-name>-allow-aiguard \
  --network=<vpc-name> \
  --direction=INGRESS \
  --source-ranges=<your-cidr> \
  --rules=tcp:4443 \
  --target-tags=<vm-name>

Post-deployment verification

GCP Console

Go to GCP Console > Infrastructure Manager > Deployments and find the deployment. Confirm that the status is SUCCEEDED.

Go to GCP Console > Compute Engine > VM instances and find the VM. Confirm that the status is Running. Confirm that an external IP is present for a new VPC or absent for an existing VPC with NAT. Use the serial console to check for startup script completion.

SSH verification

If an external IP is assigned:

CODE 
ssh -i ~/.ssh/your-key ubuntu@<vm-external-ip>

If you use an existing VPC without an external IP:

CODE 
gcloud compute ssh <vm-name> --zone=<zone>
CODE 
# Check K3s
sudo systemctl status k3s
CODE 
# Check pods
kubectl get pods -n onetrust
# Expected: 18 pods Running (17 without AI Guard)
CODE 
# Check installer log
cat ~/installer.log | tail -20

OneTrust platform

To check the lightweight worker node status, go to Data Discovery > Worker nodes. The status should transition to Healthy within 20–30 minutes. If it is still Awaiting activation after 30 minutes, SSH to the VM and check installer.log.

Cleanup and rollback

Delete a failed deployment

Go to GCP Console > Infrastructure Manager > Deployments. Find the deployment and select Delete. This runs terraform destroy and removes all resources.

If the deployment is stuck, you may need to force-delete it.

Orphaned resource cleanup

If the Infrastructure Manager does not clean up properly:

Resource

Where to find

How to delete

Compute instance

GCP Console > Compute Engine > VM instances

Select the instance > Delete.

VPC network

GCP Console > VPC network > check for <vm-name>

Select the VPC network associated with vm-name, then click Delete. Remove all subnets and firewall rules first.

Subnet

GCP Console > VPC network > Subnets

Find <vm-name>-subnet > Delete.

Firewall rules

GCP Console > VPC network > Firewall

Find rules with the <vm-name> prefix > delete each.

Persistent disk

GCP Console > Compute Engine > Disks

Find <vm-name> > Delete, if it was not automatically deleted with the VM.

OneTrust platform cleanup

To delete a lightweight worker node, see Managing Worker Node Details: To delete worker nodes.

The delete action removes the OneTrust resource but does not delete GCP cloud resources. You must manually clean up GCP resources or delete them through Infrastructure Manager.

Soft recovery without deleting the VM

If the VM is operating correctly but K3s or Helm is not working, SSH to the VM and uninstall K3s:

CODE 
sudo /usr/local/bin/k3s-uninstall.sh

Re-download and install the lightweight worker node:

CODE 
curl -L -o ~/installer.sh -H "Authorization: Bearer <TOKEN>" \
  "https://<tenant>.onetrust.com/api/discovery-scan-config/v1/installer-config/<WN_ID>/download"
chmod +x ~/installer.sh
echo "1111" | ~/installer.sh extract-zip
cd ~/onetrust-dd-installer-*/data-discovery/litenode-deployment/
./deploy.sh install skip-prompt

Quick reference

Symptom

Likely cause

Where to look

Deployment failed

Service account permissions

Infrastructure Manager > Logs

Deployment failed

API not enabled

APIs and Services

Deployment failed

VPC name conflict

VPC network > check existing networks

Deployment failed

Quota exceeded

IAM > Quotas

VM running, node in Awaiting activation status

Startup script failure

Serial console or SSH > installer.log

VM has no external IP

Existing VPC without NAT

VPC network > Cloud NAT

Port 4443 is not reachable

AI Guard firewall gap

Manually create a firewall rule

Node in Unhealthy status

NATS blocked

See Lightweight Worker Node Troubleshooting and Administration: Post-deployment troubleshooting.