Cloud Onboarding | Ringleader Docs

Your developers’ workstations can run as VMs in your own cloud account, on your bill and inside your network, so the machines your code and secrets live on stay in an account you control. This section sets that up for Google Cloud, Azure or AWS.

The work on your side is one Terraform apply, or one script, run in a project, resource group or account you own. It creates an account for Ringleader to sign in as. That account may create, start, stop and delete workstation VMs and connect them to your network, and nothing else. It also tells your cloud to accept Ringleader’s sign-in without a password or a key. When it finishes, it prints a few values; you send those to Ringleader, and from then on your developers create and delete workstations themselves.

Pick your cloud

Google Cloud: Terraform or gcloud scripts. Creates a service account with three roles in one project.
Microsoft Azure: Terraform or an ARM template. Creates an Entra app with a custom role in one resource group.
AWS: Terraform or CloudFormation. Creates an IAM role with a narrow policy in one account.

Each page lists exactly what it creates, what to run, what to send back, and how to check and revoke it. How Ringleader signs in to your cloud explains why no key changes hands, and how to move an account that was onboarded the old way.

What Ringleader gets, cloud by cloud

	Google Cloud	Microsoft Azure	AWS
Where Ringleader may act	one project	one resource group	one account, optionally one region
What Ringleader signs in as	a service account	an Entra app	an IAM role
What it may do	create, start, stop and delete workstation VMs, connect them to your network, and (on by default) keep files in storage it names	the same	the same
What it never gets	Owner or Editor	Contributor	account admin; its only IAM permission is a narrow `iam:PassRole`

On all three clouds Ringleader signs in with a short-lived token that your cloud checks, and there is no password or key anywhere.

Nothing you send back is a secret. A service-account email, a role name, an app id and a tenant id are all public identifiers, and knowing them grants nothing. What lets Ringleader in is what you set up during onboarding, which accepts tokens for your organization alone.

Can the software on a workstation touch your cloud? On AWS and Azure, no: a workstation has no cloud identity of its own unless an administrator gives it one, so nothing running on it, including an AI coding agent, can reach anything in your account. On Google Cloud every VM runs as some service account, and the default one is often broadly privileged; the Google Cloud page says how to check and how to narrow it.

What you run

Everything you run is public, at github.com/ringleader-dev/cloud-onboarding: a Terraform module for each cloud, plus a gcloud script, an ARM template, or a CloudFormation stack for teams that do not use Terraform. Nothing in it is specific to Ringleader’s account or to any other customer. You fill in the two values Ringleader gave you, your own project or account, and the addresses your engineers connect from. See the cloud-specific onboarding pages for detailed walkthroughs.

Reaching your workstations

Read this before you design the network. A workstation needs two connections, and they are set up separately:

	Needs	Provided by
Coming up, meaning it finishes setup and reports `Ready`	a way out, from the VM to Ringleader	a public address, or a NAT gateway
Being used: `rl shell`, `rl tmux`, port-forwards, VS Code Web	a way in, on TCP 22, from wherever you run `rl`	a firewall rule Ringleader writes, one of your own, or private connectivity

The first comes with the network the module creates. For the second, Ringleader writes a firewall rule for every workstation it creates. The rule admits SSH (TCP ports 22 and 2222) from any address. Writing it needs the egress control grant, which is on by default. Workstations take a public address by default on all three clouds, so with nothing else set, a workstation accepts SSH connections from the internet. Only people Ringleader has given access to the workstation can sign in.

Decide which of these you want:

Reachable from your addresses only: after onboarding, list the addresses your engineers connect from in sshSourceRanges on the CloudAccount. Ringleader’s rule then admits only those, for every workstation, including ones created later.
Private only: set allowPublicAddresses: false on the CloudAccount, so no new workstation takes a public address. Reach the workstations over your VPN, Interconnect, ExpressRoute or peering.
Reachable from anywhere: change nothing.

The module and the scripts also write an SSH rule of their own. It admits the addresses your engineers connect from (ssh_source_ranges, or the equivalent for your cloud’s script). It covers TCP 22, and on AWS and Azure TCP 2222 as well. It applies alongside Ringleader’s rule, so it can let more addresses in, never fewer. The exception is Azure, where a workstation with no egress policy accepts SSH only from the addresses Ringleader’s rule allows. This rule keeps workstations reachable when Ringleader cannot write its own, for example with egress control turned off. Such a workstation still finishes setting up and reports Ready, and it also reports the SSHAdmissionMissing condition.

What the way out costs differs by cloud. Each cloud page has a section on it.

Restricting where workstations may connect

The section above is about what a workstation needs to reach. The other half is what it is allowed to reach: by default, anything your network can. A workstation can instead be given an egress policy, a list of the addresses and hostnames it may connect to, so it can reach GitHub and your package registry and nothing else. Ringleader turns that list into your cloud’s own firewall rules, outside the machine, where nothing running on it can undo them.

To do that, Ringleader needs permission to create and maintain those rules, which the base setup does not include. That is the enable_egress_control / EGRESS_CONTROL switch, on by default on every cloud. The same permission lets Ringleader write the rule that admits SSH to your workstations, described above, so with it turned off they are reachable only through a rule of your own. A workstation with no egress policy still has no limit on where it connects. Each cloud page lists the exact permissions it adds.

How the rules are enforced, and the one thing on each cloud that can undo them, is different on each cloud, and each cloud page has a section on it. On AWS there is one step of your own: a workstation with a policy has to be given a particular security group, and the AWS page says which.

Restricting by hostname rather than by address needs a small proxy VM in your own account, an Edge, which a namespace administrator declares once per cloud and region. Each module reserves an empty subnet for it (create_gateway_subnet, on by default); the subnet itself costs nothing.

One more grant is on by default on all three clouds: artifact storage. It lets Ringleader store files for your organization in a bucket or storage account in your own cloud account, instead of in Ringleader’s own storage. Granting it writes nothing: Ringleader stores files there only once your organization is set up to use it. Each cloud page says what it grants and how to turn it off.

What Ringleader gives you, and what you send back

Ringleader gives you two values up front: its issuer URL and your organization id. Those two are all your cloud needs to recognize Ringleader’s tokens as yours.

You send back, after applying: the identity you created (a service-account email, an app id or a role ARN), where Ringleader should present its token (a workload identity provider name or a tenant id), which project, resource group or account the workstations live in, and which subnet. Each cloud page has the exact list, and both the module and the scripts print it when they finish.