Getting Started With Blueprints¶

OVERVIEW¶

Welcome to Lane 7 Blueprints. The fast and simple way to deply application networks that are Zero Trust, Secure by Design, and Secure by Default. A simple Bi-pod Blueprint will get you started and demonstrate the speed and simplicity of deploying a secure HTTP application network within a single Kubernetes cluster.

By deploying this blueprint, you will create a "2-app-serial-demo" network where two pods communicate securely without the complexity of traditional security measures.

Why Blueprints?¶

Securely deploying Kubernetes application networks is traditionally complex, often requiring:

Public Key Infrastructure (PKI) management
Complex certificate rotation
Manual Transport Layer Security (TLS) configuration

The complexity requires time-consuming trial and error tests, slows deployments, adds friction and costs, and can often be fragile.

Hopr's Workload Security Proxy (WoSP) removes this friction. Each blueprint deploys a WoSP sidecar with a containerized app in a Kubernetes pod. The bi-pod blueprint is the simplest blueprint in the Lane7 catalog, and it is pre-configured for two applications each protected by a WoSP sidecar. This quick start guide will explain hot to deploye the bi-pod blueprint in your local environment. In about 30 minutes time, you can have a working bi-pod application network that demonstrates:

Zero Trust: Restricting access to allow only trusted workload connections.
AMTD (Automated Moving Target Defense): Rotating (hopping) access credentials at high frequency to prevent theft.
End-to-End Encryption: Securing Layer 7 communication without early termination or key exchanges.
Post-Quantum Security: Eliminating the risk of encryption failure without relying on centralized key storage.

See the WoSP in action: 🎥 Watch the demonstration video to see the WoSP securing containerized workloads in real-time.

First, signup for the FREE Bi-pod Blueprint 🆓 here.

PREREQUISITES¶

Before deploying the bi-pod blueprint, ensure your local development environment meets the following requirements:

Docker: A local Docker instance running and accessible.
Kubernetes Cluster: A local cluster. We strongly recommend K3d for its speed and lightweight footprint, but Minikube or Kind will also work.
kubectl: Installed and configured to communicate with your cluster.

QUICK START¶

Follow these steps to prepare your environment and artifacts.

1. Build the App Image¶

The blueprint includes a customizable Python application for the workload in each Blueprint. The app is designed with replaceable business logic and universal networking/communications configuration specific to the WoSP. Once you have demonstrated the blueprint app network is working, you can replace the business logic with anything you choose that is compatible with the blueprints (e.g., any HTTP/REST web app logic for most blueprints.)

You must "containerize" the app by building the image locally in Docker before deploying.

# Navigate to the included python app directory  
docker build -t serial-app-wosp-node:latest .

2. Create the Cluster¶

We strongly recommend you create a cluster with port mapping. The port mapping is important in binding the WoSP with the apps. If using K3d:

k3d cluster create wosp-cluster \
  --port "30011:30011@loadbalancer" \
  --port "30012:30012@loadbalancer" \
  --agents 1

#check the cluster
kubectl get nodes

# Expected output:
# NAME                        STATUS   ROLES                  AGE   VERSION
# k3d-wosp-cluster-server-0   Ready    control-plane,master   1m    v1.27.x
# k3d-wosp-cluster-agent-0    Ready    <none>                 1m    v1.27.x

3. Import the Image¶

For the cluster to access your locally built image without a registry, import it directly.

# Example for K3d users  
k3d image import serial-app-wosp-node:latest -c wosp-cluster

# Verify the image is available in the cluster
docker exec k3d-wosp-cluster-server-0 crictl images | grep serial-app

FIRST DEPLOYMENT¶

Once your images are built and your cluster is running, you are ready to deploy the secure application network of Apps and WoSPs in kubernetes pods.

1. Apply the Manifests¶

The blueprint allows you to deploy the entire network with a single command, but you must use the file directory structure in the delivered blueprint (each pod has a directoyr with numbered manifests). The manifests include the Namespace, Secrets, and Deployments for both pods.

kubectl apply -f pod-1/ -f pod-2/

If the blueprint has more than two pods, the command line should show a -f pod-x/ for each pod in the blueprint

2. Verify the Pods¶

Check the status of your deployment. You should see two pods starting up.

kubectl get pods \-A

# Expected output may be multiple pods, but the blueprint pods should look like this
NAMESPACE   NAME                              READY   STATUS    RESTARTS   AGE
web-app-1   web-app-pod-1-xxxxxxxxxx-xxxxx    3/3     Running   0          2m
web-app-2   web-app-pod-2-xxxxxxxxxx-xxxxx    3/3     Running   0          2m

What to look for:
Each pod should show 3/3 in the READY column. This indicates that all three containers in the pod are active:

web-app: The Python application.
xtra-wasm: The WoSP security and credential management module.
web-retriever: The Hopr open source data reteival tool used by the WoSP.

3. Validate Communication¶

The app used is very simple. It repeatedly passes a 'baton' between the pods and counts each cycle. To verify the app network is functioning and the "baton" is being passed securely between the two apps:

Open a terminal for Pod-1 (the initiator) and run this command to see the logs from the web-app container kubectl logs -n web-app-1 -l app=web-app-pod-1 -c web-app -f

Observe the logs to see the communication cycle (every 20 seconds). The logs should look like this:

--- Starting up 'web-app-pod-1' (Initiator: True) ---
🛠️  CLIENT WORKER (web-app-pod-1): Started. Waiting for messages.
🚀 INITIATOR (web-app-pod-1): Task started. First cycle begins in 20 seconds.
--------------------------------------------------
🎬 INITIATOR (web-app-pod-1): Starting relay cycle for baton #1.
➡️  CLIENT (web-app-pod-1): Forwarding baton #1. Trail: ['web-app-pod-1']
⬅️  CLIENT (web-app-pod-1): Got reply for baton #1 (Status: 202): 'Message from web-app-pod-2 accepted by web-app-pod-2 for forwarding.'
🏁 CYCLE COMPLETE (web-app-pod-1): Relay baton #1 received and retired. Trail: ['web-app-pod-1', 'web-app-pod-2']
--------------------------------------------------

For any other pods in your blueprint, you can see their logs by replacing the -n namespace and the -l app name

kubectl logs -n <web-app-X> -l app=<web-app-pod-X> -c web-app -f

You will see Pod-1 initiate a 'baton', send it to Pod-2, and receive an acknowledgement, all secured transparently by the WoSP sidecars.

Need Support?¶

If you encounter issues during deployment, please reach out to our team at support@hopr.co. Please include "Free Blueprint" or "Paid Blueprint" in your subject line for faster routing.