Onboard a VM User and Register the Account as an Asset

Local accounts on servers are a classic audit blind spot: created during an incident or an onboarding, then never inventoried again. This blueprint creates a user account on an existing virtual machine using PowerShell and registers the account as a typed io.kestra.plugin.ee.assets.VM.User asset in the Kestra asset catalog, capturing the role and a compliance flag as metadata. Because the VM is declared as an input asset, the catalog records exactly which accounts exist on which machines, and access reviews become metadata queries.

How it works

1. The target_vm input names an existing VM and username names the account to create (defaults windows-web-01 and admin_user).
2. The create_windows_user task (io.kestra.plugin.scripts.powershell.Script) simulates the account creation with a Write-Output. In production you replace it with real logic such as New-LocalUser and Add-LocalGroupMember, executed on the target through your remoting mechanism.
3. The task declares the VM as an assets.inputs entry using its slugified id, wiring the account into the machine's lineage.
4. It registers the account as an assets.outputs entry of type io.kestra.plugin.ee.assets.VM.User, keyed by the slugified username plus execution id, with metadata for role, compliance_check, and the host vm.

What you get

• A cataloged VM.User asset per onboarded account, with role and compliance metadata.
• Lineage from machine to account, so decommissioning a VM surfaces the accounts that die with it.
• A queryable access inventory: assets(metadata={"role": "admin"}) lists every admin account registered through the flow.
• An auditable execution trail showing who ran the onboarding and when.

Who it's for

• IT operations teams onboarding administrators or service accounts onto Windows servers.
• Security and compliance teams running periodic access reviews.
• Platform engineers standardizing user provisioning across a VM fleet.

Why orchestrate this with Kestra

PowerShell creates the account, but nothing native records that it happened, on which machine, with which role. Kestra pairs the action with the record: the same task that provisions the user registers it as a typed asset, so the inventory is generated by the workflow itself and cannot drift. Full execution history gives you the who-when audit trail, and the assets() function turns access reviews into one-line queries inside other flows.

Prerequisites

• A Kestra Enterprise Edition instance (Assets are an EE feature).
• A VM asset already registered, for example by the asset-create-vm blueprint, matching the slugified target_vm value.
• PowerShell available to the Kestra worker or task runner executing the script.

Secrets

• None required by the stub. Add WinRM or domain credentials as secrets when you wire in real remote user creation.

Quick start

1. Run asset-create-vm so the target VM exists in the catalog.
2. Import this blueprint and execute it with the same target_vm and a username.
3. Open the Assets view to see the new VM.User asset with its role metadata and lineage.
4. Adjust the role and compliance_check metadata to match your access model.

How to extend

• Replace the Write-Output with New-LocalUser plus group membership, executed over WinRM or SSH.
• Add an approval step with io.kestra.plugin.core.flow.Pause before creating admin accounts.
• Parameterize role as a SELECT input and map it to different group memberships.
• Build an offboarding flow that queries user assets by username and removes the accounts everywhere.

Links

• Kestra Assets documentation: https://kestra.io/docs/enterprise/governance/assets
• PowerShell plugin docs: https://kestra.io/plugins/plugin-script-powershell