Concepts

Concepts

Canvas and topology

The canvas is the surface you work on. The topology is what you build on it: the infrastructure as nodes and edges. The topology is the product; the canvas is a view onto it, and the compiler turns it into deployable code.

Provider vocabulary never appears in the topology. You describe what a thing is and how it connects, not AWS resource types or Proxmox bridges.

Node kinds

A node's kind is what it is: network, segment, teamserver, redirector, collector, jumpbox, operator box. Grouping kinds like network and segment are nodes as well, not a separate container layer, so every edge endpoint is just a node id.

Edges

Edges connect nodes and carry meaning. A fronts edge puts a redirector in front of a teamserver. A logs_to edge sends a host's telemetry to a collector. The compiler derives firewall rules, play ordering, and references from the edges, so a rule exists because an edge does.

Overlays

Overlays are per-node parameters: which C2 on this teamserver, which gating rules on this redirector, which services on this jumpbox. Every overlay field is either user-supplied or derived. User-supplied fields become form inputs on the canvas and tfvars entries in the export. Derived fields become references you never see.

Two modes

A topology has a mode, either offense or defense.

• offense builds attack infrastructure (redirectors, teamservers, operators).
• defense builds a target environment (an Active Directory range and its hosts).

Mode gates the canvas palette and chrome. The compiler treats both the same: one model, one validator, one export shape.

Operator access

An offense stack's jumpbox decides how your team reaches it. The default, access_mode: public, keeps the Guacamole portal (Apache Guacamole, a browser-based remote-desktop gateway) open to the internet, restricted to the CIDRs listed in operator_source_ranges.

Set access_mode to wireguard or openvpn instead and the jumpbox becomes a personal VPN endpoint for each declared operator: apply generates a private WireGuard or OpenVPN credential per handle, on the jumpbox, and the portal moves behind that tunnel rather than sitting on the open internet. SSH stays open on either access mode, because the admin still deploys and manages the box over it.

Every declared operator gets a Guacamole portal account regardless of access mode; the access mode only changes how they reach the portal, not whether they have one. A defense topology ignores operators and access_mode (the validator warns if they are set): a defense range keeps the plain public portal.

See Deploying a Range for the fields, the firewall behavior, and rsp-operator for managing operators on a running jumpbox.

Blueprints

A blueprint is a read-only starting point you clone into your own private copy, not something you edit in place. Cloning one always gives you a private copy to edit; the baseline stays put. There are two kinds. Shipped blueprints (the GOAD family, the redStack stack, and the rest) load from the canvas with Load blueprint. Published blueprints are topologies someone saved and then published to the Library so others can clone them; the Library starts empty until people publish their own. Either way, the blueprint is the starting point and your clone of it is a topology. See Library and Blueprints for the full save, publish, and clone picture.

Cloud terms used here

A few cloud terms come up across this wiki without being defined where they appear. Plain definitions, not exhaustive ones:

• VPC (Virtual Private Cloud): an isolated network inside a cloud account. Every redStackPRO network compiles to one of these.
• Subnet: a slice of a VPC's address range that hosts actually sit in.
• NAT gateway: a managed device that lets hosts with no public address reach the internet outbound (updates, package installs) without being reachable from it.
• Elastic IP (AWS's term; GCP calls it a static external address): a public IPv4 address that stays the same across a stop and restart, rather than changing every time.
• VPC peering: a private network path between two VPCs, so hosts in one can reach hosts in the other without going over the public internet.
• Apply: the Terraform step that actually creates or changes cloud resources to match a plan. terraform apply is what your money starts paying for.
• On-Demand: the cloud's default, pay-as-you-go pricing for a running instance, as opposed to a reserved or spot instance.

The export-only model

redStackPRO generates code and hands it to you. It does not apply Terraform, run Ansible, or reach your cloud. Your credentials stay on your machine.

That boundary has consequences the tool accepts on purpose:

• No deployment status tracking in the canvas
• No destroy button (teardown is a command in the export)
• No drift detection

See Deploying a Range for what you do with the export.

How the export provisions

deploy.sh runs two stages, both kicked off from your own machine:

1. Terraform, locally. terraform apply runs on your machine, under your own cloud credentials, the same as any Terraform project.
2. Ansible, from the jumpbox. The managed hosts, a range's domain controllers and members, an attack stack's teamservers and collectors, sit on a private subnet only the jumpbox can reach. ansible-playbook cannot run against them from your laptop, so deploy.sh:
   • reads the jumpbox's public address and the shared lab password from terraform output, and fills the generated inventory's address placeholders;
   • waits for the jumpbox to accept SSH, then installs screen, python3-pip, and ansible-core (with pypsrp, PySocks, requests) on the jumpbox over SSH, since the export ships no Ansible binary of its own;
   • copies your private SSH key onto the jumpbox, tars the generated ansible/ tree onto it, and runs ansible-galaxy collection install there;
   • launches ansible-playbook ansible/site.yml on the jumpbox itself, inside a detached screen session, so the build keeps going if you disconnect.

The jumpbox's own play connects to itself locally rather than over SSH, because a cloud VM cannot SSH to its own public address. From the jumpbox, a Linux host is then reached by SSH ProxyJump at its private address, and a Windows host is reached directly over WinRM at its private address, since the play is already running inside the private network by the time it gets there.

This means the jumpbox needs its own outbound internet access: apt for screen and python3-pip, PyPI for ansible-core and its dependencies, and galaxy.ansible.com for the Ansible collections the roles need. The compiler does not restrict egress by port, only by whether a segment allows it at all (see Providers); every shipped jumpbox segment allows it.

Your cloud credentials never leave your machine: only the Terraform step touches them. The jumpbox receives an SSH key and the generated playbooks, never your cloud login.