Assign an External IP and Register It as a VM Asset

IP addresses are among the most commonly lost pieces of infrastructure state: reserved in a console, attached to a machine, then forgotten until an outage or an audit. This blueprint reserves a static external IP for an existing virtual machine and registers it as a typed io.kestra.plugin.ee.assets.VM.IP asset in the Kestra asset catalog. The VM is declared as an input asset, so the catalog records both the IP itself and its attachment to the machine, and downstream flows such as certificate provisioning can look the IP up by querying asset metadata.

How it works

1. The target_vm input names an existing VM (default windows-web-01) and target_ip carries the address to reserve.
2. The reserve_ip task simulates the reservation with io.kestra.plugin.core.log.Log. In production you swap in a real task, for example io.kestra.plugin.gcp.cli.GCloudCLI running gcloud compute addresses create.
3. The task declares the VM as an assets.inputs entry using its slugified id, which requires the machine to already exist in the catalog and creates the dependency edge.
4. It registers the IP as an assets.outputs entry of type io.kestra.plugin.ee.assets.VM.IP, keyed by the address plus the execution id, with metadata recording type: static and attached_to, the VM it belongs to.

What you get

• A cataloged VM.IP asset per reserved address, with attachment metadata.
• Lineage from VM to IP, so impact analysis shows which addresses die with which machines.
• A metadata contract (attached_to) that companion flows like asset-assign-certificate query with assets() and jq to find the right IP for a VM.
• A copyable pattern for registering network resources as assets.

Who it's for

• Network and platform engineers tracking static IP inventory across a fleet.
• SRE teams that need to know which addresses are attached to which machines without a console safari.
• Teams building an asset-driven infrastructure suite on Kestra.

Why orchestrate this with Kestra

Cloud providers reserve addresses but keep the attachment knowledge inside their own consoles, invisible to your workflows. Kestra Assets make the IP a typed catalog entry with metadata that any flow can query at execution time through the assets() function. With declarative YAML, execution history, and lineage on top, IP management becomes auditable instead of anecdotal.

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.

Secrets

• None required by the stub. Add cloud credentials as secrets when you wire in a real reservation task.

Quick start

1. Run asset-create-vm (or register a VM asset another way) so the input asset exists.
2. Import this blueprint and execute it with the same target_vm value.
3. Open the Assets view to see the new VM.IP asset and its lineage edge from the VM.
4. Run asset-assign-certificate next; its dynamic input will discover this IP via metadata.

How to extend

• Replace the Log stub with io.kestra.plugin.gcp.cli.GCloudCLI or io.kestra.plugin.aws.cli.AwsCLI to reserve a real address.
• Add DNS registration and record the resulting hostname in the asset metadata.
• Validate that the VM asset exists before reserving, and fail fast with a clear error if it does not.
• Emit a notification with the reserved address using a Slack or email task.

Links

• Kestra Assets documentation: https://kestra.io/docs/enterprise/governance/assets
• Core plugin docs: https://kestra.io/plugins/core