Introduction: The Vulnerability of Legacy Access Solutions

For decades, traditional Virtual Private Networks (VPNs) and traditional bastion hosts (jump boxes) served as the standard perimeter defense for enterprise cloud infrastructure. However, in modern cloud-native ecosystems, these solutions present critical security liabilities. A standard VPN grants broad network-level access upon authentication, allowing a compromised credential to facilitate lateral movement across an entire subnet. Similarly, traditional SSH jump boxes require exposed public ports and manual, error-prone SSH key management.

To eliminate these risks, organizations are shifting toward a Zero-Trust Network Access (ZTNA) paradigm based on the principle of "never trust, always verify." This guide provides an end-to-end blueprint for building a self-hosted, enterprise-grade, identity-aware Zero-Trust Bastion Host. By coupling HashiCorp Boundary for dynamic proxying and session management with Zitadel as an open-source, GDPR-compliant Identity Provider (IdP) supporting OpenID Connect (OIDC), you can secure your cloud infrastructure without sacrificing data sovereignty or incurring prohibitive licensing costs.

Understanding the Core Architectural Components

Before initiating the deployment, it is vital to understand how the components interact within a Zero-Trust architecture. Unlike legacy setups, users never gain direct network visibility to target resources. Instead, access is mediated through a multi-layered authentication and authorization flow.

HashiCorp Boundary: An open-source, identity-aware proxy that provides secure access to applications and critical infrastructure. Boundary authenticates users via external identity providers, authorizes access based on granular policies, and dynamically establishes temporary, encrypted TCP sessions directly to targets without exposing public ports.
Zitadel SSO: A cloud-native identity management platform that acts as the single source of truth for user identities. Zitadel handles Multi-Factor Authentication (MFA), role-based access control (RBAC), and issues secure OIDC tokens that Boundary validates to verify user identity.
Cloud Server Host: The virtual machine instance (e.g., AWS EC2, Google Cloud Compute Engine, or a general cloud VPS) running Linux that hosts our Boundary controllers/workers and Zitadel containers.

The Zero-Trust Axiom: Identity is the new perimeter. Network location should never dictate access rights; every request must be explicitly authenticated, authorized, and encrypted based on real-time identity context.

Prerequisites and Technical Requirements

To successfully execute this deployment on your cloud server, ensure your environment meets the following baseline requirements:

A cloud server running a modern Linux distribution (Ubuntu 22.04 LTS or Debian 12 recommended) with at least 2 vCPUs and 4GB of RAM.
A fully qualified domain name (FQDN) with access to DNS management (e.g., boundary.yourcompany.com and auth.yourcompany.com).
Docker and Docker Compose installed for container orchestrating Zitadel.
Valid SSL/TLS certificates (Let's Encrypt certificates are ideal for production-grade transport layer encryption).

Step 1: Deploying Zitadel as the Identity Provider

We begin by deploying Zitadel via Docker Compose to establish our Identity Provider. Create a workspace directory and define a docker-compose.yml file configured with a secure PostgreSQL backend or Zitadel's embedded storage.

Once initialization scripts are complete, access the Zitadel Console via your browser. Follow these configurations to prepare for Boundary integration:

Create an Organization: Set up your primary corporate organization workspace within the Zitadel dashboard.
Configure an OIDC Application: Navigate to Projects, create a new project, and add an application. Select Web Application and set the authentication method to Code Flow (Authorization Code).
Set Redirect URIs: Define the authorized redirect URI to allow Boundary to process callbacks. This format follows: [https://boundary.yourcompany.com/v1/auth-methods/oidc:callback](https://boundary.yourcompany.com/v1/auth-methods/oidc:callback).
Extract Credentials: Securely copy the generated Client ID and Client Secret. These parameters are essential for configuring Boundary's authentication mechanism.

Step 2: Installing and Configuring HashiCorp Boundary

With our identity core running, we proceed to install HashiCorp Boundary. Download the official binary from the HashiCorp repository or utilize your distribution's package manager. For a unified, streamlined deployment, Boundary can run in a combined Controller and Worker setup on your host server.

Create a central configuration file, typically located at /etc/boundary.hcl. Within this file, you must define the listener blocks, storage backends, and cryptographic keys:

The Controller Listener dictates how Boundary accepts API and UI traffic. Ensure it is bound to the appropriate network interface and pointed to your TLS certificates. The Worker Listener manages proxy tunnels, utilizing a separate port (typically port 9202) to establish secure connections to downstream targets.

Initialize the Boundary database using the command line initialization flags. This procedure generates an initial recovery token. Save this token securely; it provides absolute administrative control over the cluster if external authentication mechanisms fail.

Step 3: Integrating Zitadel OIDC into HashiCorp Boundary

Now, we bridge the identity provider with our access proxy. Log into the Boundary Admin UI using your recovery credentials, or execute the configurations via the Boundary CLI interface.

Create a new Auth Method within Boundary and select OIDC. Fill in the required metadata fields using parameters gathered during the Zitadel configuration phase:

Issuer: The complete URL of your Zitadel instance (e.g., [https://auth.yourcompany.com](https://auth.yourcompany.com)).
Client ID & Secret: The unique identifiers provided by Zitadel's application dashboard.
Signing Algorithms: Specify RS256 to align with modern cryptographic security standards.
Scopes: Request openid, profile, and email to map user identifiers accurately within Boundary.

To implement true identity-driven governance, set up Managed Groups in Boundary. By mapping Zitadel user roles or group claims directly to Boundary groups, a user granted an "Infrastructure Admin" role within Zitadel automatically inherits corresponding access permissions in Boundary upon their next login session.

Step 4: Defining Infrastructure Targets and Access Control

With authentication established, we must configure our infrastructure directory within Boundary. Boundary organizes resources using a clean, logical hierarchy: Orgs > Projects > Host Catalogs > Host Groups > Hosts > Targets.

Follow this systematic configuration sequence to register your target infrastructure:

Create a Host Catalog: Define a static or dynamic catalog representing a specific cloud network or environment (e.g., Production-VPC).
Define Hosts and Host Groups: Add individual backend server instances by mapping their internal, private cloud IPs (e.g., 10.0.1.45) to host profiles. Group identical servers together to simplify policy management.
Configure Targets: Construct a specific access Target. Set the target type to tcp, assign the relevant port (e.g., port 22 for SSH or port 3389 for RDP), and connect it to your host resources. Set a default maximum session duration to enforce continuous verification.

Step 5: Testing the Zero-Trust Architecture Connection Workflow

To validate the installation, evaluate the architecture from an end-user perspective. The user initiates connection via the Boundary Desktop Client or the Boundary CLI tool:

$ boundary connect ssh -target-id tt_1234567890

Upon triggering the connection command, Boundary prompts the user to authenticate. Instead of asking for an SSH key or localized password, Boundary launches a secure browser window redirecting the request to the Zitadel SSO server. The user enters their corporate credentials and completes the required Multi-Factor Authentication challenge.

Once Zitadel verifies the identity context, it passes a signed OIDC token back to Boundary. Boundary evaluates active access policies, confirms authorization for the specified target, and spins up a localized ephemeral listener loop on the user's machine (e.g., localhost:45931). The local SSH client tunnels securely through this dynamic endpoint, transparently connecting the user to the private cloud server without exposing the backend infrastructure to the open internet.

Conclusion: Elevating Infrastructure Security and Compliance

Deploying a self-hosted Zero-Trust Bastion Host using HashiCorp Boundary and Zitadel SSO completely redefines how your business manages administrative infrastructure access. By eliminating static SSH credentials and sweeping network-level VPN accesses, you mitigate primary vectors for ransomware and unauthorized lateral entry.

Furthermore, this architectural pattern provides deep auditing capabilities. Every session request, token validation, and individual proxy tunnel is centrally logged. Administrators can monitor active sessions in real-time or analyze historical connection logs to simplify regulatory compliance audits (such as SOC2, ISO 27001, or GDPR). Investing in modern ZTNA workflows today ensures your organization's digital assets remain protected against an increasingly sophisticated threat landscape.

Building a Self-Hosted Zero-Trust Bastion Host with HashiCorp Boundary and Zitadel SSO