Skip to content
vWorld
Menu
  • Main Page
  • About
  • Study Guide
    • VCAP-CMA Deploy 2018
Menu

The One-Time Secret: Securely Delivering VM Passwords to Customers

Posted on June 10, 2025June 10, 2025 by admin

Introduction

When provisioning a new Virtual Machine (VM) for a customer, one of the final, critical steps is delivering the initial access credentials. This moment is fraught with security risks: passwords sent over email, pasted in chat, or left in ticketing systems can be intercepted or accidentally exposed, compromising the security of the new machine before the customer even logs in.

This article outlines a secure, automated, and elegant solution.

The Solution: An Automated, Self-Destructing Web Page

Imagine this workflow: during the VM deployment process, your automation platform generates a strong, random password for the machine. As soon as the VM is ready, a post-deployment action instantly spins up a simple, secure web page accessible via a unique link. This page has one job: to display the password that was just created for the customer.

The server is configured to self-destruct after a set time or after the first access, ensuring the password is only exposed for the brief moment it’s needed.

How It Works: The Technical Workflow

This mechanism is implemented using a lightweight Docker container. A workflow, orchestrated by a tool like vRealize Orchestrator (vRO), receives the pre-generated password and executes a command on a designated Docker host.

Here is a breakdown of the core command structure:

# Step 1: Ensure the network exists. If not, create it.
docker network inspect mybridge >/dev/null 2>&1 || docker network create mybridge

# Step 2: Run the container, mapping its port 80.
docker run -d --rm -p 80 --network mybridge -e PASSWORD="SuperSecret123" nginx sh -c "echo '<html>...PASSWORD_PLACEHOLDER...</html>' > /usr/share/nginx/html/index.html && sed -i \"s/PASSWORD_PLACEHOLDER/\\$PASSWORD/\" /usr/share/nginx/html/index.html && nginx && timeout 300 sh -c 'while ! grep -q \"GET /\" /var/log/nginx/access.log; do sleep 1; done' && nginx -s stop"
  • docker network inspect ... || docker network create ...: This command first checks if a network named mybridge exists. If the inspect command fails (meaning the network doesn’t exist), the || (OR) operator runs the docker network create mybridge command. This ensures the container always has a network to connect to.
  • docker run -d --rm: Runs a container in the background (-d) and automatically removes it (--rm) as soon as it stops.
  • -p 80: Exposes port 80 of the container directly. The password page will be available via the Docker host’s port 80.
  • -e PASSWORD="...": Securely passes the generated password into the container as an environment variable.
  • nginx: Specifies the image to use.
  • sh -c "...": Executes a series of shell commands inside the container, which implement the page creation and self-destruct logic.

Automating the Workflow with vRealize Orchestrator (vRO)

We’ll use vRO’s SSH plugin to remotely execute the Docker command. The workflow:

  1. Builds a Docker run command that exposes port 80 (no dynamic host port mapping).
  2. Injects the password into the container’s web page.
  3. Serves the page via Nginx.
  4. Automatically stops and removes the container after a set timeout or after the page is accessed.

Prerequisites

  • The SSH plugin is installed and configured in vRO.
  • vRO can reach the Docker host over the network.
  • The SSH user on the Docker host has permissions to run Docker commands (docker group).
  • The Docker network (e.g., mybridge) exists or is created automatically.

Step-by-Step vRO Workflow

1. Create Workflow Inputs

NameTypeDescriptionExample Value
sshHoststringDocker host IP or FQDN192.168.1.100
sshUsernamestringSSH usernamedocker-user
sshPasswordSecureStringSSH password (use SecureString)(your SSH password)
networkNamestringDocker network namemybridge
secretPasswordSecureStringPassword to shareSecret123
imageNamestringDocker image name (default: nginx)nginx
timeoutSecondsnumberTime before auto-stop (in seconds)300

2. Add and Configure a Scriptable Task

Define an output variable:

  • Name: commandToRun
  • Type: string
// Build Docker network check command
var networkCheckCmd = 'docker network inspect ' + networkName +
    ' >/dev/null 2>&1 || docker network create ' + networkName;

// Build Docker run command as before
var command = 'docker run -d --rm -p 80 --network ' + networkName;
command += ' -e PASSWORD="' + secretPassword + '"';
command += ' ' + imageName;

var part1 = "echo '<html><body><h1>Your password is: PASSWORD_PLACEHOLDER</h1></body></html>' > /usr/share/nginx/html/index.html";
var part2 = 'sed -i \\"s/PASSWORD_PLACEHOLDER/\\$PASSWORD/\\" /usr/share/nginx/html/index.html';
var part3 = 'nginx';
var part4 = "timeout " + timeoutSeconds + " sh -c 'while ! grep -q \\\"GET /\\\" /var/log/nginx/access.log; do sleep 1; done'";
var part5 = 'nginx -s stop';

var shellScript = [part1, part2, part3, part4, part5].join(" && ");
var runContainerCmd = command + ' sh -c "' + shellScript + '"';

// Final SSH command: ensure network, then run container
var commandToRun = networkCheckCmd + '; ' + runContainerCmd;

System.log("Final SSH command: " + commandToRun);

3. Execute the SSH Command

  • Add the Run SSH Command element.
  • Map the inputs:
    • hostName → sshHost
    • username → sshUsername
    • password → sshPassword
    • command → commandToRun

4. Validate and Execute

  • Save and validate the workflow.
  • Run it, providing the required inputs.
  • The container starts and serves the password at http://<DOCKER_HOST_IP> with random port
  • After the first access or timeout, it self-destructs.

After collecting password

Security Considerations

  • Minimal Exposure: Password is exposed only for a short, controlled time.
  • Environment Variables: While convenient, environment variables can be inspected in some cases. For even higher security, look into Docker Secrets or external secret managers.
  • Auditability: All actions are logged in vRO.
  • HTTPS: For production, consider serving the page over HTTPS.

This approach provides an automated, auditable, and secure way to deliver initial access credentials to your customers, minimizing the risk of accidental credential leaks during VM provisioning.

Share with:


Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Recent Posts

  • From Commit to Cluster: Mastering GitOps with Argo CD on VMware Cloud Foundation
  • The Full Power of VCF Automation in Action: How I Connect the Dots and Build a Multi-Tier App with Kubernetes Objects.
  • From Code to Kubernetes Cluster with Chiselled Ubuntu Images on VMware
  • From Zero to Database-as-a-Service: A Deep Dive into VMware Data Services Manager 9.0 and VCF Automation
  • Complete Guide: Configuring SSO in VMware Cloud Foundation with Active Directory and VCF Automation Integration

Archives

Follow Me!

Follow Me on TwitterFollow Me on LinkedIn

GIT

  • GITHub – vWorld GITHub – vWorld 0
© 2026 vWorld | Powered by Superbs Personal Blog theme