Name Base Secure Routing

NBSR turns a service name into a short-lived, identity-authorized route instead of exposing a reusable network location.

Comment

Inspiration

Traditional DNS tells a client where a service is, but not whether that specific workload should be allowed to reach it, which secure path it should use, or how long that access should remain valid.

Name-Based Secure Routing started from one question:

What if a service name resolved to a short-lived, identity-authorized route instead of a reusable network location?

The goal is not to replace DNS. It is to add an identity-aware routing and authorization layer above conventional naming.

What it does

NBSR turns a logical service name such as payments.internal into a temporary, policy-controlled route.

The flow is:

  1. A workload requests access to a logical service name.
  2. The control plane validates the workload identity.
  3. Open Policy Agent evaluates a default-deny authorization policy.
  4. If access is approved, the control plane issues a short-lived Ed25519-signed routing ticket.
  5. The workload presents the ticket to an Envoy gateway.
  6. Envoy calls an external authorization verifier.
  7. The verifier checks the signature, identity, audience, service, HTTP method, path, and expiration.
  8. Envoy routes approved traffic to the protected backend.

The backend service is not published to the host and cannot be reached directly from client workloads.

How we built it

The prototype uses:

  • Python and FastAPI for the control plane, ticket verifier, payments service, and demo client
  • Ed25519 for workload identity and routing-ticket signatures
  • Open Policy Agent for default-deny authorization
  • Envoy Proxy for external authorization and fixed backend routing
  • Docker Compose for the validated end-to-end deployment
  • Isolated Docker networks to prevent direct backend access
  • Kubernetes manifests and NetworkPolicies for a secondary kind deployment path
  • Pytest and OPA tests for automated validation
  • PowerShell and Bash scripts for bootstrap, testing, demos, and lifecycle management

GPT-5.6 and Codex were used as the main implementation environment. Codex generated the initial repository from a detailed architecture and security specification, then helped validate the live Docker Compose integration and debug issues found during testing.

Challenges we ran into

The biggest challenge was proving that the security tests were real rather than only appearing to work.

During live validation, the original tampered-ticket test changed the final Base64URL character of the JWT signature. For a 64-byte Ed25519 signature, that character can contain unused padding bits. The token string changed, but the decoded signature bytes remained identical, so the ticket was still valid.

We reproduced the issue, confirmed that EdDSA verification was working correctly, changed the test to mutate a signature-bearing byte deterministically, and added a regression test.

Other challenges included:

  • Envoy external authorization configuration
  • OPA policy syntax and default-deny behavior
  • Docker startup ordering and service health
  • Fail-closed gateway behavior
  • Network isolation between clients and the protected backend
  • Keeping the prototype secure without overbuilding a full service mesh or SPIFFE deployment

Accomplishments that we're proud of

The strongest accomplishment is that the prototype works end to end, not just in unit tests.

Validated results:

  • 20 Python tests passed
  • 5 OPA policy tests passed
  • Docker Compose configuration validated
  • All five services started successfully
  • 8 out of 8 mandatory security scenarios passed
  • 15 Kubernetes resources passed offline validation
  • The backend has no published host port
  • Direct client-to-backend access is blocked by real network isolation
  • Envoy remains fail-closed
  • Tampered, expired, malformed, and incorrectly scoped tickets are rejected

The project also includes a threat model, architecture documentation, ADRs, a three-minute demo script, Kubernetes manifests, and a complete public GitHub repository.

What we learned

We learned that identity-aware routing can be built from existing, proven components without inventing a new cryptographic protocol.

The value comes from combining:

  • stable service names
  • workload identity
  • policy-as-code
  • short-lived signed route grants
  • controlled gateways
  • hidden backend infrastructure

We also learned that security tests must validate underlying bytes and real network behavior, not only changed strings or expected status codes.

A different token string is not automatically a different cryptographic signature, and a service without a published port is not automatically isolated unless network access is tested directly.

What's next for Name-Based Secure Routing

The current project is a validated prototype, not a production-ready platform.

The next steps are:

  • SPIFFE/SPIRE integration
  • Cloud-native workload identity
  • Live kind and Kubernetes testing
  • Certificate and signing-key rotation
  • Revocation streams
  • Multi-region gateway selection
  • OpenTelemetry metrics and tracing
  • Rate limiting and replay protection
  • Managed or hardware-backed signing keys
  • High availability and disaster recovery
  • CoreDNS or SVCB/HTTPS bootstrap integration

The long-term goal is to make service names the entry point to identity-aware, policy-controlled, temporary routes instead of reusable network locations.

Built With

  • 5.6
  • chatgpt
  • codex
  • gpt
Share this project:

Updates