Configuration: Zero Trust Identity for Workloads¶

Overview¶

The core philosophy of Lane7 Blueprints is elimination: eliminating the complexity, friction, and "configuration drift" that plague standard Kubernetes deployments.

In a typical environment, securing service-to-service communication requires a web of configuration: Service Meshes, Cert-Managers, CSRs, Key Vaults, and Sidecar Injectors.

This blueprint is different. It comes pre-configured to function immediately. By embedding the Hopr Workload Security Proxy (WoSP) directly into the pod specifications, we remove the need for external control planes to manage identity and secrets at runtime.

Manifests Guide¶

The blueprint bundle typically contains three primary Kubernetes manifest types. Understanding these allows you to scale the blueprint from a demo to production.

!!!Alert
In the examples cited below numerical variables in filenames are denoted by X. Specific name will replace the X with a number corresponding to each pod in the blueprint)

1. Namespaces (01-namespace-pod-X.yaml)¶

This manifest creates the namespace for each pod. The WoSP authorizes pod interconnections via remote endpoint definitions. This requires each pod to have its own namespace (e.g., web-app-pod-X). DO NOT change the generic namespace definitions provided in namespace yamls in a blueprint.

2. Secrets (02-secrets-pod-X.yaml)¶

The secrets yaml is the most sensitive yaml in a blueprint. It has been pre-configured just before download with the licensee’s credentials to access the container repo, define a specific CHIPS™ algorithm, and define license and key required for the WoSP to operate. Be sure not to store your secrets yaml in an insecure or public repository. Keep it secret. Keep it safe!

3. The Deployment (Pod-X-deployment.yaml)¶

This is the heart of the configuration. Unlike standard deployments, you will notice three containers defined in the Pod spec:

web-app: Your application (e.g., a Python app like that found in the bi-pod blueprint).
xtra-wasm (a Korvette-S sidecar): The proxy that intercepts ingress/egress traffic.
web-retriever (supports the xtra-wasm): This container handles collection of dynamic elements used by the WoSP at the start of a communication session.

!!! info "Pre-Wired Security"
You do not need to configure the networking between these containers. They communicate over localhost within the pod boundary, creating a self-contained "Secure Enclave."

Standard Kubernetes Services are used to assign cluster IP addresses. However, because the WoSP handles routing and encryption at Layer 7, the Service definition is minimal and included in the deployment yaml.

Identity Management (Why No PKI?)¶

This is the most critical architectural distinction of the Hopr platform.

This blueprint does NOT use Public Key Infrastructure (PKI) certificates or Mutual TLS (mTLS).

Why no PKI & mTLS?¶

In modern cloud environments, PKI and mTLS automation often fail the principles of Zero Trust:

Implicit Trust: Automated PKI systems issue certificates on receipt of a CSR without vetting the trust of the receiving entity. Zero Trust principles require explicit trust verification.
Static Trust: Once a certificate is issued, it is trusted until it expires or is revoked (which rarely happens fast enough).
Chain of Trust: With PKI certificates the chain of trust ends with the certificate authority and does not extend to the workload receiving the certificate. Each PKI certificate rotation gives the workload an entirely new identity without regard for its prior trust history. Any trust in the old identity is lost and must be re-built.
Centralized Risk: If the Certificate Authority (CA) or the automation pipeline is compromised, the entire trust chain collapses.
Complexity: Managing rotation, expiration, and root-of-trust requires heavy operational overhead.

The Hopr Approach: A Machine Alias ID (MAID™)¶

Instead of static certificates, Hopr uses an ephemeral cryptographic identity credential that builds and preserves the chain of trust in a workload as it operates.

Frequent Rotation: MAID credentials are "hopped" (rotated) automatically at short intervals. There are no long-lived keys to steal. By the time an attacker captures a credential, it is already invalid.
Trust Verification: MAID credentials are verified for trust at the start of each communication session.
Authorization: WoSPs are issued an initial MAID credential on deployment and then rotate the credential thereafter. The authorization workloads to access each other in an application is established in the yaml assignment of remote endpoints. No other authorization policy is needed.

!!! success "Secure by Design"
By avoiding PKI identities, we eliminate the need for you to manage certificates. And we eliminate the identity boundary that impedes connections between different cloud/cluster environments. There are no .crt files to mount, no keys to rotate, and no expiration dates to track.

Secrets Management¶

Because the WoSP handles encryption and identity internally, your application's burden for secrets management is drastically reduced.

Bootstrap Secrets: The WoSP containers require a set of initial secrets (provided in the blueprint) to establish the first link in the trust chain.
Application Secrets: Your application logic (e.g., database passwords, API keys) should be managed via standard Kubernetes Secrets or Vault integration. The WoSP does not interfere with these.

Best Practice: Never hardcode secrets in your application logic. Always inject them as Environment Variables or mounted volumes, as demonstrated in the blueprint manifests.

Environment Variables¶

The blueprint uses Environment Variables to control the interaction between your application and the WoSP sidecar.

Variable	Default	Description
EGRESS_PORT	18001	The local port where your app sends outbound traffic. The WoSP listens here to encrypt and route data.
INGRESS_PORT	18000	The local port where your app receives inbound traffic. The WoSP listens here to decrypt and route data.
POD_NAME	(Dynamic)	Used by the demo app to identify itself in logs. In production, this can be used for logical routing.
NAMESPACE	web-app-pod-X	Each pod is assigned it own namespace to isolate WoSP configurations
NODE_PORT	300XX (match the port mapping in the cluster)	Specific to the demo logic. Determines if the pod starts the relay cycle or waits for messages.

Configuring Your App¶

When adapting the blueprint for your own code (see Customizing Blueprint Apps), you only need to ensure your HTTP client targets:
http://localhost:${EGRESS_PORT}

This simple configuration ensures all traffic is automatically captured, verified, and encrypted by the application network.