Kest Lab: Zero Trust Integration Playground

The kest-lab is a fully orchestrated Docker Compose environment that validates Kest's cryptographic lineage, trust propagation, and policy enforcement against real infrastructure. It is the definitive proof that the v0.3.0 specification is implementable and correct.

Why a Lab?

Unit tests with MockPolicyEngine and MockIdentityProvider validate logic, but they cannot catch:

• SPIRE attestation failures — PID namespace mismatches, socket permission errors, SVID rotation race conditions
• OPA/Cedar policy edge cases — Rego/Cedar syntax issues, incorrect input schema mapping, sidecar connectivity timeouts
• Cross-service propagation bugs — W3C Baggage header encoding, Claim Check cache misses, context loss across async boundaries
• Keycloak OIDC flows — Token exchange, scope delegation, JWT claim extraction

The lab tests all of these with real services.

Architecture

Service Topology

Container Details

Running the Lab

Prerequisites

• Docker and Docker Compose v2
• moon task runner (installed via proto)

Commands

# Start all services (builds containers if needed)
moon run kest-lab:up
 
# Run the full integration test suite
moon run kest-core-python:test-live
 
# View container logs
docker compose -f showcase/kest-lab/docker-compose.yml logs -f hop1
 
# Tear down
moon run kest-lab:down

Why Tests Run Inside hop1

SPIRE attestation requires the test process to run in the same PID namespace as the SPIRE Agent. On Docker Desktop (especially WSL2), the host's PID namespace is isolated from the container's PID namespace. Running tests inside hop1 ensures:

1. The SPIRE Agent can observe the test process's PID
2. The Unix domain socket is accessible
3. SVIDs are issued to the correct workload identity

The test-live moon task handles this automatically by executing docker compose exec hop1 pytest instead of running pytest on the host.

Test Suite: 17 Integration Tests

1. Basic Lifecycle Tests

2. Security Enforcement Tests

3. Trust & Taint Tests

4. Policy Hierarchy Tests

5. Identity Context Tests

OPA Policies in the Lab

The lab ships with pre-configured Rego policies at showcase/kest-lab/opa/policies/:

kest.rego — Core Trust Policy

package kest
 
import rego.v1
 
default allow := false
 
allow if {
    input.trust_score >= 10
}

This policy implements CARTA: it allows execution only if the cumulative trust score is above a minimum threshold. The threshold is deliberately low (10) to allow most lab test scenarios to pass while still blocking adversarial (0) sources.

kest/allow_trusted.rego

package kest.allow_trusted
 
import rego.v1
 
default allow := false
 
allow if {
    input.trust_score >= 40
}

A stricter policy used for functions that handle sensitive operations — requires at least user_input level trust.

Extending the Lab

Adding a New Test

1. Create a test file in showcase/kest-lab/tests/
2. Use the @pytest.mark.live marker
3. Add appropriate skip markers for optional services:

import pytest
 
requires_keycloak = pytest.mark.skipif(
    not keycloak_available(), reason="Keycloak not running"
)
 
@pytest.mark.live
async def test_my_scenario():
    configure(engine=MockPolicyEngine(allow=True), clear=True)
 
    @kest_verified(policy="allow", source_type="internal")
    def my_function():
        return {"status": "ok"}
 
    result = my_function()
    assert result["status"] == "ok"

Adding a New Policy

1. Create a .rego file in showcase/kest-lab/opa/policies/
2. Reference it in your test via @kest_verified(policy="your/policy_name")
3. OPA hot-reloads policies — no container restart needed

Adding a New Service

1. Add the service to showcase/kest-lab/docker-compose.yml
2. Register a SPIRE workload entry for it
3. Add corresponding test cases

Troubleshooting

Related Concepts

• Platform Identity: The theoretical model of workload-to-workload attestation used in the lab.
• Integration with SPIRE: Detailed internals of how the lab's SPIRE agent issues SVIDs.
• Merkle DAG Lineage: The data structure validated by the test_3hop_chain suite.
• Audit Trails: How lab-generated data can be used for zero-trust compliance.

For the full testing philosophy, see Testing & Kest Lab. For the spec edge cases this lab validates, see Spec §11.