Build Notes: Importing Hosts from Azure and Google Cloud
Cloud discovery is easy to demo. The useful bit is what happens after discovery: deciding which machines belong in the estate, giving them the right access path, and making the result auditable.
We spent this week on host imports from Azure and Google Cloud. The work started as provider integration, but the real product question was broader: what should happen when a team brings an existing cloud estate into CertLocker?
A list of VM names is not enough. An imported host needs a usable connection configuration, group scope, credentials, and a sensible next step. Otherwise the import is just another inventory screen that someone still has to clean up by hand.
Start with credentials, not a blind scan
The import flow begins with the provider credential. For GCP that means a service-account key and project, with an optional zone filter. Azure supports client-secret or certificate authentication, and can reuse a stored configuration secret instead of asking the operator to paste the same values again.
That distinction matters in real environments. Cloud access credentials are themselves infrastructure secrets. They should not end up in a screenshot, a ticket, or a random shell history. The UI keeps the setup explicit, and the backend can store the provider configuration as a typed configuration asset.
Discovery should be reviewable
After connecting, CertLocker returns a preview rather than immediately creating hosts. The operator can see the instance name, address, operating system, provider location, state, and resource metadata before anything is imported.
That review step is important for estates with old instances, duplicate addresses, temporary workers, and machines that were created for one incident and never removed. Importing everything because the provider returned it is not a useful default.
Group mapping is where the import becomes useful
Cloud tags, names, resource groups, and environment labels are often the best information available for initial ownership. The importer uses those signals to suggest groups, while still allowing the operator to adjust them before import.
That gives the imported hosts a useful starting boundary for the rest of the platform. A production edge host should not automatically inherit the same access as a staging supplier portal. The group decision is not cosmetic: it is used later for scoped tokens, user access, secret visibility, and audit review.
Import is an access workflow, not just a database insert
The import result is intentionally more informative than “success”. Each selected machine becomes a host configuration, and the workflow can create the associated access token. Where a key is available, it can be attached to the host configuration rather than copied into a separate manual process.
The same result also gives the operator a next check. In the current flow, probe scanning can start after import so the team can move from “the cloud API says this VM exists” to “we have a host record and can begin verifying what is reachable”.
Azure and GCP share the workflow, not the provider details
Azure and GCP have different credential models and different instance metadata, so the integrations are not pretending to be identical. Azure includes subscription and resource-group selection, and supports both client-secret and certificate authentication. GCP uses a project and service-account configuration, with zone filtering where that is useful.
The workflow around those details is the same: configure access, discover, review, map, import, then verify. That is the useful abstraction. Operators should not need a different mental model for every cloud provider just to get a machine into the same host, token, group, and audit system.
Testing the awkward paths
The development work also added a dedicated Azure/GCP host-import E2E phase. It exercises the UI contract with provider responses mocked, which lets us test the selectors, modal steps, payload shape, group mapping, and result handling without depending on a live cloud account.
That is not a replacement for testing against real provider credentials. It is a fast boundary test. Before a real-cloud evaluation, we want to know that a change to the shared Hosts page or a provider SDK response cannot quietly break the import workflow.
What this changes for an existing estate
- Cloud instances can enter the same host inventory as bare metal, OpenStack, VPS, and on-premise machines.
- Group scope can be established during import instead of repaired later.
- Access tokens and host credentials stay part of the controlled workflow.
- Probe scanning can follow import, so reachability is checked rather than assumed.
- The import path gives the operator a reviewable record of what was selected and what happened.
There is more to do. Provider-specific credential validation needs more real-estate testing, and larger estates will need clearer filtering and import summaries. But the basic shape is now right: discovery is not the finish line. It is the first step in turning an existing cloud estate into something the operations team can actually govern.
Evaluation
Get started: book a hosted walkthrough to review host, group, token, probe and audit workflows with our engineers.
One-month onsite evaluation: have CertLocker deployed into your own environment and test the import path against the cloud accounts, Windows/Linux hosts, VPNs, supplier systems, and old infrastructure that a clean demo cannot represent.
Hosted shows the workflow. Onsite proves whether it fits your estate.