HTTP, TCP, and SSH Service Publishing

Unified service publishing platforms abstract the complexities of Layer 4 and Layer 7 routing, enabling secure exposure of diverse protocols through a single control plane.

On this page

Modern infrastructure encompasses a highly heterogeneous mix of communication protocols, ranging from stateless REST APIs and gRPC streams to stateful database connections and interactive shell sessions. Managing distinct ingress controllers, load balancers, and firewall rules for each protocol introduces severe operational fragmentation. A unified service publishing architecture abstracts these underlying transport mechanics, allowing operators to expose HTTP, raw TCP, and SSH services through a singular, policy-driven control plane.

Abstracting the Transport Layer

Historically, publishing an internal web application required configuring a Layer 7 reverse proxy, while exposing a backend database required setting up a separate Layer 4 TCP load balancer. This bifurcation forces operations teams to maintain disparate configuration languages, distinct TLS certificate lifecycles, and fragmented access control lists. A unified publishing platform consolidates these functions into a single ingress fabric. Administrators simply declare the desired public endpoint and the internal target, and the control plane automatically provisions the appropriate routing logic, whether that requires deep packet inspection or raw byte forwarding.

This abstraction drastically accelerates the deployment of new services. Development teams can expose a temporary staging environment, a raw TCP game server, or an internal SSH bastion using the exact same API and declarative manifests. The underlying ingress fabric dynamically allocates the necessary edge resources, ensuring consistent security policies and observability across all published endpoints, regardless of the underlying wire protocol.

Layer 7 Inspection vs Layer 4 Passthrough

While a unified control plane simplifies management, the data plane must still respect the distinct requirements of different OSI layers. For HTTP and gRPC traffic, the edge gateway operates at Layer 7. It terminates the TLS connection, parses the headers, enforces Web Application Firewall (WAF) rules, and can inject identity context before routing the request to the backend. This deep inspection is critical for protecting web applications from injection attacks and cross-site scripting.

Conversely, raw TCP and SSH services require Layer 4 passthrough. Attempting to parse SSH handshakes or proprietary binary database protocols at Layer 7 introduces unacceptable latency and risks breaking the protocol state machine. For these services, the edge gateway acts as a high-performance stream proxy, terminating the external TLS (or passing it through entirely via SNI routing) and blindly forwarding the decrypted TCP stream to the internal target. The unified platform intelligently selects the appropriate processing pipeline based on the declared service type.

Unified Policy Enforcement

Despite the differences in data plane processing, the control plane enforces a unified policy model across all published services. Whether a user is accessing an HTTP dashboard or initiating an SSH session, the edge gateway evaluates the same contextual signals: device posture, geographic origin, and identity provider claims. This ensures that the principle of least privilege is applied consistently. If a user’s device is flagged as compromised, the control plane instantly revokes their access to both the web portal and the underlying database TCP port, eliminating the security gaps that often occur when Layer 4 and Layer 7 access controls are managed in silos.

# HAProxy configuration demonstrating mixed HTTP and TCP frontend routing
# The unified ingress controller handles both Layer 7 and Layer 4 traffic

frontend unified_edge_ingress
    bind *:443 ssl crt /etc/ssl/srrrs-edge.pem alpn h2,http/1.1
    bind *:2222 # Raw TCP port for SSH tunneling

    # Layer 7 Routing for HTTP/gRPC
    acl is_http req.proto_http
    use_backend http_web_cluster if is_http

    # Layer 4 Routing for SSH based on destination port
    acl is_ssh dst_port 2222
    use_backend tcp_ssh_bastion if is_ssh

backend http_web_cluster
    mode http
    option forwardfor
    # Inject identity headers verified by the edge control plane
    http-request set-header X-SRRRS-User %[req.hdr(X-Edge-User)]
    server web01 10.0.1.50:8080 check
    server web02 10.0.1.51:8080 check

backend tcp_ssh_bastion
    mode tcp
    option tcplog
    # Raw TCP passthrough to the internal SSH daemon
    server bastion01 10.0.2.10:22 check send-proxy-v2

Summary

Unified service publishing eliminates the operational friction of managing fragmented ingress architectures for diverse protocols. By abstracting Layer 7 inspection and Layer 4 passthrough behind a single, policy-driven control plane, organizations can securely expose any internal service with consistent identity enforcement and observability. SRRRS provides a comprehensive publishing fabric that dynamically routes HTTP, TCP, and SSH traffic, ensuring that your entire application portfolio is protected by a cohesive zero-trust perimeter.