Skip to content
Soul Stack

CloudDriver and SshProvider

Beyond SoulModule (Destiny steps, host = the soul agent), there are two server-side plugin types — launched by keeper, not by the agent on the host. The general model, handshake, manifest, and SDK are the same as described in the extending overview; the gRPC contract differs.

CloudDriver — cloud providers

Section titled “CloudDriver — cloud providers”

CloudDriver manages the lifecycle of virtual machines at a cloud provider: it creates, deletes, resizes, and queries VMs. The binary is soul-cloud-<provider>, the host is keeper.

The driver is invoked from the Keeper-side module core.cloud (a step with on: keeper, addressed as core.cloud.created / .destroyed / .resized): the scenario asks the driver to create/delete/resize a VM, and Keeper records the result in its registries. So the driver does not touch the host’s filesystem — it works with the cloud API.

The CloudDriver contract covers creating, deleting, resizing, status polling, and listing VMs, plus the provider profile schema (declared in the plugin manifest under kind: cloud_driver).

SshProvider — SSH credentials for push

Section titled “SshProvider — SSH credentials for push”

SshProvider supplies SSH credentials for Keeper’s push mode — when Keeper applies Destiny on a host over SSH, with no agent installed. The binary is soul-ssh-<provider>, the host is keeper.

A single SshProvider contract accommodates different access-issuance models — a static key, Vault SSH CA (minting a certificate on demand), Teleport. The provider type is declared in the plugin manifest under kind: ssh_provider.

Access security is a priority: for CA models the private key is generated on the Keeper side and never leaves it — only the public key goes to the provider for signing, and a certificate comes back. The fewer points the private key passes through, the smaller the leak surface.

One SDK for all types

Section titled “One SDK for all types”

All three contracts (SoulModule, CloudDriver, SshProvider) are written through one public Go SDK with a shared handshake mechanism and a shared manifest format. The plugin type is set by the kind field in the manifest (soul_module / cloud_driver / ssh_provider); only the gRPC contract you implement differs. The skeleton and the interface are as described in the extending overview and, for modules, in How to write a SoulModule.

What’s next

Section titled “What’s next”