How Do You Keep a Cyber Range Isolated From Production?

Keep a cyber range isolated by separating its exercise workloads, administrative authority, identities and data-transfer paths from production, then testing the intended boundaries under the privileges participants actually receive. A separate subnet is only one part of that design. A shared host folder, production credential or powerful orchestration account can create a consequential path that a network diagram omits.

I would define the exercise's permitted effects before selecting its platform. Participants may need to compromise a deliberately vulnerable service, alter its configuration or investigate synthetic incident evidence. None of those learning objectives automatically requires access to a real business system. The engineering task is to reproduce the relevant behavior while keeping the resulting authority and effects inside the approved environment.

This paper develops a proposed containment assessment using twelve authoritative technical sources checked on October 29, 2026. Its path model, acceptance matrix and fictional example are original synthesis; the method has not been empirically validated. No live range, production system or malicious payload was tested. The aim is a defensible account of what the range permits, what blocks prohibited effects, and what remains outside the evidence.

Define the permitted failure before choosing the boundary

A cyber range deliberately creates conditions that ordinary production hardening would remove. It may contain vulnerable applications, weak exercise credentials or opportunities to change a guest system. Those conditions are not necessarily design defects. The important distinction is between the component participants are allowed to affect and the components that enforce containment around it.

NIST's technical testing guidance emphasizes planning assessment objectives, selecting techniques with attention to operational risk, and establishing rules of engagement. Those rules define authorized testing activities and constraints (Scarfone et al., 2008, §6 and Appendix B). For a range, I would translate that into an explicit statement of allowed targets, privileges, techniques, destinations and stop conditions before any practical session begins.

Specify the strongest capability the scenario intentionally grants. A learner allowed to administer a guest can change controls inside that guest. A learner allowed to deploy arbitrary containers can influence a different part of the platform. An instructor controlling the host occupies another trust position entirely. “Students only use the lab” is not a useful security assumption until those permissions are described.

Then decide what must remain unaffected: production data and services, other learners' environments, the management platform, outside organizations and the resources needed to stop the exercise. A scenario can be contained with respect to production but still disrupt every learner through shared infrastructure. Record those as separate objectives rather than treating one isolation label as an answer to all of them.

Model effects across channels, not only packets

I propose representing the range as a graph of components and permitted interactions. Components include exercise guests, hosts, controllers, identity providers, artifact stores and external services. Edges represent specific capabilities: network access, file read or write, credential use, administrative changes, resource consumption and artifact transfer. A diagram containing only IP routes misses several of the ways an exercise can affect something outside itself.

For each exercise capability, trace paths toward a protected component. A prohibited path needs an effective restriction somewhere along it. The restriction must remain outside the authority granted by that scenario. If participants can remove the only firewall rule that supposedly contains their guest, the diagram has described a convention rather than an enforced boundary.

This resembles a graph cut, but I would not present it as a mathematical proof of security. The graph is incomplete if it omits a host-sharing mechanism, inherited role or control-plane connection. Unknown vulnerabilities can undermine a modeled boundary. Its practical value is exposing the assumptions that a test or configuration review can challenge, not certifying that every conceivable path has been enumerated.

Channel	Example boundary question	Evidence to seek
Network	Where can exercise traffic go?	Routes, enforcement and authorized path tests
Identity	Which real services accept exercise credentials?	Trust configuration and bounded authorization checks
Host and control	Can a workload change its containment?	Effective permissions and management separation
Files and artifacts	What can cross through shared storage?	Mounts, transfer workflow and destination permissions
Capacity	Can an exercise exhaust shared resources?	Limits and bounded resource observations
Lifecycle	What authority survives reset or teardown?	Credential, storage and controller-state reconciliation

A virtual network needs explicit enforcement and observation

NIST SP 800-125B examines virtual-network segmentation, firewall placement, path redundancy and traffic monitoring as distinct configuration concerns (Chandramouli, 2016). That distinction matters in a range. Creating a separate virtual switch or address space may change topology without, by itself, establishing every required restriction on routed or shared access.

I would document the intended communications in both directions. Which exercise components can reach one another? Which may reach a controlled update service? What can contact the management interface? Which paths are prohibited? The answers should identify enforcement points and administrators, not merely colors on a diagram. A protected production destination must not become an implicitly allowed exception because it supplies a convenient service.

Treat supporting infrastructure as part of the design. Name resolution, time synchronization, package retrieval and telemetry can each require communication beyond an exercise subnet. Sometimes they can be provided locally; sometimes a bounded intermediary is appropriate. The choice depends on the learning objective and threat assumptions. Any remaining connection needs a purpose, an authorized recipient and a way to observe that its actual use fits the purpose.

Avoid using access to real production as the default containment test. A controlled destination representing the prohibited class can test a particular rule without touching an unrelated system. Configuration inspection provides additional evidence about actual protected routes. Where an actual production-side check is necessary, it requires its own explicit authorization and bounded procedure; permission to operate a training range is not that authorization.

Network-policy objects are not evidence of enforcement

Kubernetes documents that NetworkPolicy depends on a supporting network implementation. It also identifies limitations, including implementation-dependent behavior for host-networked Pods and protocol scope that does not cover every possible packet type uniformly (Kubernetes, n.d.-b). A policy accepted by the API is therefore not sufficient evidence that the intended traffic restriction is active in the relevant configuration.

For a range using Kubernetes, the acceptance record should name the network implementation, policy scope and workload modes under review. Separate ingress from egress. Determine whether participants can change labels, policy objects or workload settings that influence selection and enforcement. The boundary must be evaluated under their effective permissions rather than only under the instructor's intended manifest.

A useful negative test attempts an authorized, harmless interaction with a controlled destination that the selected workload should not reach. A positive control verifies that the destination is functioning and that a permitted interaction succeeds through an appropriate path. Otherwise a timeout might reflect an unavailable destination rather than a successful security restriction. Record the protocol, identity, configuration and observation point.

These tests remain bounded. One denied TCP connection does not establish that every protocol, workload mode or newly created resource is contained. Select cases according to the actual architecture, including how new workloads receive their restrictions. When a platform mode lies outside the verified scope, either constrain its use or supply another justified boundary. Do not silently extend the meaning of the successful test.

Match the execution boundary to the exercise's trust model

NIST's container-security guide explains that containers share a host kernel and discusses the associated isolation and host-security risks. It distinguishes that shared operating-system boundary from hypervisor-based separation (Souppaya et al., 2017, §§2.2, 3.5). The relevant conclusion is not that containers are categorically unsuitable. It is that their isolation properties must fit the privileges and behavior the scenario permits.

A tightly controlled application exercise differs from an exercise whose objective includes manipulating operating-system internals. For the latter, placing the deliberately affected component on a host that also supports valuable production workloads would require a much stronger argument. I would prefer a design in which the component expected to fail has no valuable co-resident production dependency. The exact platform choice still requires current implementation review.

Kubernetes' multi-tenancy guidance treats isolation as a spectrum and discusses cases where dedicated clusters, and potentially dedicated hardware, may be appropriate for stronger separation (Kubernetes, n.d.-a). A namespace name does not establish which point on that spectrum a deployment occupies. Review the shared control plane, nodes, storage and permissions rather than asking the namespace label to carry the assurance claim.

Dedicated infrastructure also has limits. An administrator can connect it to an inappropriate network, reuse a production credential or import a sensitive artifact. Physical or virtual separation does not make those decisions disappear. The stronger boundary should reduce the consequences of the exercise's intended behavior while still receiving configuration, identity and lifecycle review.

Keep management authority outside the exercise

NIST SP 800-125 recommends restricting hypervisor management access and disabling unnecessary guest-to-host facilities such as clipboard or file sharing. Its discussion also treats management channels as assets needing protection (Scarfone et al., 2011, §4.1). These are particularly relevant when guests are intentionally vulnerable or participants receive administrative access inside them.

Separate the instructor's exercise controls from the platform's containment controls. A scenario may let an instructor start, pause or reset a guest without giving that instructor the same authority to alter production connectivity. Similarly, a learner's ability to create a lab machine should not silently include authority to change shared firewall policy or attach privileged infrastructure. Review the permissions actually granted by the provisioning interface.

The management session itself is another path to inspect. A workstation used to administer both environments can carry files, credentials and active sessions across the boundary even when the workload network is restricted. Decide which administrative contexts may coexist and how artifacts are transferred. The assessment should identify such crossings without assuming that an endpoint's location alone makes every action safe.

Preserve an independent means of stopping exercise effects. A stop control inside a guest that participants can disable is not sufficient for a scenario that assumes guest compromise. The authorized operator needs a platform-level action whose scope and consequences are understood. That may involve suspending workloads, withdrawing permitted communications or stopping a job; the chosen action must be tested for the environment rather than described as a universal kill switch.

Separate cloud authority as well as cloud networks

AWS describes using separate accounts to apply different controls to production and non-production environments and to limit the scope of adverse events (Amazon Web Services [AWS], n.d.-a). For a cloud-hosted range, account separation can support a clearer ownership and policy boundary. It does not independently prove that cross-account roles, resource policies or shared services cannot connect the environments.

I would review the authority issued to each exercise principal. What may it create, read, modify or assume? Which systems accept it? Can a controller grant broader access than the learner appears to hold initially? A role named “training” is descriptive metadata; its effective authority is the security fact. The range's provisioning process needs the same review as its interactive accounts.

AWS IAM guidance recommends temporary credentials, least-privilege permissions and review of unused access (AWS, n.d.-b). Those practices support a range design, but short lifetime is not a substitute for narrow scope. A brief credential can still carry consequential production authority during its validity. Credentials issued for the exercise should be accepted only for their intended tasks and resources.

At the end of a session, reconcile issuance and surviving authority. Removing a learner from a front-end interface may not demonstrate the state of every credential or delegated resource created during the exercise. Define the intended closure condition and verify it through the responsible identity and service controls. This is a proposed lifecycle requirement, not a claim that every cloud provider uses the same revocation mechanism.

Treat shared files as active boundary crossings

Docker's bind-mount documentation states that host paths mounted into containers are writable by default and explains that container processes can consequently modify host files. It also documents read-only mount options (Docker, n.d.-a). A range container with restricted networking can therefore still have a significant path into its host through storage.

List each shared path and the purpose of the sharing. Distinguish incoming exercise material, learner output, platform configuration and host-private files. Read-only access can prevent an intended write path while still exposing information that should not be available to the workload. The decision must address both confidentiality and integrity, not just whether the exercise can modify the file.

Use a deliberate transfer stage for artifacts that must leave the range. Identify who approves the transfer, what processing occurs, where the result goes and which receiving tools will open it. A report, archive or document may contain more than the visible text needed for grading. Treat exported artifacts as untrusted input to the receiving workflow until the applicable checks have completed.

Dataset selection is a separate privacy and engineering decision. A range should not inherit real datasets merely because they make a scenario look convincing. Synthetic records and controlled services can reproduce many required relationships without importing the original organization's confidential information or valid access material.

No network interface does not mean no external effect

Docker's none network driver creates only a loopback interface within the container (Docker, n.d.-b). That can be useful for an exercise that does not require network interaction. The claim is about the configured networking stack; it does not describe host mounts, control-plane permissions, shared resources or files an operator later exports.

This distinction prevents a common category error in assurance. A disconnected workload may still write a mounted directory, influence a co-resident service through resource pressure, or produce an artifact that is later processed elsewhere. Those are different channels in the path model. Closing one channel should narrow the remaining analysis rather than prematurely end it.

For exercises that do require outside-like behavior, consider a local simulator or controlled service that supplies the necessary responses. Record what is simulated and what is real. A learner investigating a synthetic exchange can demonstrate a bounded skill, but the result should not be presented as evidence that every live-service condition has been reproduced. Fidelity should follow the learning objective, not the visual complexity of the range.

An approved external connection remains possible when the task genuinely requires it. It needs a narrowly described destination, purpose, available authority and withdrawal condition. Prefer an arrangement whose effects can be observed and constrained independently of the exercise guest. The existence of an exception should appear in the acceptance statement rather than disappearing behind the word “isolated.”

Availability is part of containment

Docker documents that containers have no resource constraints by default beyond what the host's scheduler permits, and provides controls for memory and CPU use (Docker, n.d.-c). Consequently, a separate container identifier does not establish that a runaway exercise cannot consume resources needed by other workloads. Inspect the actual limits and the host's remaining capacity.

A range needs an explicit capacity budget for exercise work, platform control and observation. If monitoring and the stop mechanism depend on the same exhausted resources, the operator may lose visibility when it is most needed. Consider whether those functions require reserved or independently provisioned capacity. The appropriate design depends on the expected load and the scenarios authorized for the range.

Do not test this by generating uncontrolled load. Use a bounded exercise with agreed ceilings, duration, observation and termination conditions on authorized infrastructure. Check whether the configured limits take effect and whether the management path remains usable. A successful low-load demonstration does not establish behavior under every possible exhaustion condition; document the tested envelope.

Separate availability findings from learner performance. An infrastructure failure can make a competent learner appear unable to complete the task, or conceal the behavior being assessed. The curriculum competence paper explains that assessment problem. Here the range owner must make the environmental failure visible and decide whether the session can continue safely and fairly.

Reset is a state-reconciliation problem

NIST SP 800-125 notes that images and snapshots can contain sensitive information, including data retained in memory, and require protection against unauthorized access or change (Scarfone et al., 2011, §3.3). A snapshot is therefore both a recovery mechanism and an artifact with its own exposure implications. Its existence does not establish that every external effect of an exercise will be reversed.

Before relying on reset, list the state outside the guest: attached storage, accounts, issued credentials, controller records, external messages, exported artifacts and shared-service changes where applicable. Determine which state the reset operation actually restores and which needs a separate action. A participant's virtual disk returning to its starting point says little about an object that was created in another service.

Protect the baseline as well as the disposable instance. If a learner can modify the template used for subsequent sessions, the next cohort may inherit the previous exercise's state. Use a controlled source for baseline artifacts and verify the intended version when provisioning. The acceptance record should distinguish a trusted baseline claim from a convenient image name.

After teardown, reconcile what should remain for assessment and what should no longer grant access or execute work. Retain necessary evidence with appropriate access and retention decisions; remove or disable other state through the authorized lifecycle process. The security telemetry privacy analysis addresses the related collection and reuse decisions. Exercise logs sent to a central service need that review too. No universal retention period is proposed here. The point is to avoid treating deletion of the visible guest as proof that the entire exercise has ended.

Test containment as an exercise in its own right

NIST SP 800-84 describes functional-exercise roles including controllers, data collectors and simulators, with responsibilities distinct from participants (Grance et al., 2006, §5.2.5). That separation is useful for a containment acceptance exercise. Someone must observe and control the test without depending on the behavior of the workload whose restrictions are being evaluated.

Start with a configuration review of the selected range version, then test representative allowed and prohibited paths. Use harmless markers, controlled destinations and synthetic accounts. Record the source privilege, intended action, enforcement point, expected outcome and actual observation. Include positive controls so a failed interaction is not mistaken for isolation when the destination or test mechanism was broken.

Challenge a small number of consequential assumptions: a guest administrator changes an in-guest setting; a permitted workload is reprovisioned; an approved transfer path receives an unexpected artifact type; a bounded resource limit is reached; or the ordinary exercise interface becomes unavailable. These are test designs to adapt and authorize, not instructions to attack an uncontrolled host. The purpose is to see whether containment still depends on an assumption the scenario intentionally violates.

A passing result should name its scope: the selected privileges, paths, platform version and test conditions. Keep unsupported paths and untested exceptions visible. Where the evidence does not justify the intended exercise, reduce its privileges, remove the exception, choose a different execution boundary or postpone that scenario. A limited but enforceable training environment is more useful than an ambitious one whose containment cannot be explained.

A fictional range reveals an overlooked file path

Consider fictional Rowanbridge, which plans a learner exercise involving administrative access to deliberately vulnerable guests. The proposed workload network cannot route to production, and the team intends to describe the range as isolated. All details here are hypothetical; no actual organization, learner or deployment is being described.

The path review finds a writable host directory shared into the guests for collecting exercise reports. The same host runs a production-support task that reads configuration from a neighboring shared location. The relevant concern is the actual mount scope and receiving process, not a guessed exploit. The team must determine whether the granted file authority crosses the intended boundary before accepting the design.

Rowanbridge replaces broad sharing with a controlled output transfer stage and separates the exercise host from production-support duties. It also checks whether the provisioning identity can grant cross-environment access and whether the baseline can be modified from an exercise session. These are distinct decisions; fixing the file path does not establish the identity or baseline controls.

A bounded acceptance exercise then uses a harmless marker to verify the approved output path and a controlled prohibited destination to evaluate the selected network restriction. The team records whether the platform stop action remains available under a small, capped resource test. Any untested recovery or external-service path stays outside the completion claim. This scenario illustrates the proposed reasoning; it does not supply observed pass results or a guarantee against escape.

Realism, cost and the limits of assurance

The strongest objection is that strict separation can make a range less realistic and more expensive. That deserves an engineering answer. Identify which relationships the learner must experience and which merely reproduce organizational convenience. A controlled identity service or simulated external dependency may preserve the required decision while avoiding unnecessary production authority. Some advanced exercises may require dedicated infrastructure that a small program cannot operate responsibly.

In that case, change the exercise or use an appropriately governed provider rather than stretching an unsupported assurance claim. A tabletop, prerecorded evidence set and practical isolated task demonstrate different capabilities. They can be combined, provided the assessment describes what each actually establishes. Containment requirements should not be traded away simply to make a demonstration look more authentic.

The evidence base is normative and implementation-specific. It supports documented boundary properties and operational practices, not a measured probability of range escape. Older NIST guidance is used for architectural principles; current product behavior still requires version-specific review. This method cannot prove absence of unknown vulnerabilities or compensate for undisclosed administrative connections. Testing samples behavior, while configuration review exposes additional assumptions; neither is exhaustive.

I would accept a range for a stated scenario when the required paths work, prohibited effects are constrained by controls outside participant authority, and the remaining limitations are explicit. That is a decision about a defined exercise and environment. It is not a permanent claim that everything labeled “lab” is safe.

Request a cyber-range containment assessment to review those boundaries before expanding your practical program. The work can connect learning objectives to permitted privileges, map the overlooked identity and artifact paths, and produce an acceptance exercise with clear stop conditions. That gives instructors room to teach challenging material while making the operating limits understandable to the people responsible for production.