Two application paths, one named range

The legacy AWS CLI engine creates the network, load balancing, EKS capacity, EC2 utility application, lab storage, IAM simulation and observability resources for a selected scenario. Public paths initially point to a generated portal and API application on EC2.

The optional telecom runtime adds actual Kubernetes workloads for the customer portal, provisioning service and device inventory, plus a deterministic behavior runner. This documented legacy runtime slice covers telecom-provider/easy. The larger catalog remains available through the AWS scenario engine; catalog availability does not mean every scenario has its own Kubernetes runtime.

Review the exact run before creation

bin/vulnvm inspect telecom-provider
bin/vulnvm plan telco -t easy -n telco-easy-1
bin/vulnvm up telco -t easy -n telco-easy-1

Plan describes resource changes without applying them. Check the account, region, tier, operator address and run name before confirming creation. Use -v for raw Terraform output when the compact summary is insufficient.

A run stores its scenario, tier and configuration along with ownership information. This legacy CLI requires one canonical operator IPv4 /32. A stable EKS operator role must be chosen before the first plan. The CLI refuses to change the EKS principal of an existing run that has not been destroyed because that migration can replace the cluster or remove access.

Preserve the state that owns the resources

Local configuration and run records live under .vulnvm/. Each named run has its own owned Terraform workspace and Terraform data directory. New runs bind their identity, generation, reviewed projection, account and stable principal to live Terraform ownership outputs and exact state checkpoints.

These checks help reject operations against a different account or changed state. They do not make the local directory a shared team control plane. The local state example does not establish a shared remote backend boundary. Preserve the directory securely, use one responsible operator for a run and avoid changing its state manually while another operation is in progress.

Prepare an immutable runtime image

The repository includes a pinned release workflow for the telecom image. Its published index includes Linux images for AMD64 and ARM64, build provenance and an SBOM. Obtain the immutable digest reference from the workflow summary.

The GHCR package must be public for the anonymous EKS pull path documented here. Publishing an image does not automatically change package visibility. Confirm that visibility before installation. Mutable tags are not accepted in place of the digest required by the runtime command.

Replace OWNER and RELEASE_DIGEST in the next command with the registry owner and exact digest from your release.

Install and inspect the staged workload

bin/vulnvm kubeconfig -n telco-easy-1
bin/vulnvm runtime install -n telco-easy-1 \
  --image ghcr.io/OWNER/telecom-provider@sha256:RELEASE_DIGEST
bin/vulnvm workloads -n telco-easy-1 -N vulnvm-telecom

Installation configures access, installs the AWS Load Balancer Controller, deploys the telecom workloads and waits for AWS target health. It compiles the selected behavior plan and passes that plan and the generated internal token to Helm through standard input. The local run record retains plan provenance and a digest, not the raw plan or header values.

The EKS target group remains at listener weight zero. Healthy target registration therefore does not mean that public requests have moved to EKS. Public traffic stays on EC2. A traffic cutover is outside this documented installation procedure and requires separate review.

Check the service chain and behavior

Portal readiness checks provisioning, and provisioning checks inventory. The behavior runner has no inbound server and no Service. It continuously requests the portal through a bounded plan, with a normal browsing profile and a separate controlled adversarial profile in the easy scenario.

The runner is Ready only while every configured profile has fresh successful expected responses and all declared flows have completed successfully. A failed flow or stale evidence withdraws readiness. Events and readiness state bind to the loaded plan digest. This is a workload check, not the separate signed provider readiness contract described in the architecture work.

Remove workloads or close the whole run

bin/vulnvm runtime uninstall -n telco-easy-1
bin/vulnvm destroy -n telco-easy-1

Runtime uninstall removes the application and controller but leaves the AWS infrastructure. Destroy performs that cleanup automatically when needed before removing the infrastructure, so a separate uninstall is optional.

Normal cleanup allows target group finalizers to finish while their controller still exists. Reserve --skip-runtime-cleanup for recovery when Kubernetes is unreachable. Afterwards verify account resources independently; Terraform closure is not an AWS residual resource scan. See the cleanup procedure.