Improving SPIRE security and resiliency with AWS managed services

What it is

AWS Security Blog post detailing six specific plugin integrations that replace SPIRE's (SPIFFE Runtime Environment) default self-managed components with AWS managed services, each solving a distinct named production gap in SPIRE deployments.

How it works

Each AWS service maps to a specific SPIRE server/agent function via a named plugin:

• AWS KMS plugin — replaces in-memory/on-disk key storage for signing X.509-SVIDs and JWT-SVIDs. Keys never leave FIPS 140-3 Level 2 validated HSMs; signing requests are SigV4-authenticated and logged to CloudTrail.
• Datastore SQL Plugin — swaps SPIRE's default in-memory SQLite datastore for Amazon Aurora PostgreSQL, using an IAM-authenticated database user provisioned by the CloudFormation stack.
• AWS Private CA upstream authority plugin — configures SPIRE's CA as an issuing CA chaining to an existing Private CA root (FIPS 140-2 Level 3 HSM-backed), instead of SPIRE's default self-signed root.
• S3 Bundle Publisher Plugin — publishes the trust bundle to S3 (with versioning) and distributes it via CloudFront, so workloads validate peer identities without live connectivity to the SPIRE server.
• AWS Secrets Manager SVIDStore Plugin — configured on the SPIRE agent (not server); a node-attested agent pushes SVIDs into Secrets Manager for consumption by Lambda, ECS, Bedrock AgentCore, or other serverless/container workloads that can't run a SPIRE agent directly.
• Amazon Verified Permissions — uses SPIRE as an OIDC-style identity source, authenticating JWT-SVIDs against the trust domain's public keys, and enforces Cedar policies keyed on SPIFFE ID for resource-level allow/deny decisions.

Preconditions / Affected

Applies to organizations running SPIRE in production on AWS (EC2, ECS, or EKS for agents). Each integration is independently toggleable — the CloudFormation templates expose a parameter per service, so an existing AWS Private CA or Aurora cluster can be reused instead of provisioning new resources. One constraint stated explicitly: if the SPIRE CA certificate is signed by an issuing CA, that issuing CA's path length must be at least 1 (not an issue with the sample's provisioned root CA).

What to do

• Deploy the reference architecture from the linked GitHub repository (CloudFormation-based) rather than hand-configuring plugins.
• To push a given workload's SVID to Secrets Manager, add storeSVID and the relevant selector parameters when creating that workload's registration entry (example given for Kubernetes-managed SPIRE server).
• For hands-on practice, use the separately linked SPIFFE/SPIRE on AWS workshop.

flowchart TD
    A[SPIRE Server] -->|KeyManager| B[AWS KMS: sign SVIDs]
    A -->|DataStore| C[Aurora PostgreSQL]
    A -->|UpstreamAuthority| D[AWS Private CA]
    A -->|BundlePublisher| E[S3 + CloudFront: trust bundle]
    F[SPIRE Agent] -->|SVIDStore| G[Secrets Manager]
    G --> H[Lambda / ECS / Bedrock AgentCore workloads]
    E --> I[Workloads w/o direct SPIRE connectivity]
    J[Amazon Verified Permissions] -->|validates JWT-SVID via trust domain keys| K[Cedar policy: allow/deny by SPIFFE ID]

Caveats

The post is a vendor walkthrough promoting AWS-native replacements; no performance benchmarks, cost comparisons, or failure-mode testing of the managed-service substitutions are given. Permission specifics for the Secrets Manager agent plugin are deferred to a separate plugin GitHub repo rather than stated in the post itself.