Aembit’s identity control plane now issues both SPIFFE credential types: X.509-SVID certificates for mutual TLS and JWT-SVID tokens for bearer-token authentication. Workloads and AI agents get a standards-compliant identity, without deploying or operating SPIRE.
What Is Aembit Announcing?
Aembit supports both SPIFFE credential types as part of the control plane. Both let workloads prove their identity and authenticate to each other using the open SPIFFE standard, issued and managed by Aembit instead of a self-run SPIRE deployment. No SPIRE server, agent, or supporting infrastructure required.
How Does X.509-SVID Support Work?
Aembit issues SPIFFE-compliant X.509-SVID certificates for end-to-end mTLS between client and server workloads, with no application code changes required. There are three ways to get or inject the certificate:
- Agent Proxy: Generates the key pair in memory and establishes the outbound mTLS connection.
- CLI: Issues the certificate directly.
- Aembit Secrets Operator: For Kubernetes environments.
Private keys are never persisted to disk or sent to Aembit Cloud. Certificates auto-rotate at 80% of their lifetime, 15 minutes by default and configurable.
How Does JWT-SVID Support Work?
Aembit issues SPIFFE JWT-SVID tokens for services that authenticate via bearer token rather than mTLS, such as calls behind an Istio or Envoy service mesh. Standard claims (sub, iss, aud, exp, iat, jti) are handled automatically.
Aembit also supports custom claims built from literal values or dynamic workload attributes, like Kubernetes namespace, AWS account ID, or environment. Custom claims carry workload-specific metadata and authorization attributes directly in the token, so the receiving service doesn’t need a separate lookup to decide what a caller is allowed to do.
Do I Need to Run SPIRE?
No. Aembit’s control plane handles identity attestation, credential issuance, and policy evaluation, so there’s no SPIRE server, agent, or supporting infrastructure to deploy or maintain.
What Are the Common Use Cases?
Service-to-service authentication in a service mesh (Istio/Envoy), securing microservices without static secrets, workload-to-workload mTLS across clusters or clouds, and extending SPIFFE-based identity to workloads SPIRE doesn’t natively cover well, like SaaS calls, legacy systems, CI/CD, and AI agents.
See a real example: SPIFFE JWT-SVID in a service mesh, where pods authenticate through an Aembit Trust Provider, request a JWT-SVID, and an Envoy sidecar validates it using standard SPIFFE verification.
How Does This Work If I Already Have SPIRE Deployed?
Teams that already have SPIRE in parts of their environment can use Aembit alongside it to extend coverage to workloads SPIRE doesn’t reach well. Teams starting from scratch can adopt the SPIFFE standard without the multi-year platform engineering investment.
Where Can I Learn More?
Read the docs on X.509-SVID mTLS, the JWT-SVID credential provider, or talk to an engineer.
