- AWS Security published a design that moves SPIRE's signing keys, records and certificate root onto managed services. The SPIRE server itself still runs in the customer's environment.
- Machine identity is only as trustworthy as whoever holds the keys and keeps the records available. Moving them shifts trust toward the cloud provider.
- Ask where your machine-identity keys live, what happens if the identity server fails, and which workloads still use long-lived secrets.
When one piece of software calls another, the second needs proof of who is asking. A fixed password, such as an API key or a shared secret, is one way to supply it. AWS argues these were not designed for short-lived workloads that start and stop constantly.
AWS Security published a reference design on October 6 that tackles this gap. The idea beneath it is simple. A machine identity system is only as trustworthy as whoever holds its signing keys and keeps its records available.
The problem with a password for software
AWS lists API keys, shared secrets and static service account credentials as approaches that weren't designed for the scale and ephemeral nature of cloud workloads. Its answer is to move from long-term, static credentials to short-lived cryptographic identities. It points to SPIFFE, a set of open source standards for identifying software systems. SPIRE is an open source implementation of those standards.
AWS also names the "bottom turtle problem." Protecting one credential takes another credential, and that one takes another. At some point, something must be trusted with no further secret behind it. Where that point sits is the real design choice.
How SPIRE works
A SPIRE deployment has at least one server, at least one agent and at least one workload. The server issues identities. It also stores the registrations that say which workload may receive which identity. Agents run alongside the workloads.
Applications then ask for short-lived identity documents. These are either X.509 certificates or JSON Web Tokens. They fetch them through a local interface called the workload API.
AWS says SPIRE is quick to try out. Production is harder. By default, the server keeps its records in an in-memory SQLite database. It also creates its own self-signed root certificate. Neither default suits a business that needs the system to stay up and fit its existing certificate setup.
What moves to AWS, and what stays
The SPIRE server does not move. Customers still deploy it and manage it, as the post's mention of "managing your SPIRE server" in Kubernetes shows. The agents stay in the customer's environment too. What AWS offloads is the set of supporting jobs around them.
AWS lists six questions. Where do signing keys live? How does the registry stay available? How does SPIRE fit the company's certificate setup? How do workloads check identities without reaching the server? How do identities reach serverless code? How is access enforced? Each gets a managed service.
Signing keys go to AWS KMS. AWS says plaintext keys stay inside hardware security modules. Each signing request is logged in AWS CloudTrail. The registry moves to Amazon Aurora, which AWS says adds automatic failover and automated backups.
The SPIRE certificate authority can chain to an existing AWS Private CA hierarchy. AWS says the private keys of that root cannot be exported.
Trust bundles are the public keys that let one workload check another. SPIRE can publish them to Amazon S3 and serve them through Amazon CloudFront. AWS says workloads can keep validating identities even when the SPIRE server cannot be reached.
Serverless code and AI agents
Some workloads have no room for a SPIRE agent. The post singles out Lambda functions and AI agents hosted on Bedrock AgentCore Runtime. For these, an agent on another node pushes the identity into AWS Secrets Manager. The workload then reads it from there. The post also lists HashiCorp Vault as another store.
Access control comes last. Amazon Verified Permissions can accept SPIRE-issued identities. It applies policies written in the Cedar language. A policy can allow or forbid a named workload from taking actions.
The trade-off the post leaves out
This is AWS describing its own services. The post offers no independent testing. It also does not weigh the cost of tying identity systems to one cloud. That is a question for your team, not a finding.
The design does reduce one burden. The keys and records no longer sit on systems your staff must patch and back up. But the SPIRE server still needs running. And trust now rests more on the provider and on whoever holds its permissions. The turtle has not left. It now stands on a vendor's foundation.
What to ask your team
First, ask where the signing keys for machine identity live, and who can use them. Second, ask what happens to service calls if the identity server goes down. Third, ask which workloads still use long-lived keys or shared secrets, and who plans to retire them.
Fourth, ask how much of the design could move to another provider. AWS notes that each managed service in its templates is optional. Teams can adopt them one at a time.
Machine identity is easy to ignore until software starts acting on its own, including AI agents. Then the question is no longer who logged in. It is who vouched for whatever just made the call.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: AWS Security.
