Infrastructure Management Dashboard

Admin Account

This account has full access to all dashboard features. Leave password blank to keep the current password.

What is this instance for?

This decides which features the instance offers. The two are mutually exclusive, because they disagree about where BeyondTrust tenant configuration lives.

A POV instance is deliberately narrow.

The cloud credential steps are skipped and nothing is written for them. Demo features — on-premises hypervisors, cloud databases, Kubernetes, containers, virtual desktops, cost reporting — stay unavailable on this instance whatever their toggles say. Run a second instance, with its own database, for those.

AWS Credentials

Used to deploy EC2 instances. Create a dedicated IAM user with a customer-managed policy — see Part A of docs/ONBOARDING.md, as the AWS-managed policies do not grant enough (read-only S3 cannot write Terraform state) — then generate an access key.

Name (or ARN) of an AWS Secrets Manager secret containing a JSON object with a public_key field. Call it anything you like — paste the name here and the dashboard will use it for every EC2 deployment.

The IAM instance profile — its name or ARN, not the role name — attached to every deployed EC2 instance for AWS Systems Manager (SSM) access. In IAM open your role and copy the Instance profile ARN; the name is the part after instance-profile/ (e.g. role ec2-ssm-role → profile ec2-ssm-instance-profile). Required for the cloud-native AWS Systems Manager Password Safe onboarding; leave blank if you are not using SSM. The role needs the AmazonSSMManagedInstanceCore policy.

Required if you launch BeyondTrust Gateway containers in ECS. Stored encrypted in the dashboard DB and resolved through whichever secrets backend you select on the /secrets page.

Spin up an isolated, disposable AWS lab tenant on your own machine — where your aws login already works — then paste the values it prints into the fields above. It runs on your laptop, not in this container, so it uses your existing cloud login.

From a clone of the dashboard repo, with the AWS CLI logged in:

aws login                                   # or: aws configure
./scripts/sandbox/Linux/setup-aws.sh        # Windows: .\scripts\sandbox\Windows\Setup-AwsSandbox.ps1

Provisions an isolated VPC, a scoped IAM user, and an SSH-key secret, then prints an aws_* config block to paste here. Tear it down later with rollback.sh --cloud aws. Full walkthrough in docs/ONBOARDING.md (Quick path: cloud sandbox).

See IAM access keys docs for setup instructions.

Azure Credentials

Used to deploy Azure VMs. Create a service principal with Contributor rights: 

az ad sp create-for-rbac --name dashboard-dev --role Contributor --scopes /subscriptions/<sub-id>

Leave blank if everything lives in the same resource group and you don't use a Shared Image Gallery or Key Vault.

The resource group that contains your VNets and NSGs. Leave blank to use the VM RG above.

Shared Image Gallery (private images tab)

Key Vault — SSH key retrieval

The service principal above needs Key Vault Secrets User role on this vault.

Key Vault secret containing JSON with public_key (used for VM deploys) and private_key (used by Ansible) fields.

Container Registry — ACI Ansible / Gateway pulls (optional)

Configure if you mirror the Ansible runner or BeyondTrust Gateway images in your own registry (e.g. to bypass Docker Hub rate limits). Credentials are stored encrypted in the dashboard DB and resolved through whichever secrets backend you select on the /secrets page.

Leave blank to pull all images from public Docker Hub without authentication.

Required if you launch BeyondTrust Gateway containers in ACI. Stored encrypted in the dashboard DB and resolved through whichever secrets backend you select on the /secrets page.

Requires a separate Entra app registration (not the service principal above). Grant delegated permissions: openid profile email User.Read. Leave blank to disable.

The redirect URI is auto-configured to {your-host}/api/auth/oauth/azure/callback — add this in the app registration → Authentication.

Spin up an isolated, disposable Azure lab tenant on your own machine — where your az login already works — then paste the values it prints into the fields above. It runs on your laptop, not in this container, so it uses your existing cloud login.

From a clone of the dashboard repo, with the Azure CLI logged in:

az login
./scripts/sandbox/Linux/setup-azure.sh      # Windows: .\scripts\sandbox\Windows\Setup-AzureSandbox.ps1

Provisions a resource group, VNet, a scoped service principal, and a Key Vault, then prints an azure_* config block to paste here. Tear it down later with rollback.sh --cloud azure. Full walkthrough in docs/ONBOARDING.md (Quick path: cloud sandbox).

Google Cloud Credentials

Used to deploy Compute Engine instances. Create a service account with the Compute Admin and Secret Manager Secret Accessor roles, then download a JSON key: 

gcloud iam service-accounts create dashboard-sa --display-name "Dashboard SA"
gcloud projects add-iam-policy-binding <PROJECT_ID> \
  --member "serviceAccount:dashboard-sa@<PROJECT_ID>.iam.gserviceaccount.com" \
  --role "roles/compute.admin"
gcloud iam service-accounts keys create sa-key.json \
  --iam-account "dashboard-sa@<PROJECT_ID>.iam.gserviceaccount.com"

Paste the full JSON key file (sa-key.json). It is stored encrypted in the dashboard database.

Name of a GCP Secret Manager secret containing a JSON object with a public_key field (or raw public key). Used for every Compute Engine deployment.

Cloud-NAT subnet the cloud-database tunnel Gateway lands in (it needs egress to reach PRA, unlike the default VM subnet). Emitted by setup-gcp.sh as gcp_jumpoint_subnetwork; falls back to the default subnetwork if blank.

The deploy key the GCE COS Gateway container registers with. Stored encrypted in the dashboard DB and resolved through whichever secrets backend you select on the /secrets page. Consumed when provisioning the GCP cloud-database tunnel Gateway.

Spin up an isolated, disposable GCP lab project on your own machine — where your gcloud login already works — then paste the values it prints into the fields above. It runs on your laptop, not in this container, so it uses your existing cloud login.

From a clone of the dashboard repo, with gcloud logged in:

gcloud auth login
./scripts/sandbox/Linux/setup-gcp.sh        # Windows: .\scripts\sandbox\Windows\Setup-GcpSandbox.ps1

Provisions a VPC, a scoped service account, and a Secret Manager secret, then prints a gcp_* config block to paste here. Tear it down later with rollback.sh --cloud gcp. Full walkthrough in docs/ONBOARDING.md (Quick path: cloud sandbox).

Oracle Cloud (OCI) Credentials

Optional — used to deploy OCI compute (Always-Free by default). Uses API-key signing. In the OCI console under Identity → Users → your user → API Keys, add a key and copy the shown tenancy/user OCIDs + fingerprint; paste the matching private-key PEM below. All fields may be left blank to skip OCI.

Stored encrypted in the dashboard database.

Feature Flags

Enable optional integrations. All default to off — turn on only what you have infrastructure for.

Credentials are encrypted with AES-256 and stored in the application database.