Identity enforced before access
Users authenticate through Cloudflare Access before reaching the Guacamole application. Cloudflare becomes the first control point and primary external kill switch.
SECURITY ARCHITECTURE CASE STUDY
Zero Trust Remote Access Platform
A self-hosted remote access platform that uses Cloudflare Access, Cloudflare Tunnel, Apache Guacamole, Docker, PostgreSQL, and segmented Proxmox lab networks to provide browser-based SSH and RDP access without exposing inbound management ports to the public internet.
PROBLEM
Remote administration needed identity-aware access without exposing management services.
The lab needed a reliable way to administer internal systems from outside the home network. Exposing SSH, RDP, Proxmox management, or other administrative services directly to the internet would increase risk and create unnecessary attack surface. A traditional VPN could provide connectivity, but it would also create broader network trust than needed for browser-based operational access.
The goal was to build an access path that enforced identity before application access, kept management services internal, supported both SSH and RDP workflows, and remained recoverable after outages or host restarts.
ARCHITECTURE
Identity at the edge, brokered access inside.
flowchart LR
U[User Browser] --> A[Cloudflare Access]
A --> P[Allow Policy]
P --> T[Cloudflare Tunnel]
T --> G[Guacamole]
G --> B[Bastion]
B --> I[Internal Systems]
No exposed management ports
SSH, RDP, and administrative services remain internal. Cloudflare Tunnel maintains an outbound-only connection to the edge instead of requiring inbound firewall openings.
SECURITY CONTROLS
The platform uses layered access controls instead of a single trust boundary.
Cloudflare Access
External access is gated by an identity-aware policy layer using SSO, MFA, explicit allow rules, and default-deny behavior.
Cloudflare Tunnel
The access path is established through an outbound tunnel, avoiding direct inbound exposure of SSH, RDP, or virtualization management interfaces.
Apache Guacamole
Guacamole acts as a browser-based broker for SSH and RDP sessions, keeping users from directly touching internal service ports.
Endpoint authentication
Internal systems still require native authentication after the user passes Cloudflare and Guacamole access checks.
OPERATING MODEL
Access was designed as an operational workflow, not just a tunnel.
User lifecycle
Access can be granted or revoked at the Cloudflare policy layer and separately managed inside Guacamole for application-level authorization.
Segmented administration
The bastion and internal targets sit behind the access broker, keeping administrative workflows separated from direct public exposure.
Recovery-first thinking
Restart behavior, service dependencies, container state, tunnel status, and authentication paths were treated as part of the system design.
Operator usability
Browser-based access reduces client-side setup requirements and makes the lab easier to demonstrate, validate, and operate from different locations.
ENGINEERING CHALLENGES
Most of the work was in making the access path stable and recoverable.
Service recovery
Restarts and outages required checking the tunnel, container state, Guacamole application path, backend database availability, and the relationship between the reverse path and local services.
Access path troubleshooting
Failures were isolated across Cloudflare Access policy, tunnel routing, Guacamole application behavior, Docker networking, and internal target reachability.
Layered authentication
The design separates Cloudflare identity access from Guacamole authorization and final endpoint credentials, reducing reliance on any single access control.
Documentation
Recovery steps, user access workflows, revocation steps, and operating assumptions were captured so the platform could be maintained instead of rediscovered after each issue.
VALIDATION
The platform was validated by testing each layer of the access chain.
External access validation
- Confirm the public hostname resolves through Cloudflare.
- Confirm Cloudflare Access prompts for identity authentication.
- Confirm unauthorized users are denied before application access.
- Confirm authorized users reach the Guacamole application.
Internal access validation
- Confirm Guacamole authentication succeeds for authorized users.
- Confirm SSH or RDP sessions reach intended internal targets.
- Confirm endpoint credentials are still required.
- Confirm management services are not directly exposed inbound.
OUTCOME
The lab gained a safer and more usable remote administration path.
The final design provides identity-aware remote access without exposing management ports directly to the internet. It also creates a stronger operating model for demos, administration, recovery, and future lab expansion because the access path is documented, layered, and designed around explicit trust boundaries.
Security improvement
Management access is brokered through Cloudflare Access and Guacamole instead of being exposed directly through public inbound firewall rules.
Operational improvement
The platform supports repeatable remote administration and easier lab demonstrations from a browser-based workflow.
LESSONS LEARNED
Zero Trust access is only useful if the recovery path is understood.
Default deny must be intentional
The access model works best when every access path is explicitly documented and unauthorized traffic fails closed by default.
Operations matter as much as architecture
The architecture was not complete until restart behavior, service checks, revocation, and troubleshooting steps were documented.