Assign a TLS Certificate to a VM as a Kestra Asset

Certificates expire silently when nobody records where they live. This blueprint provisions a TLS certificate for a virtual machine and registers it as a typed io.kestra.plugin.ee.assets.VM.Certificate asset, with lineage back to both the VM and the IP address it protects. Its standout feature is asset-driven input resolution: the ip_asset_id input queries the catalog at execution time to find the IP asset attached to the chosen VM, so operators never paste raw asset ids.

How it works

1. The target_vm and target_ip inputs identify the machine and address to certify.
2. The ip_asset_id input is a dynamic SELECT with dependsOn: [target_vm]. Its expression calls assets(type='io.kestra.plugin.ee.assets.VM.IP'), pipes the result through jq to select the entry whose metadata.attached_to equals the chosen VM, and takes the first match. With autoSelectFirst: true the right IP asset is preselected as soon as the VM name is typed.
3. The certbot_provision task (io.kestra.plugin.scripts.shell.Script) simulates the ACME issuance. It declares two assets.inputs, the slugified VM and the resolved IP asset, wiring the certificate into the lineage graph.
4. It registers the certificate as an assets.outputs entry keyed cert-{{ execution.id }}, with issuer, valid_until, and vm metadata.

What you get

• A cataloged VM.Certificate asset per issuance, with issuer and expiry metadata you can query.
• Lineage from VM and IP to certificate, so decommissioning a machine surfaces its certs.
• A reference implementation of dependent, catalog-driven SELECT inputs using assets(), jq, and dependsOn.
• The data needed for an expiry-monitoring flow to alert on valid_until.

Who it's for

• Platform and security engineers automating certificate issuance across a VM fleet.
• SRE teams tired of spreadsheet-based certificate inventories.
• Anyone building asset-aware forms where one input filters another.

Why orchestrate this with Kestra

Certbot issues certificates but keeps no inventory, no link to the machine or address, and no expiry governance. Kestra Assets give every certificate a typed catalog entry with metadata and lineage, while the assets() expression function turns the catalog into live form data for execution inputs. Add schedules, retries, and full audit history, and certificate management becomes observable end to end.

Prerequisites

• A Kestra Enterprise Edition instance (Assets are an EE feature).
• A VM asset and an attached VM.IP asset already registered, for example by running asset-create-vm then asset-assign-external-ip, otherwise the ip_asset_id dropdown is empty.

Secrets

• None required by the stub. Add DNS provider or ACME account credentials as secrets when you wire in a real certbot invocation.

Quick start

1. Run asset-create-vm and asset-assign-external-ip for the same VM name.
2. Import this blueprint and execute it; the IP asset is auto-selected from the catalog.
3. Inspect the new VM.Certificate asset and its lineage in the Assets view.
4. Update valid_until metadata to match your real certificate lifetime.

How to extend

• Replace the echo with a real certbot certonly command or an ACME client container.
• Compute valid_until from the actual certificate instead of hardcoding it.
• Add a scheduled companion flow that queries assets(type='io.kestra.plugin.ee.assets.VM.Certificate') and alerts when expiry is near.
• Push the issued certificate to a secret manager and record the reference in metadata.

Links

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