Event-driven VM cleanup from vCenter removal events

Decommissioned virtual machines leave a trail of stale infrastructure: orphaned DNS A records, dead Active Directory computer objects, and ghost endpoints in your EDR console. This blueprint turns VMware vCenter into the source of truth for VM lifecycle and lets Kestra react in real time. The flow subscribes to VM_REMOVED events on vCenter, then fans out the offboarding work across DNS, AD, and CrowdStrike so your CMDB, security posture, and IP space stay clean without manual tickets.

How it works

1. The io.kestra.plugin.ee.vmware.vcenter.Trigger polls vCenter every minute (interval: PT1M) for events matching eventType: VM_REMOVED and a configurable vmNameRegex filter.
2. io.kestra.plugin.core.flow.ForEach iterates over {{ trigger.events }}, so a single poll cycle can offboard many VMs in parallel.
3. io.kestra.plugin.core.log.Log records the VM name, event type, and timestamp for audit trails.
4. A Sequential block runs three cleanup steps per VM:
   • io.kestra.plugin.scripts.powershell.Commands calls Remove-DnsServerResourceRecord to drop the DNS A record.
   • A second PowerShell task calls Remove-ADComputer to delete the Active Directory computer object.
   • io.kestra.plugin.core.http.Request POSTs action_name: hide_host to the CrowdStrike devices-actions/v2 API to retire the sensor.

What you get

• Zero-touch decommissioning the moment vCenter removes a VM.
• Clean DNS zones, no stale A records pointing to recycled IPs.
• Active Directory free of orphaned computer accounts, reducing Kerberos and GPO noise.
• CrowdStrike licenses freed up and ghost hosts hidden from detection dashboards.

Who it's for

Platform, virtualization, and infrastructure engineers running VMware on-prem or in hybrid cloud, Windows admins who own AD and DNS, and SecOps teams who manage CrowdStrike Falcon.

Why orchestrate this with Kestra

vCenter alarms and PowerCLI scripts can fire on a VM removal, but they cannot natively coordinate a multi-system workflow across DNS, AD, and a SaaS EDR with retries, logs, and audit lineage. Kestra adds an event-driven trigger that fans out into typed tasks, retries each cleanup independently, captures structured logs per VM, and keeps the entire policy declarative in version-controlled YAML. If CrowdStrike rate-limits or AD is briefly unreachable, only the failing branch retries, the rest already succeeded.

Prerequisites

• A VMware vCenter Server reachable from your Kestra workers, with an account that can read events.
• A Windows host or worker with the DNS Server and Active Directory PowerShell modules installed.
• A CrowdStrike Falcon API client with hosts:write scope.
• Kestra Enterprise Edition (the vCenter trigger ships with EE plugins).

Secrets

• VMWARE_VCENTER_USERNAME, vCenter service account username.
• VMWARE_VCENTER_PASSWORD, vCenter service account password.
• CROWDSTRIKE_API_TOKEN, bearer token for the CrowdStrike API.

Quick start

1. Add the three secrets above to your Kestra tenant.
2. Update server, the DNS ZoneName, and vmNameRegex to match your environment.
3. Deploy the flow to a namespace and confirm the trigger appears as active.
4. Remove a test VM from vCenter that matches the regex and watch the execution log the event, drop the DNS record, delete the AD object, and hide the host in CrowdStrike.

How to extend

• Add a io.kestra.plugin.notifications.slack.SlackIncomingWebhook step to broadcast each offboarding to your platform channel.
• Append an IPAM reclaim call (Infoblox, phpIPAM, BlueCat) so the released IP returns to the pool.
• Open a ServiceNow change ticket via HTTP for audit before executing destructive steps.
• Branch on vmNameRegex to route production versus lab VMs to different cleanup policies.
• Replace the CrowdStrike call with SentinelOne, Defender for Endpoint, or your EDR of choice.

Links

• Plugin docs: https://kestra.io/plugins/plugin-ee-vmware
• PowerShell scripts plugin: https://kestra.io/plugins/plugin-script-powershell