-
Notifications
You must be signed in to change notification settings - Fork 7
Cloud Prerequisites
Two things have to be true before you run deploy.sh, and redStackPRO cannot
do either for you (see Concepts, the export is the boundary):
- Your cloud identity can create the resources the export builds. VPCs or networks, subnets, security groups or firewall rules, instances, and elastic or static IPs, at minimum.
- Your machine has the tools the deploy script needs. Terraform, plus ssh, tar, and Python, none of which redStackPRO installs.
This page covers AWS and GCP, the two providers tested end to end. Azure,
Proxmox, and ESXi are on the roadmap, not yet supported; see Providers
for their status. Quota planning (Elastic IPs, vCPUs, the GCP
CPUS_ALL_REGIONS cap) is covered there too; this page is about identity
permissions and local tooling, not capacity.
| Always |
terraform, ssh, tar, and Python 3.8 or newer |
| Never (installs itself) | Ansible: the deploy installs it on the jumpbox over ssh, nothing to add on your machine |
Of these, ssh and tar ship with Git for Windows and come stock on
macOS and Linux; you install Terraform and a real Python 3.8+ yourself
(see Getting Started). Once all four are present the deploy runs the
same way on all three. On Windows, run .\deploy.ps1 rather
than bash deploy.sh at a PowerShell prompt: PowerShell's bash resolves to
the WSL launcher, a different filesystem with a different home directory and
different cloud credentials. deploy.ps1 finds Git Bash
(C:\Program Files\Git\bin\bash.exe or your user-scope install) and calls it
directly. If Git for Windows is not installed, deploy.ps1 says so and
points at https://git-scm.com/download/win.
The deploy also looks for a working Python at python3, python, or py,
in that order, and runs a quick check rather than trusting PATH: on
Windows, the Microsoft Store's python3 stub is on PATH by default and
merely prints an advert, so a plain command -v check would pass and then
fail on the first real use. Install a real Python 3.8+ if none of the three
runs.
Neither provider's Terraform module creates an IAM role or service account
for the export's own use (the one exception is auto_stop, on AWS only, see
below). The permissions your identity needs map directly to the resource
types the modules create.
The AWS modules create:
-
aws_vpc,aws_internet_gateway,aws_subnet,aws_route_table,aws_route_table_association,aws_route -
aws_nat_gatewayandaws_eip(one per network that needs NAT, one per host that takes a public address: the jumpbox, and on the attack side, the redirector) -
aws_security_groupandaws_vpc_security_group_ingress_rule(one group per host) -
aws_instance, plus theaws_amidata source used to resolve the image -
aws_key_pair(one per export, from yourssh_public_key) -
aws_vpc_peering_connectionandaws_route(when a topology peers two networks, for example redStack's attack side reaching into a range)
Simple path: attach the AmazonEC2FullAccess managed policy to the IAM
user or role you configure with aws configure. It covers every resource
type above.
Scoping a custom policy: grant ec2:* (or the narrower set of
Create/Describe/Delete/Modify actions for VPCs, subnets, route
tables, internet gateways, NAT gateways, security groups, security group
rules, instances, key pairs, Elastic IPs, and VPC peering connections) on the
account and region you deploy into.
The one exception, auto_stop. If a topology sets a daily auto-stop
time, the export also creates aws_iam_role, aws_iam_role_policy, and
aws_scheduler_schedule (an EventBridge Scheduler schedule that stops the
range's instances on a cron). That needs iam:CreateRole,
iam:PutRolePolicy, iam:PassRole, and scheduler:CreateSchedule in
addition to the EC2 permissions above. This is deliberately the export's
only IAM-touching resource; an identity that cannot create roles fails the
apply here, by name, rather than partway through something broader. If your
account restricts IAM role creation, drop auto_stop from the topology and
the apply needs nothing beyond EC2.
The GCP modules create:
-
google_compute_network,google_compute_subnetwork -
google_compute_routerandgoogle_compute_router_nat(one pair per network segment that needs NAT) -
google_compute_address(a reserved static IP for the jumpbox, and for a redirector on the attack side) google_compute_instance-
google_compute_firewall(one set per segment, plus intra-segment rules) -
google_compute_network_peering(when a topology peers two networks) -
google_compute_resource_policy, GCP's own auto-stop schedule, when a topology sets one. Unlike AWS this is a Compute Engine resource, not an IAM one, so it needs no extra role.
All of the above are Compute Engine resources. Grant your account
roles/compute.admin on the project. The instance resource does not
attach a service account to the VMs it creates (no service_account block
in the module), so roles/iam.serviceAccountUser is not required for a
stock deploy; only add it if you customize the topology to attach a service
account yourself.
Enable the Compute Engine API before the first apply:
gcloud services enable compute.googleapis.com --project <project-id>
The export touches no other GCP API: no Cloud DNS, no IAM API calls beyond
what compute.admin already covers. A redirector's DNS record is something
you create at your own registrar, not a GCP resource; see
Deploying a Range.
GCP caps running Compute Engine vCPUs per project, not per region, under
CPUS_ALL_REGIONS (default 32). A topology with enough hosts can exceed
this well before any single-region or machine-type limit does, which makes
it the real ceiling on how large a topology you can deploy without asking
for more. Check and raise it under IAM & Admin > Quotas in the console,
filtered to the Compute Engine API, before a large deploy. See Providers
for the full GCP quota table (external IPs, project/billing setup) and the
AWS equivalent (Elastic IPs, vCPUs, the Kali Marketplace subscription).
If you do not already have the AWS CLI, install it from the official per-OS instructions: https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html
Then configure it:
aws configure
This prompts for an access key ID, a secret access key, a default region,
and a default output format, and writes them to ~/.aws/credentials and
~/.aws/config (C:\Users\<you>\.aws\ on Windows). Confirm it worked:
aws sts get-caller-identity
That should print your account id and the IAM identity you just configured.
Terraform reads the same standard AWS credential chain the CLI does
(environment variables, then ~/.aws/credentials), so nothing further is
needed for terraform apply to pick up what aws configure just wrote. See
the full precedence order:
https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html
If you do not already have it, install the gcloud CLI from the official per-OS instructions: https://cloud.google.com/sdk/docs/install
Then run both of these:
gcloud auth login
gcloud auth application-default login
Both matter, and only the first is obvious when it lapses. gcloud auth login signs in the CLI itself; gcloud auth application-default login
writes Application Default Credentials (ADC), a separate credential file
that Terraform's Google provider (and the generated deploy.sh) actually
reads. deploy.sh checks for ADC before it applies anything and stops with
a one-line fix (gcloud auth login && gcloud auth application-default login) if it is missing, rather than a raw Terraform authentication error.
See the ADC docs:
https://cloud.google.com/docs/authentication/provide-credentials-adc
Point the CLI at the right project:
gcloud config set project <project-id>
If you do not have a project yet, or need to enable billing on one, see
Providers for the gcloud projects create / gcloud billing projects link commands.
Only AWS and GCP are tested end to end, and the permission guidance above covers only those two. Azure, Proxmox, and ESXi are on the roadmap, not yet supported; Proxmox and ESXi additionally cannot allocate a public address on their own. See Providers for current status before planning a deploy on any of the three.