Cloud Onboarding

Cloud onboarding lets a Ringleader control plane create, manage, and tear down Workstation VMs inside your own cloud account (your subscription, your project, your bill, your network) while granting Ringleader only the minimum permissions it needs and never a broad account admin.

You run a small set of Infrastructure-as-Code assets once, in your account, and hand a few identifiers back to Ringleader. Ringleader turns them into a CloudAccount and a CloudIdentity that place your workstations. You never operate Ringleader’s control plane yourself.

Pick your cloud

• Google Cloud: a Terraform module or a gcloud shell script. Two predefined Compute roles scoped to one project, and a workload identity pool that trusts Ringleader’s issuer for your organization only. No static key.
• Microsoft Azure: a Terraform module or the Azure CLI. A custom least-privilege role (narrower than the built-in Contributor) scoped to one resource group, and a federated identity credential trusting the same claims. No static key.
• AWS: a Terraform module or CloudFormation. An IAM OIDC identity provider and a least-privilege IAM role scoped to one account (optionally one region), assumed keyless with AssumeRoleWithWebIdentity. No access key.

Then read per-organization federation for how the trust works end to end, what Ringleader does with the identifiers you hand back, and how to migrate an account that is already onboarded.

The shared model

Every onboarding grants Ringleader a scoped identity inside one billing/RBAC boundary and nothing else:

Nothing you hand back is a secret. A service-account email, a workload identity provider’s resource name, an application client id, a tenant id — all public identifiers. Naming a principal grants nothing; the authority is the short-lived token Ringleader signs, whose subject your trust configuration pins to your organization.

Workstations hold no cloud identity by default. The VMs Ringleader boots have no attached service account or managed identity unless an administrator explicitly declares a runtime identity on a CloudIdentity. Without that, nothing inside a workstation can act as any cloud principal — and enabling it is an opt-in on the onboarding assets, because it costs real permissions in your account.

The assets

The onboarding assets are published, parameterized, and meant to be run as-is:

github.com/ringleader-dev/cloud-onboarding

gcp/      terraform/      (a reusable module + a standalone example)
          gcloud/         (idempotent shell scripts)
azure/    terraform/      (a reusable module + a standalone example)
          arm/            (an ARM template + an az wrapper)
aws/      terraform/      (a reusable module + a standalone example)
          cloudformation/ (a template + an aws-CLI wrapper)

They contain no account ids and no shared state — nothing needs editing beyond the two values Ringleader gives you. Each provider page below is the runbook that walks you through them.

Reaching your workstations

Read this before you design the network. Two different things need two different kinds of connectivity, and conflating them produces a workstation that looks perfectly healthy and that nobody can use:

Ringleader ships no bastion, no proxy, and no SSH tunnel. rl shell dials the address the VM publishes, on port 22. So a workstation with egress but no inbound path finishes setting up perfectly, reports Ready, and cannot be opened by anyone.

That leaves two honest choices, and the assets support both:

• Public and restricted. Give the assets the CIDRs your engineers connect from (ssh_source_ranges). They open port 22 to those ranges and nothing else.
• Private only. Leave ssh_source_ranges empty and reach the subnet over VPN, Interconnect, ExpressRoute, or peering. The workstation still comes up on egress alone.

The clouds differ in their default, which is worth knowing before you are surprised by it:

• Google Cloud gives a workstation an external IP unless you opt out (providerConfig.gcp.assignPublicIp: false). It is still unreachable until a firewall rule allows 22 — a custom VPC has none.
• AWS also gives a workstation a public IP unless you opt out (providerConfig.aws.assignPublicIp: false), so the internet gateway alone gives egress — no NAT gateway. It is still unreachable until a security-group rule allows 22.
• Azure gives a workstation no public IP unless you opt in (providerConfig.azure.publicIp: true). Such a workstation needs the NAT gateway for egress, or it cannot reach the gateway at all and never finishes setting up.

What Ringleader gives you, and what you return

Ringleader provides up front: its issuer URL and your organization id. Those two values are all the trust configuration in your cloud needs.

You return after applying: the identity you created (service-account email / app client id), how to reach the trust you created (the workload identity provider resource name / your tenant id), the boundary (project / subscription + resource group), and your subnet.

Each provider page has the full runbook, verification, and revocation steps.

• Google CloudGrant Ringleader least-privilege, keyless access to run workstation VMs in one of your GCP projects, with Terraform or the gcloud CLI.
• Microsoft AzureGrant Ringleader a custom least-privilege role to run workstation VMs in one of your Azure resource groups, keyless, with Terraform or an ARM template.
• AWSGrant Ringleader least-privilege, keyless access to run workstation EC2 instances in your AWS account, with Terraform or CloudFormation.
• Per-organization federationHow Ringleader authenticates to your cloud with a signed, organization-scoped token instead of a shared identity or a stored key — and the end-to-end onboarding flow.