AWS has published a reference architecture for running SPIRE, the SPIFFE workload identity runtime, on AWS managed services. The main change is that the keys and CA behind every workload credential stop living on the SPIRE server, which is the part of a self-managed SPIRE deployment most worth protecting.
What happened
In an October 6, 2026 AWS Security Blog post, Brendan Paul and Meg Peddada walk through six integrations that address key management, availability, enterprise PKI integration, workloads that can't run a SPIRE agent, and authorization. The authors say the SPIFFE standard, which SPIRE implements, can help with the bottom turtle problem: every secret you add to protect a credential becomes one more credential you have to protect.
- AWS KMS for SVID signing. The AWS KMS key manager plugin (
aws_kms) signs X.509 and JWT SVIDs with HSM-backed keys that never leave KMS. Out of the box, SPIRE keeps keys in memory or on disk. Key use is authenticated with SigV4, controlled by KMS key policies and logged in CloudTrail. - Amazon Aurora as the datastore. By default, the datastore holding registration entries and SVID status is an in-memory SQLite database. The post replaces it with Aurora PostgreSQL using IAM database authentication, multi-AZ failover and point-in-time recovery.
- AWS Private CA as upstream authority. The
aws_pcaupstream authority plugin chains SPIRE to an existing enterprise root through Private CA, with non-exportable keys and managed CRL and OCSP. The authors note the Private CA you use must have a path length of at least 1. - S3 and CloudFront for trust bundles. The S3 bundle publisher plugin (
aws_s3) publishes root certificates and JWT verification keys to S3, optionally fronted by CloudFront. Workloads can then keep validating identities without network access to the SPIRE server. - Secrets Manager for serverless. The Secrets Manager SVIDStore plugin (
aws_secretsmanager) pushes SVIDs into Secrets Manager for workloads that can't run an agent. The post names Lambda and Bedrock AgentCore Runtime as examples. - Verified Permissions for authorization. Cedar policies in Amazon Verified Permissions permit or forbid requests by matching SPIFFE ID patterns, validating JWT-SVIDs through an OIDC identity source.
AWS ships a CloudFormation-based sample in the aws-samples/sample-spire-on-aws GitHub repository and a SPIFFE and SPIRE on AWS workshop.
Why it matters
Workload identity is where non-human identity programs get rid of long-lived secrets: short-lived, attested credentials instead of API keys checked into pipelines. The weak point is the issuer. If the SPIRE signing key sits on disk on the server, anyone who compromises that host can mint an identity for any workload in the trust domain. Moving signing into KMS and the CA into Private CA turns that single host into an IAM-governed, auditable dependency. The trade-off is that the IAM principals allowed to use those keys become your most privileged non-human identities.
The bundle publishing and Secrets Manager pieces address two common blockers: validation that breaks when the server is down, and serverless workloads with nowhere to run an agent. SVIDs stored in Secrets Manager are only as protected as the secret's resource policy.
What to check in your environment
- Find where your SPIRE signing keys live. If the server's key manager writes keys to disk or holds them in memory, treat the server host as a tier-zero asset until you move to a KMS-backed key manager.
- Scope the KMS key policy tightly. Limit signing to the SPIRE server role, and alert on any other principal using the key in CloudTrail.
- Check your datastore. A default SQLite datastore is a single point of failure for registration entries. Plan a move to a highly available, backed-up database.
- Review your PKI chain before integrating Private CA. Confirm path length (at least 1, per the post), who can issue from that CA, and whether workload certificates should chain to your enterprise root at all.
- Lock down published trust bundles. Anyone who can write the S3 object controls what your workloads trust. Restrict write access to the SPIRE server and enable versioning.
- Audit SVIDStore secrets. If you push SVIDs to Secrets Manager, review the resource policies and the IAM permissions listed in the plugin documentation, and confirm only the intended function or agent runtime can read each secret.
- Test Cedar policies against SPIFFE ID patterns. Wildcard matches such as a path prefix can grant more than intended. Pair permits with explicit forbids for sensitive workloads.