BeyondTrust Customer tenants

Dashboard POV Templates Storage Use cases Inventory Jobs Schedules Agents Health Audit Secrets RBAC
Settings
POV

Storage

Active:

Cloud object storage for the dashboard's playbooks, scripts, and other assets. Configure one or more backends; pick one as active. Use the Migrate tab to copy assets between backends — the source is preserved so you can verify before deleting.

Backend

The active backend is what new uploads write to, what features (such as Ansible) read from, and where Terraform state for provisioned resources is now kept. Backends with required fields filled in will show configured; the active one is highlighted.

Expand a backend to set its connection details. You can configure several (for a migration target or the image hub) without making them active.

Credentials come from the OCI setup wizard — only the bucket is set here. Can host the image-registry hub, but cannot be the active backend: the active backend also decides where Terraform state lives, and Terraform has no OCI state backend.

Either a path inside the dashboard container (typically a bind-mounted host directory) or a UNC share like \\fileserver\share\playbooks. UNC reads go through the SMB protocol — no host-side mount needed. Username / password / domain are only used for UNC.

The same kind of target as the backend above, reached by a remote agent instead of by this container — so it works when the dashboard is hosted in a cloud with no route to your file server, and it has no ansible_runner=local constraint. The path is not configured here. It lives in that agent's own shares.yaml alongside its policy.yaml grants the share by name, and the dashboard never holds either. The SMB password can stay there too, or the dashboard can hold it (below) and hand it to the agent sealed, per job. Files move inside a signed job envelope, so playbooks and scripts work and packages (.rpm, .deb, .msi) are too large.

Name in the agent's shares.yaml.

A directory inside the share. Relative only — leave blank for its root.

Used only when the share's entry in shares.yaml says dashboard_secret: true (agent 2.7+); the username stays there. Delivered sealed to each job, and only to SPIRE-attested agents when Remote Agents requires that.

Runs a real job on the agent — expect this to take a few seconds, not to be instant.

Terraform state

The active backend above also stores the Terraform state for everything you provision (VMs, cloud databases, EKS). State is written under a fixed terraform-state/ prefix at the bucket / container root — this is separate from the asset Key / Blob / Object Prefix and is not affected by it. Keeping state on a cloud backend means it survives container recreates. Switching the active backend while live state exists will prompt you to migrate that state to the new backend (the old copy is kept as a backup).

Heads up: with no cloud backend active, Terraform state stays on the container's ephemeral deploy disk and is lost if the container is recreated. Select a cloud backend (S3, Azure Blob, or GCS) above to keep state safe. A filesystem backend — including one reached through an agent — does not hold state; only assets.

Image-registry hub

The single backend that holds the canonical VHD/raw artefact for every registered image. Leave on Same as active backend for single-backend installs — only change this if you want the image hub to live on a different cloud than your day-to-day uploads.

BeyondTrust EPM-L packages

Pull the EPM for Linux agent packages from BeyondTrust into this backend. Once here they're ordinary assets: installable at image-build time from the Install EPM-L option on the AWS / Azure / GCP build pages, or by a config-management playbook. No active backend selected. Choose one on the Backend tab first.

Build status:

BeyondTrust has no built packages yet — use Build packages, then check again. A build takes a few minutes.

Upload an asset

Pick a playbook, script or installer — it goes straight into the active backend and becomes available on /config-mgmt for runs against your VMs and cloud instances. No active backend selected. Choose one on the Backend tab before uploading.

Ready:
Uploading part of — of

Maximum upload for : — . Anything over is sent in parts automatically — there is nothing to switch on.

Allowed types: .yml .yaml .sh .ps1 .rpm .deb .exe .msi. Scripts and packages are auto-wrapped in a generated playbook at run time; .ps1, .exe and .msi target Windows hosts (the host's Ansible inventory must set ansible_connection=winrm). A Windows installer is how a POV's Password Safe Resource Broker bootstrapper is staged — it comes from your own tenant, so the dashboard cannot fetch it for you.

Stored assets

Showing assets across every configured backend. Use Move to relocate a playbook from the local filesystem to a cloud backend so the cloud-side Ansible runner can fetch it. Tick rows and click Delete N selected to clean up multiple assets in one shot.

No assets yet. Upload a playbook or script using the form above.
Name Backend Type Size Actions

Move asset

Move from to:

The asset is copied first, then deleted from the source. If the copy succeeds but the delete fails, the asset will exist on both backends and you'll be asked to clean up the source manually.

Migrate between backends

Copy every asset from a source backend to a target backend. The source is preserved — verify the target is healthy, then delete from the source manually if you want a clean cutover. Files already present in the target are skipped unless you tick Overwrite existing.

Copied ()
Skipped ()
Failed ()