Skip to content
TrustPlane

Non-Kubernetes hosts

Not every trusted caller runs in Kubernetes. An EC2-hosted service can call the same protected Orders API without becoming a Kubernetes workload. In the current TrustPlane Auth release, this is modeled as a software/JWKS-style source: the service signs requests with a software key, and the adapter accepts it only when route policy allows the issuer, trust domain, subject, and signer class.

Know the boundary

Section titled “Know the boundary”

This scenario is deliberately narrow:

Claim Current status
Non-Kubernetes caller acceptance Live through software/JWKS-style trust material
AWS Instance Identity Document attestation Not implemented
Nitro attestation Not implemented
Hardware-bound signing Not implied
Control Plane auto-enrollment Future governance work

The proof says “this configured software source signed this exact request.” It does not say “AWS cryptographically attested this instance.”

Shape the policy with a subject prefix

Section titled “Shape the policy with a subject prefix”

Use a subject shape that lets route policy describe the caller without embedding private cloud details in docs. For example:

{
  "issuer": "https://issuer.acme.example/ec2-jwks",
  "trust_domain": "acme.example.ec2",
  "subject_prefix": "aws:ec2:us-east-1:",
  "required_key_binding": "software"
}

That rule can allow a family of EC2-style callers while still separating them from local development, Kubernetes SPIFFE, or external automation sources.

Follow the request flow

Section titled “Follow the request flow”
sequenceDiagram
  participant C as EC2-style service
  participant A as TrustPlane adapter
  participant B as Local bundles
  participant U as Orders API

  C->>A: GET /orders + passport + transcript-v1 proof
  A->>B: Resolve issuer key and route allowed_sources
  B-->>A: EC2 software/JWKS source rule
  A->>A: Verify signature, subject prefix, route, replay
  A->>U: Forward verified request

What this proves

Section titled “What this proves”
  • TrustPlane Auth is not Kubernetes-only.
  • A VM, edge process, local service, or EC2-hosted service can be accepted as a configured source.
  • The adapter still enforces request binding, audience, replay, signer class, and route policy.

What it does not prove

Section titled “What it does not prove”
  • It does not bind trust to AWS Instance Identity Document claims.
  • It does not use Nitro attestation.
  • It does not make the private key non-exportable.
  • It does not create a managed principal record.

Next steps

Section titled “Next steps”