Deploying a Range

Deploying a Range

You deploy the export from your own machine, under your own credentials. redStackPRO is not in the loop once you press Download.

Caution

Deploying creates real, billed resources in your own cloud account: VMs, storage, a public IP or two, and the rest. Nothing in this pipeline stops the clock for you. Tear the range down when you are done (see Teardown below), and check your cloud console if a build ever fails partway through.

Check AWS quotas first (per region)

On AWS, scope your quotas for the target region before the first apply. A compile does not check them, and a shortfall surfaces mid-apply, after instances are up, leaving partial infrastructure to destroy. Each item is per region, so a new region means re-checking.

• Elastic IPs: the default is 5 per region. A defense/AD range uses about 2, an offense range about 3, so the default holds only one or two concurrent ranges. Request an increase in advance.
• vCPUs: a large AD range (for example full GOAD plus a SIEM) can exceed the default running On-Demand vCPU limit. Raise it before large deploys.
• Kali: a Kali operator needs a one-time Marketplace subscription on the account, per region. redStackPRO touches no account, so you subscribe once per region.
• Key pair name: it is region-global and defaults to <prefix>-key, so keep the topology prefix unique per range to avoid a collision.

See Providers for the quota table and the increase commands.

Make an SSH key

An SSH key pair is two matching files: a private half you keep and a public half you can hand out. The deploy authenticates to the hosts with the private half, and the public half is written into each host at creation, so make the pair before the first apply.

Run this from the export's root folder, the one holding deploy.sh and keys/ (the command below creates keys/id_ed25519 and keys/id_ed25519.pub there):

macOS, Linux, or Git Bash on Windows:

ssh-keygen -t ed25519 -f keys/id_ed25519 -N ""

Windows PowerShell (the quoting differs):

ssh-keygen -t ed25519 -f keys\id_ed25519 -N ''

keys/ sits beside the export's README. Already have a key? Point at it with REDSTACKPRO_SSH_KEY=/path/to/key.

Fill in the variables

terraform.tfvars is a plain text file, one setting per line as name = "value" (or name = ["value"] for a list). Open export/terraform/terraform.tfvars and set:

• ssh_public_key: the single line from keys/id_ed25519.pub.

• operator_source_ranges: the addresses you connect from, each as a /32. A CIDR like 203.0.113.7/32 means exactly that one address; find yours with curl ifconfig.me or by searching "what is my ip".

  [!CAUTION] The shipped default is ["0.0.0.0/0"], meaning anyone on the internet. This variable gates management access (SSH, RDP, the Guacamole portal) next to a deliberately vulnerable range, so narrow it to your own /32 (or your team's known ranges) before you apply. Leaving it open is the single easiest way to hand your range to someone else.

• region (AWS) or project and region (GCP), plus any topology-specific inputs the briefing names. A region is the cloud's data center location (for example us-east-1 on AWS, us-east4 on GCP); pick one close to you or your target. A GCP project is the billing and resource container every GCP resource lives in; if you do not have one yet, see Providers for how to create one and enable billing.

Authenticate to your cloud first: aws configure, then aws sts get-caller-identity, or gcloud auth application-default login.

Run the deploy

Windows PowerShell, from the export folder:

.\deploy.ps1

macOS, Linux, or Git Bash:

bash deploy.sh

On Windows, do not run bash deploy.sh at a PowerShell prompt: that bash is the WSL launcher. WSL (Windows Subsystem for Linux) runs a separate Linux environment with its own filesystem, home directory, and credentials, so the deploy would run somewhere your SSH key and cloud login are not. deploy.ps1 finds Git Bash and calls it correctly.

deploy.sh applies the Terraform, then provisions from the range's own jumpbox. The managed hosts sit on a private subnet nothing else can reach, so provisioning runs from inside the range rather than from your laptop. Your cloud credentials stay on your machine throughout.

RANGE-BRIEFING.md in the export lists the credentials and what is planted where.

Redirectors need a real domain

A redirector is the one host that answers to the internet by name. A domain has to be registered and pointed at the box by a human, and nothing can invent one. Any shipped example that carries a redirector arrives one field short on purpose, and the validator says so with RDR001.

Supply a domain you control, either in the canvas inspector before you compile, or on the command line:

redstackpro compile <template> --hostname your-domain.example -o export

After apply, create the A record the briefing names, pointing your subdomain at the redirector's address. A DNS A record is the entry that maps a domain name to an IPv4 address; you create it in your domain registrar's or DNS provider's control panel (wherever you manage the domain), not anywhere in redStackPRO. See Redirectors and Cover Stories.

Teardown

Teardown is a Terraform command, not a button in the canvas or a script the export generates for you. Ranges are meant to be stood up, used, and torn down, so nothing keeps costing money after the work is done. From the export root (the folder holding deploy.sh):

terraform -chdir=terraform destroy

This is the same -chdir=terraform invocation deploy.sh uses for apply, run in reverse. Confirm the plan it shows before approving it.

Note

Flag for review: RANGE-BRIEFING.md does not currently print this command; it covers access, credentials, and the planted attack surface, not teardown. Until a teardown.sh (or an explicit mention in the briefing) ships, this page is the place to look. If you deployed redStack (attack infrastructure) and a range as separate exports, each has its own terraform/ state and needs its own destroy.

Providers

GCP and AWS are tested end to end. Azure is a preview backend (public addressing works, private DNS and peering do not yet). See Providers for the full matrix and the setup notes for each.