You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm wondering whether it's worth integrating SPIRE with AWS IAM Roles Anywhere. Roles Anywhere is an AWS service that allows workloads to obtain temporary AWS credentials through PKI trust. On a very high level, you can configure a CA certificate as root of trust to the service and then use a leaf certificate that forms a certification path to that root of trust in a request to the Roles Anywhere credentialing API, which is called CreateSession. The API uses an asymmetric private-key based signature specification for authN (it doesn't use mTLS). The root of trust that is configured with the service is called a trust anchor and needs to be referred to in the request to CreateSession along with a few other resources, including the ARN of the role that the workload wants to assume. From a mental model perspective, you can think of the service as providing an AssumeRoleWithCertificate API.
For this integration with SPIRE, I'm thinking that on SPIRE server start up, it can create a trust anchor resource with the Roles Anywhere service based on the trust domain's SPIFFE bundle. This means that the SPIRE server will need to be configured with AWS credentials that have permissions to call rolesanywhere:CreateTrustAnchor and rolesanywhere:UpdateTrustAnchor (for when the certificate bundle needs to be updated, like in a rotation scenario), along with potentially a few other permissions. Then, this trust anchor ARN should be saved by the SPIRE server so that it can be communicated to the SPIRE agent. The SPIRE agent can then expose the trust anchor ARN information to workloads through the Workload Endpoint, but through a logical service that is independent from the Workload API (as mentioned in the Extensibility and Services Rendered section of the Workload Endpoint standard). Workloads can obtain the trust anchor ARN for this trust domain from this new logical service and use it to obtain temporary AWS credentials from the Roles Anywhere service.
There are some details that I'm skipping (like revocation for example - Roles Anywhere currently only supports CRLs as a resource that's configured with the service), but on a high level, does such an integration make sense? If so, how should the integration with SPIRE look (does the flow I provided in the previous paragraph make sense)? If the integration does make sense, I would be happy to implement it (although, I do admit that I need to familiarize myself with the SPIRE codebase a bit more).
The text was updated successfully, but these errors were encountered:
Thanks for opening this @ajay1135! Better integration here would be awesome
SPIRE has a plugin type called BundlePublisher, and my feeling is there should be a pretty clear path forward for adding an AWS Trust Anchor plugin. That is pretty well aligned with what you're suggesting, and would ensure that the trust anchor remains updated as keys rotate.
Propagating the configured trust anchor ARN is harder for a number of reasons. We don't have an existing API on the agent for it, that particular API is standardized by SPIFFE, and questions around config divergence on the servers, supporting multiple trust anchors, etc.
That said, I think it makes a lot of sense to start with a BundlePublisher plugin. What do you think? Is it something you'd be willing to contribute?
I'm wondering whether it's worth integrating SPIRE with AWS IAM Roles Anywhere. Roles Anywhere is an AWS service that allows workloads to obtain temporary AWS credentials through PKI trust. On a very high level, you can configure a CA certificate as root of trust to the service and then use a leaf certificate that forms a certification path to that root of trust in a request to the Roles Anywhere credentialing API, which is called
CreateSession
. The API uses an asymmetric private-key based signature specification for authN (it doesn't use mTLS). The root of trust that is configured with the service is called a trust anchor and needs to be referred to in the request toCreateSession
along with a few other resources, including the ARN of the role that the workload wants to assume. From a mental model perspective, you can think of the service as providing anAssumeRoleWithCertificate
API.For this integration with SPIRE, I'm thinking that on SPIRE server start up, it can create a trust anchor resource with the Roles Anywhere service based on the trust domain's SPIFFE bundle. This means that the SPIRE server will need to be configured with AWS credentials that have permissions to call
rolesanywhere:CreateTrustAnchor
androlesanywhere:UpdateTrustAnchor
(for when the certificate bundle needs to be updated, like in a rotation scenario), along with potentially a few other permissions. Then, this trust anchor ARN should be saved by the SPIRE server so that it can be communicated to the SPIRE agent. The SPIRE agent can then expose the trust anchor ARN information to workloads through the Workload Endpoint, but through a logical service that is independent from the Workload API (as mentioned in the Extensibility and Services Rendered section of the Workload Endpoint standard). Workloads can obtain the trust anchor ARN for this trust domain from this new logical service and use it to obtain temporary AWS credentials from the Roles Anywhere service.There are some details that I'm skipping (like revocation for example - Roles Anywhere currently only supports CRLs as a resource that's configured with the service), but on a high level, does such an integration make sense? If so, how should the integration with SPIRE look (does the flow I provided in the previous paragraph make sense)? If the integration does make sense, I would be happy to implement it (although, I do admit that I need to familiarize myself with the SPIRE codebase a bit more).
The text was updated successfully, but these errors were encountered: