Bi-pod Blueprint

This 2-app blueprint is the simplest of the Lane7 'blueprint' collection. It's purpose is to demonstrate the speed and simplicity of deploying a simple HTTP application network (in a single Kubernetes cluster) that is secure by design and secure by default. But it is also a building block for other Blueprints that scale the size of an application network.

The two 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 Bi-pod Blueprint

What the Blueprint Does

The bi-pod blueprint is a simple HTTP application network of two pods that connect securely and communicate in cycles without using any PKI or TLS. Pod-1 is the intiator (client) that sends a 'baton' to Pod-2 (server) and Pod-2 recieves it, acknowledges, and returns the baton to Pod-1, which destroys it. Pod-1 initiates a new baton every 20 seconds and the cycle repeats.

Bleuprint Architecture

The blueprint deploys 2 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>Initiator</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>Client Worker</b><br/>━━━━━━━<br/>web-app:8000<br/>WoSP IN:18000")]
        end
    end

    P1 ==>|Egress:18001<br/>baton| P2
    P2 -.->|Response<br/>baton| P1

    style P1 fill:#4CAF50,stroke:#2E7D32,stroke-width:3px,color:#fff
    style P2 fill:#2196F3,stroke:#1565C0,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:#E3F2FD,stroke:#2196F3,stroke-width:2px

Key Features:

• Green (Pod-1): Initiator - sends 'baton' messages every 20 seconds
• Blue (Pod-2): Client Worker - receives 'baton', sends pong responses
• Solid arrow: Outbound baton from Pod-1 to Pod-2
• Dotted arrow: Return baton response from Pod-2 back to Pod-1
• Simple pattern: Demonstrates basic request-response communication

Services mapping:

• Pod-1: NodePort 30011
• Pod-2: NodePort 30012 (if exposed)

Customization

This enables DevOps and Platform Engineers to play with the app, but not alter the WoSP configuration or communications which proxy both networking (e.g., envoy proxy) and security (hence the name Workload Security Proxy). You can easily identify and replace the business logic in the blueprint app with your own and repurpose the app without breaking the security and networking.

In effect, this 2-app blueprint is the foundation for building more elaborate and functional application networks that meet Zero Trust and are protected by Cloud Native AMTD. Other foundational blueprints iinclude the tri-pod fan-out blueprint and the tri-pod fan-in blueprint. Together they simplify and accelerate deployment of application (HTTP apps) networks and replace and improve the security of conventional PKI, TLS, and mTLS implementations