Hoop.dev Architecture
The architecture solves a few key problems with the existing technologies to address the privileged network access problem.
Existing Solutions and Their Problems
Let's start by discussing existing solutions and their associated problems. The most basic architecture to this problem is using a jump host. A jump host is a device located in an accessible remote environment that is also connected to the private resource needing access. The problem with this approach is that you need to secure this remote server resource. It's accessed by all your endpoints, all the users who need it to jump into the backend resource. Most of the time, you're using basic firewall network rules because that's all you can really do with a plain server.
Dynamic IPs and Firewall Management
One of the biggest challenges is managing firewall rules when most people are working from home on public or home networks with dynamic IPs. The user experience is terrible. Any time a client's IP address changes, you have to update the firewall rules. This often requires manual intervention, either through some sort of automation or by filing a ticket to the ops team. Not only is this inefficient, but it's also very insecure. Old IPs are often left in the firewall rules, which can be picked up by anyone.
User Experience and Overexposure
Another issue is the user experience. In using a jump host, you expose more resources than you intended. For example, once a user gains access to the jump machine, they have access to the entire operating system. This overexposure can lead to unintentional sharing of keys and credentials.
VPN as an Alternative
The second alternative is using a VPN service, which creates a bridge between a client network and a remote network. This approach eliminates the need to manage public firewall rules, but introduces new problems. Now your entire network is exposed to public home networks, making you highly vulnerable. Again, you end up exposing more resources than you intended.
Modern Solutions: Partial Fixes
There are some modern solutions that address 10-20% of these problems, like stronger authentication methods for jump boxes and VPNs. However, these are just partial fixes and don't resolve the core issues.
Our New Architecture
Now let's talk about our solution, which involves re-implementing the entire remote access architecture. We moved away from traditional tools like VPNs and jump servers, which are no longer suitable for modern, complex infrastructures. Instead, we used modern technologies designed for the cloud age, such as HTTP2 and gRPC for fast data transmission and streaming. This approach is far more effective and secure, especially when dealing with the scale and complexity of today's environments.
The New Architecture: Overview
The new architecture addresses the problems we've discussed by fundamentally redesigning how remote access works. Instead of letting external traffic into private networks, we restrict it to outbound traffic only, making it easier to monitor and manage.
Backend Infrastructure: The Lightweight Agent
The first component is a lightweight agent, utilizing gRPC and HTTP2. This agent is deployed in an environment that has connectivity to the private resources you want to expose. It allows only outbound traffic within that private network, eliminating the need for inbound firewall rules. The agent is cloud-native but compatible with any environment, like Kubernetes or an on-premises VM.
Central Gateway: The Control Plane
The second component is the central gateway, which is the only stateful element. It's also cloud-native and adheres to the 12-factor application design. This gateway is where your policies and rules reside. The agent establishes an outbound connection to this gateway, making it the control plane for the architecture.
User Connectivity
Users connect to this central gateway using a specialized client that employs HTTP2 and gRPC streaming. The agents pull this connection into the private network, so there's no inbound traffic.
Layer 7 Proxy: Precision Control
What sets this architecture apart is the implementation of a Layer 7 proxy. This proxy understands the protocols users are interacting with and can alter packets in real-time. This allows for very granular control, exposing only the specific resources you want. You're not just setting rules for networks or endpoints; you're setting rules for specific applications like databases.
Problem-Solving Compared to Traditional Methods
This architecture solves the problems inherent in using jump hosts and VPNs by being incredibly focused. For example, if a user tries to access a database, the Layer 7 proxy can enforce Multi-Factor Authentication (MFA) or block certain queries in real-time. You expose only what you intend to, eliminating the overexposure problem of older solutions.
User Experience and Management
From a user's perspective, the experience is streamlined. They get direct access to the specific resources they need without the clutter of extra resources or APIs. The system also integrates with the user directory for a unified interface.
Maintenance and Monitoring
This architecture is easier to manage than a collection of jump hosts or VPN services. It's designed for modern infrastructures, not patched to fit them. One additional benefit is the use of HTTP2, which integrates with standard monitoring tools you're likely already using.
Summary
To recap, the architecture consists of lightweight agents deployed in private networks, a central gateway for control, and specialized clients for user access. All of these utilize modern technologies like HTTP2 and gRPC. It's not a retrofitted solution but a system designed for today's complex, cloud-native environments.