Skip to content

Tri-pod Fan-in Blueprint

This 3-app blueprint improves the speed and simplicity of deploying a HTTP applications in a fan-in or aggregator network pattern (in a single Kubernetes cluster). The small network is secure by design and secure by default. The three pods are deployed with Hopr's Workload Security Proxy (WoSP) - sidecars which provide Zero Trust identity verification and an Automated Moving Target Defense (AMTD).

 The Tri-pod Fan-in  Blueprint Pattern
The Tri-pod Fan-in Bluepint

What the Blueprint Does

The tri-pod fan-in blueprint is a simple HTTP application network of three pods that are 'authrorized by design' to interconnect securely and communicate without the complexity of using PKI or TLS. Pod-1 and Pod-2 are separate intiators (senders) that send their messages to Pod-3 (aggregator). Pods -1 and -2 initiate a new message every 20 seconds in a repeating cycle.

Blueprint Architecture

The blueprint deploys 3 pods in a single cluster. Each pod has 3 containers.

flowchart LR
    subgraph K8s["Kubernetes Cluster"]
        subgraph NS1["Namespace: web-app-1"]
            P1[("Pod-1<br/><b>Sender</b><br/>━━━━━━━<br/>web-app:8000<br/>WoSP IN:18000<br/>WoSP OUT:18001")]
        end

        subgraph NS2["Namespace: web-app-2"]
            P2[("Pod-2<br/><b>Sender</b><br/>━━━━━━━<br/>web-app:8000<br/>WoSP IN:18000<br/>WoSP OUT:18001")]
        end

        subgraph NS3["Namespace: web-app-3"]
            P3[("Pod-3<br/><b>Aggregator</b><br/>━━━━━━━<br/>web-app:8000<br/>WoSP IN:18000")]
        end
    end

    P1 ==>|Egress:18001| P3
    P2 ==>|Egress:18001| P3

    style P1 fill:#4CAF50,stroke:#2E7D32,stroke-width:3px,color:#fff
    style P2 fill:#4CAF50,stroke:#2E7D32,stroke-width:3px,color:#fff
    style P3 fill:#FF9800,stroke:#E65100,stroke-width:3px,color:#fff
    style K8s fill:#f5f5f5,stroke:#424242,stroke-width:2px
    style NS1 fill:#E8F5E9,stroke:#4CAF50,stroke-width:2px
    style NS2 fill:#E8F5E9,stroke:#4CAF50,stroke-width:2px
    style NS3 fill:#FFF3E0,stroke:#FF9800,stroke-width:2px
Key Characteristics:

  • 2 Sender Pods (Pod-1 and Pod-2) - each with ONE egress port (18001)
  • 1 Aggregator Pod (Pod-3) - only ingress port (18000), no egress
  • Convergent Flow - both senders independently send to the same destination (Pod-3)
  • Stateful Aggregation - Pod-3 tracks and waits for messages from both senders
  • NodePorts: 30005 (Pod-1), 30006 (Pod-2), 30007 (Pod-3)

Customization

DevOps and Platform Engineers are able to modify the simple app business logic, replacing it with their own, without altering the WoSP configuration or communications which proxy both networking (e.g., envoy proxy) and security (hence the name Workload Security Proxy)

In effect, this 3-app blueprint is the foundation for expanding the Zero Trust application network by adding other blueprints (such as the bi-pod or tri-pod fan-out blueprints) while preserving the Zero Trust and AMTD performance of the apps in the network. This simplifies and accelerates deployment of secure application (HTTP apps) networks without the complexity and friction of conventional PKI, TLS, and mTLS implementations.