Securing microservices

In microservices setups (Kubernetes, Elastic Container Service (ECS), VMs), services need to authenticate to each other. Teams often rely on shared secrets, static API keys, or network controls. This creates risks, stale credentials, and limited visibility into service-to-service communication.

What Aembit solves

Aembit issues unique, verifiable identities to each microservice using Trust Providers. When Service A calls Service B, Aembit issues a signed authentication token. This can be an OpenID Connect (OIDC) ID Token. Alternatively, it can issue a JWT-SVID Token. JWT-SVID stands for Secure Production Identity Framework For Everyone (SPIFFE) JSON Web Token. Service B validates this token using standard cryptographic libraries. Your Access Policies control which services can communicate with each other, and Aembit logs every interaction for audit visibility.

With this approach, you can:

Remove shared secrets and static API keys from your microservices configurations
Use SPIFFE JWT-SVID for environments (for example, Istio, Consul, Kuma)
Use tokens for custom or legacy services that support standard JWT validation

Choosing between JWT-SVID and OIDC tokens

Aembit signs both JWT-SVID and OIDC tokens as JWTs that prove workload identity. The difference is the ecosystem they target.

JWT-SVID follows the SPIFFE specification. Service meshes like Istio, Consul, and Kuma natively understand SPIFFE identities and can validate JWT-SVIDs without custom configuration. If you run a service mesh, JWT-SVID is the natural fit because your Envoy sidecars already know how to verify them.

OIDC ID Tokens follow the OpenID Connect standard. Services that already validate JWTs using standard libraries (most web frameworks include this) can verify OIDC tokens without any SPIFFE awareness. If your services don’t run in a service mesh or you’re integrating with legacy services, OIDC tokens require less infrastructure.

You can use both in the same environment. Use JWT-SVID for service mesh traffic and OIDC tokens for services outside the mesh.

Real example: SPIFFE JWT-SVID in service mesh

Consider an Istio-on-Amazon-EKS environment where microservices need to authenticate with each other. Without Aembit, you would typically run separate (Secure Production Identity Runtime Environment) infrastructure just to issue certificates to your services. That adds another cluster component to manage, patch, and monitor.

What running separate SPIRE infrastructure involves

SPIRE requires deploying and operating its own server and agent components in your cluster. The SPIRE Server manages identity registration and signs SVIDs. SPIRE Agents run as DaemonSets on every node, performing workload attestation and delivering SVIDs to pods.

This means a separate certificate authority to secure, a separate control plane to monitor for availability, and a separate upgrade cycle to track against Kubernetes versions. If the SPIRE Server goes down, services can’t get new SVIDs and authentication fails.

Aembit replaces this infrastructure with a managed service. Identity attestation, credential issuance, and policy evaluation happen through Aembit’s control plane, so you don’t run or maintain SPIRE components in your cluster.

Aembit replaces this separate infrastructure:

Kubernetes microservice authentication flow with Aembit sidecar requesting JWT-SVID tokens for service-to-service communication through Envoy proxy

When a microservice pod starts in your Kubernetes cluster, Aembit’s Trust Provider authenticates it. The Trust Provider uses the pod’s Kubernetes ServiceAccount to verify identity. The pod registers its identity with Aembit.

When the service needs to call another service, it requests a credential from Aembit. Aembit issues a JWT-SVID Token, a signed token in the SPIFFE standard format. Your Access Policies determine whether to grant the credential.

The service makes its request with this token in the Authorization header. The Istio Envoy proxies validate the token using SPIFFE standard verification. The request succeeds because Aembit confirmed the caller’s identity and verified that it has permission to access the target service.

You deploy Aembit as a sidecar in your Kubernetes cluster, using the same deployment patterns as your other services. Compared to running separate SPIRE infrastructure, this reduces operational overhead while aligning with Zero Trust security practices. Aembit also gives you audit logs of every service-to-service interaction.

Why this matters for microservices

Shared secrets and static API keys between services create lateral movement risk. If an attacker compromises one service, those credentials give access to every service that shares them.

With per-workload identity, each service authenticates individually. Compromising Service A doesn’t grant access to Service B because there are no shared credentials to steal. Access Policies define exactly which services can communicate, and Aembit logs every interaction for audit visibility.

Supported platforms

Kubernetes (EKS, Azure Kubernetes Service (AKS), Google Kubernetes Engine (GKE))
Istio, Consul, Kuma (via SPIFFE JWT-SVID)
Any service supporting OIDC or JWT validation

Next steps

Deploy Aembit in Kubernetes to get started with service-to-service identity
Configure JWT-SVID Credential Providers for SPIFFE-based service mesh environments
Configure OIDC ID Token Credential Providers for services that validate standard JWTs

Related use cases:

For securing database connections from your microservices, see Database Access
For microservices spanning multiple cloud providers, see Multicloud Environments
For microservices accessing third-party SaaS APIs, see Third-Party Access