Add Support for IAM Roles Anywhere CreateSession

[rittneje]

Describe the feature

Add native support for CreateSession to the SDK.

Use Case

We would like to leverage IAM Roles Anywhere to "bootstrap" AWS credentials into our external services that are written in Go. We are unable to use the precanned credential_process binaries.

Proposed Solution

No response

Other Information

No response

Acknowledgements

• [ ] I may be able to implement this feature request
• [ ] This feature might incur a breaking change

AWS Go SDK V2 Module Versions Used

n/a

Go version used

n/a

[Madrigal]

For our understanding, why are you unable to use the vended binaries?

Note that these binaries are more than just "bootstrap" credentials. They are a long-running process that is used to refresh your credentials, which includes reading and sending your x509 certificate for validation. You can see what the credential helper does here and get an idea of the size of the effort it would take.

We could port just CreateSession API, but without the binaries I'm not sure that would be super helpful

[github-actions[bot]]

This issue has not received a response in 1 week. If you want to keep this issue open, please just leave a comment below and auto-close will be canceled.

[rittneje]

@Madrigal

For our understanding, why are you unable to use the vended binaries?

I can't get into specifics, but essentially we need to distribute a single static executable. This also highlights another flaw of the binaries - they expect the certificate and private key to be files, which is totally incompatible with things like HSMs. When adding native support to Go, please do so via x509.Certificate + crypto.Signer or similar.

[strideynet]

👍

Even depending on the exported Go code from https://github.com/aws/rolesanywhere-credential-helper is pretty awkward due to it requiring CGO. It'd be great if we could just leverage this API directly from the aws-sdk-go-v2 especially if it supported x509.Certificate and crypto.Signer.

[punmechanic]

Hello,

In our case, we're developing a service that other engineers at the company can use and can embed into their services. It is not reasonable to expect them to embed a binary into their application to make it work.

We're OK with handling credential refreshing ourselves. Indeed, we're using short-lived x509 certificates in the first place, so we already have to handle credential refreshes on one end. Our users are not executing the AWS CLI from their machine; our intended use cases are machines talking to other machines, where credentials_process is not appropriate.

Absent official support, we are likely to leverage a significant amount of the code written in the helper (less the CGO) to provide this support. The helper would be an excellent use if we could run it as a sidecar, but that's not appropriate for every use-case.

As it stands, the helper offers no way to deal with a changing x509 certificate other than manually watching the expiration for it and then shelling out to credential-helper update, or restarting the server process. I think the helper makes a lot of sense when you expect to have a more long-lived certificate, but our certificates are issued with days on them, with workloads that may last longer than that and will need to refresh their certs.

[strideynet]

@punmechanic if you are using SPIFFE/SPIRE, you may find https://github.com/spiffe/aws-spiffe-workload-helper interesting. At the moment it's pretty oriented as a credential-helper/long-running-service, but, we could probably extract some of the CLI side code and expose it as an SDK.

[punmechanic]

@punmechanic if you are using SPIFFE/SPIRE, you may find https://github.com/spiffe/aws-spiffe-workload-helper interesting. At the moment it's pretty oriented as a credential-helper/long-running-service, but, we could probably extract some of the CLI side code and expose it as an SDK.

Thanks, this is really helpful.

I expect we will likely take the CLI code and put this into a SDK.

The key thing for us is that we have APIs that are designed for users to be able to just start using with minimal knowledge of how the library gains credentials. For example, we have a Github Action where specifies some information about a secret they want to retrieve from Vault - their team name and the paths of the secrets - and the Github Action does the rest. The user doesn't need to do anything else other than configure a policy for Vault to accept a connection from their Github repository, which at our corporation is something they are more than used to doing.

Having to install a binary makes this more challenging. It would be possible with a Dockerfile action for Github Actions, where we can abstract the use of the container away from the user, but it's a harder sell when a user wants to interact with AWS from a K8s cluster. Having an SDK would mean that we could just provide a library and say "Use this, job done", without the user having to faff around with anything else. As an additional bonus it also lets us abstract the procurement of x509 certs.

[lucix-aws]

IIUC we would basically just need to support the x509 variant of sigv4, right? That's what's "missing" here, directly calling the rolesanywhere CreateSession API should be trivial if you have signing support for it.

[github-actions[bot]]

This issue has not received a response in 1 week. If you want to keep this issue open, please just leave a comment below and auto-close will be canceled.

[rittneje]

Don't close.

[strideynet]

IIUC we would basically just need to support the x509 variant of sigv4, right? That's what's "missing" here, directly calling the rolesanywhere CreateSession API should be trivial if you have signing support for it.

Yeah - I'd think so. It'd also be beneficial if bindings for the RPC were available within the SDK to save everyone effectively re-implementing the call and needing to keep up with internal changes to the AWS API client libraries.

[ultrabstrong]

I am also in a situation where I cannot use the binaries or cert/key files. Would be nice to have SDK support for this. I'm using .NET 8 . Edit - I see now that this is a SDK for Go so my need in .NET isn't as relevant; but still would be nice to have implemented.