Microservice and Serverless Boundaries

By Davy Rogers

You split the monolith. Now you have 50 trust boundaries instead of one.

Monolith: one trust boundary. Microservices: many. Every service call crosses a boundary.

Service-to-service auth

"It's internal" is not auth. Fails when attacker compromises one service, misconfigured SG exposes internal service, or insider has network access.

Options:

  • mTLS: Both sides present certs. Service mesh handles it.
  • JWT: Signed token per request.
  • Service mesh: Istio/Linkerd handles mTLS transparently.

Zero trust

Never trust based on network location. Every request authenticated/authorised.

  • mTLS or JWT between all services
  • Per-service IAM roles
  • Network segmentation
  • Logging on every boundary

Request context

Edge validates user JWT. Downstream gets user context in trusted header. Trust internal headers only when you verify calling service identity.

Serverless specifics

Cold start timing: Use constant-time comparison for auth.

Over-permissioned IAM: One compromised function with *:* = full account.

Event injection: Validate SQS messages, S3 keys.

Data isolation

Database per service. Others access via API, not direct queries. Use separate DB users with schema permissions.

The takeaway

Authenticate every service call. Don't rely on network isolation. Least-privilege IAM per service. Validate input from internal sources. Assume any component could be compromised.

Want a professional to look at it?Get an AppSec Health Check.