GCP Deployment: Technical Details
This page provides in-depth technical information about how AIR deploys Responders to Google Cloud Platform assets. For basic GCP setup and configuration, see Cloud Forensics.
Script Generation and Storage
When you deploy a Responder to a GCP asset, AIR generates a unique deployment script and stores it in your GCS bucket. The script filename is generated using a SHA-256 hash (truncated to 16 characters) of key deployment parameters:
Console address and version
Responder package version
Organization ID and deployment token
Relay server details (if configured)
Connection route information (if applicable)
GCS path format:
gs://<bucketName>/air-responder-deploy-scripts/<hash>.ps1 (Windows)
gs://<bucketName>/air-responder-deploy-scripts/<hash>.sh (Linux)If a script with identical parameters already exists, it is reused rather than re-uploaded.
Patch Job Execution
The deployment uses GCP OS Config to execute the script on the target VM:
ExecStep Configuration — References the GCS object with bucket name, object path, and generation number
Interpreter Selection — PowerShell for Windows, Shell for Linux
Patch Job Creation — A patch job is created targeting the specific VM instance
Patch job naming:
Display name:
binalyze-air-responder-deploy-<instanceName>Description:
Binalyze AIR Responder deployment on <instanceName>
The patch job is configured with rebootConfig: NEVER to prevent automatic reboots after deployment.
Status Monitoring
AIR monitors the patch job via the OS Config API, tracking:
Job status (started, patching, succeeded, failed)
Error messages
Progress percentage
Deployment logs are retrieved from Cloud Logging to surface command output and error details.
Prerequisites Checklist
OS Config Agent
Must be installed and running on target VMs
GCS Bucket
Must exist and be accessible by service account
IAM Roles
Service account needs Storage Object Admin on bucket
Network
VMs must reach GCS and OS Config API endpoints
Last updated
Was this helpful?