VDI Authentication with SPIFFE/SPIRE

Architecture for workload identity and mutual TLS authentication in Frontier Workspace VDI, replacing password-based connections with SPIFFE/SPIRE-issued X.509 certificates.

VDI authentication with SPIFFE/SPIRE

Frontier Workspace VDI authentication is moving from password-based RDP connections managed by the connection broker to workload identity with mutual TLS, issued and rotated by SPIFFE/SPIRE. This page describes the architecture in three phases: user authentication, workload identity provisioning, and the authenticated connection itself.

Why this matters

In the current architecture, the connection broker stores a random password per workspace in its internal database. When a user connects, that password is sent over the RDP connection to authenticate the session. The password is a static secret that exists for the lifetime of the workspace, sits in a database that must be protected, and can be replayed if intercepted.

SPIFFE/SPIRE removes the password entirely. Both the workspace VM and the connection broker are issued X.509 certificates signed by a trust authority. Each side presents its certificate during the connection handshake; each side verifies the other against a shared trust bundle. There is no password to steal, no password to rotate manually, no shared secret that needs to be protected at rest. Certificates rotate automatically on a one-hour cadence, and revoking a workspace’s identity is a single SPIRE registration delete.

This is the kind of identity architecture federal customers require for IL5 and IL6 deployments, and it is straightforward to operate at IL2 once the SPIRE control plane is in place.

Architecture

The full authentication flow runs in three phases.

Phase 1 — user authentication

User authentication is unchanged from the current architecture. The user signs in to the OutpostAI operator interface, which redirects through OIDC to the Keycloak identity provider. Keycloak issues a token containing the user’s subject identifier and realm roles. This token authenticates the user to the platform; it does not authenticate the workspace VM or the connection broker.

User identity and workload identity are separate concerns. The user proves who they are with OIDC; the workloads prove what they are with SPIFFE.

Phase 2 — workload identity provisioning

When a workspace VM is provisioned, a SPIRE agent runs on the VM and performs node attestation against the SPIRE server using cloud infrastructure metadata. The SPIRE server validates the attestation and issues a workload SVID — a short-lived X.509 certificate with a SPIFFE URI identifying the workspace, of the form spiffe://frontier.local/vdi/workspace/<user>. The certificate is injected into the VM’s TLS configuration and used by the in-VM RDP service.

A second SPIRE agent runs on the connection broker pod. It performs node attestation against the SPIRE server using Kubernetes pod identity. The SPIRE server validates and issues a separate workload SVID identifying the broker, of the form spiffe://frontier.local/guacamole. The certificate is available to the broker for outbound mTLS connections to workspace VMs.

Both certificates have a one-hour time-to-live and rotate automatically. Revoking a workspace’s identity is a single delete operation against the SPIRE registration database.

Phase 3 — authenticated connection

When the user clicks Connect on a workspace tile, the operator interface signals the platform’s workspace orchestrator. The orchestrator fetches the trust bundle for the SPIFFE namespace from the SPIRE server. The trust bundle contains the certificate authorities that signed the workspace and broker SVIDs.

The orchestrator instructs the connection broker to establish an mTLS connection to the workspace VM. The handshake proceeds as two sequential one-way exchanges:

  1. The broker presents its SVID to the VM. The VM’s SPIRE agent verifies the SVID against the trust bundle. If the certificate is signed by a trusted authority and identifies the expected broker, the VM accepts the connection attempt.
  2. The VM presents its SVID to the broker. The broker verifies the SVID is for the workspace it was instructed to connect to. If the SPIFFE URI matches the expected workspace, the broker establishes the session.

With both sides verified, the RDP session is established and the desktop streams to the user’s browser. No password is exchanged at any point in the flow.

Integration approach

The connection broker (Apache Guacamole) does not natively support SPIFFE workload identity or mTLS for RDP connections. The recommended integration uses an Envoy sidecar proxy deployed alongside the broker:

  • Envoy sidecar — runs next to the Guacamole pod and terminates mTLS using the SPIFFE Workload API. Guacamole connects to localhost:3389; Envoy handles the certificate exchange with the VM. Envoy has first-class SPIFFE support.
  • SPIRE Agent on the VM — baked into the VDI golden image. Performs node attestation at boot, receives the workspace SVID, and configures XRDP for TLS client certificate verification.
  • SPIRE Server on the management cluster — issues and rotates all SVIDs. Registration entries define which workloads receive which identities.

This approach requires no changes to Guacamole itself. The mTLS termination is handled entirely by the sidecar and the VM-side SPIRE agent.

Operational benefits

The shift from password-based to SPIFFE-based authentication has several operational consequences worth naming.

No password database to protect. The current connection broker’s password store is a high-value target. With SPIFFE, the equivalent secret material is X.509 private keys held in memory on each workload, never persisted to a shared database. The attack surface for credential theft is materially reduced.

Automatic rotation. Certificates rotate every hour without operator intervention. A compromised certificate has at most one hour of utility before it expires naturally. Manual password rotation — which most operators either skip or do too infrequently — is replaced by automatic rotation as a property of the architecture.

Identity revocation is fast. Removing a workspace’s access is a single SPIRE registration delete. The workspace VM’s next certificate renewal fails, and the workspace cannot complete future handshakes. There is no “but did we revoke the password in every system” question.

Audit trail is identity-aware. Every mTLS handshake produces logs keyed to specific SPIFFE URIs. Auditing which workspace connected to which broker, when, and how long — questions that were previously inferred from broker logs — become directly queryable from the identity infrastructure.

Federal classification compatibility. SPIFFE/SPIRE is the identity mechanism most federal authorities-to-operate increasingly expect for workload identity at IL5 and IL6. Adopting it at IL2 means the architecture transfers cleanly to higher classifications without re-engineering.

What is unchanged

The user-facing experience does not change. The user signs in to the operator interface, picks a workspace from a catalog, clicks Connect, and lands in their desktop. The platform handles workload identity beneath the user-visible surface. Existing OIDC integrations, user roles, and access controls operate as before.

The change is in the substrate, not in the experience.