EC2 / non-Kubernetes caller

An EC2-hosted service can call the same protected Orders API without becoming a Kubernetes workload. In TrustPlane Auth v0.1.0-rc.1, 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.

The honest v0.1 boundary

This example is deliberately narrow:

Claim	Status in v0.1.0-rc.1
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."

Subject-prefix policy

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.

Flow

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

• 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.

For the generic software/JWKS command flow, use the Software/JWKS caller example.