Platform
Workload identity architecture deep-dive
SPIFFE-based identity sources, policy engine, ephemeral OIDC token issuance, mTLS enforcement, and zero stored secrets — the complete technical picture.
Core components
How the identity fabric is assembled
Three layers work together. Each layer has a single responsibility. No layer ever holds credential material.
Identity layer — SPIFFE / SPIRE
Every workload is issued a cryptographically-signed SPIFFE Verifiable Identity Document (SVID). The SVID encodes the workload's namespace, service account, and cluster. It is short-lived and automatically rotated by SPIRE — no operator involvement.
Policy layer — Aembit engine
The policy engine receives an SVID and evaluates it against your access policies. Policies specify: which workload identities can call which target services, under which conditions (time, environment, load class). If permitted, a scoped OIDC token is issued. If denied, the request is logged and blocked.
Credential layer — ephemeral tokens
The token issued is an OIDC JWT scoped to exactly the target service, with a 15-minute TTL by default. When the TTL expires, the token is dead with no revocation step needed. The token is injected into the outbound request header by the Aembit sidecar — the application never handles it directly.
Token structure
What is inside an Aembit-issued token
A standard OIDC JWT with workload-specific claims. Any service that validates OIDC tokens can accept it without Aembit-specific SDK changes.
OIDC JWT payload — decoded
{
"iss": "https://aembit.aembits.org",
"sub": "spiffe://cluster.local/ns/prod/sa/api-svc",
"aud": "internal-data-api.prod.svc.cluster.local",
"iat": 1750000000,
"exp": 1750000900,
"jti": "tok_prod_8a3f2c1e",
"aembit.io/policy": "allow:api-svc:internal-api:read",
"aembit.io/workload_type": "kubernetes-pod",
"aembit.io/namespace": "prod"
}