Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integration with AWS IAM Roles Anywhere #4963

Open
ajay1135 opened this issue Mar 9, 2024 · 3 comments
Open

Integration with AWS IAM Roles Anywhere #4963

ajay1135 opened this issue Mar 9, 2024 · 3 comments
Assignees
Labels
priority/backlog Issue is approved and in the backlog

Comments

@ajay1135
Copy link
Contributor

ajay1135 commented Mar 9, 2024

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).

@amartinezfayo amartinezfayo added the triage/needed Issue is in need of triage label Mar 9, 2024
@MarcosDY MarcosDY added triage/in-progress Issue triage is in progress and removed triage/needed Issue is in need of triage labels Mar 12, 2024
@evan2645
Copy link
Member

evan2645 commented Apr 2, 2024

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?

@ajay1135
Copy link
Contributor Author

ajay1135 commented Apr 7, 2024

Sorry, I realized belatedly that I accidentally commented with my other GitHub account. Posting the same response again with this account:

Yup, that makes sense to me as well. I'll submit a PR with an implementation of the BundlePublisher plugin once I've implemented it.

@evan2645
Copy link
Member

Thank you @ajay1135 that is awesome

@evan2645 evan2645 added priority/backlog Issue is approved and in the backlog and removed triage/in-progress Issue triage is in progress labels Apr 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority/backlog Issue is approved and in the backlog
Projects
None yet
Development

No branches or pull requests

4 participants