plugin breaks oidc auth Web Identity Provider authentication

[herebebogans]

Very similar issue to https://github.com/thomasmichaelwallace/serverless-better-credentials/issues/15

Our CI / CD (bitbucket cloud) injects

AWS_ROLE_ARN and AWS_WEB_IDENTITY_TOKEN_FILE into deployment environment

as outlined here

https://support.atlassian.com/bitbucket-cloud/docs/deploy-on-aws-using-bitbucket-pipelines-openid-connect/

Adding this plugin works beautifully for local development with AWS SSO but breaks serverless deployment with the same error

Error:
Error: ENOENT: no such file or directory, open '/root/.aws/credentials'

as issue above.

Removing the plugin fixes the issue.

[thomasmichaelwallace]

Thanks for the bug report- I think one of the main challenges for this plugin is that, because it overloads the credential mechanisms, it needs to understand if you are in a CI/CD environment.

I'm also hoping that the update to aws-sdk v3 will iron out some of the legacy bugs (like the errors caused by expecting ~./aws/config to exist).

[thomasmichaelwallace]

It's a bit late, but I've added a bit to the readme about how to deal with this CI/CD scenario by creating a temporary ~/.aws/credentials file- see:

https://github.com/thomasmichaelwallace/serverless-better-credentials?tab=readme-ov-file#troubleshooting

I'll close this issue for now, but feel free to re-open if you have any trouble.

[herebebogans]

Thanks for the follow up.

I managed to work around this by dynamically stripping the plugin out of config when CI detected. All our serverless config is in typescript so it was reasonably clean to do.

Your workaround doesn't feel right to me - instance profile + other fallback methods should be attempted when there is no credentials file. Feels like the plugin changes the ordering behaviour.

If I get a chance I'll have a deeper look.

[thomasmichaelwallace]

That is also a good fix 😄

The reason the plugin works differently is because, back when there was only the aws-sdk-js v2, the serverless framework used to pass around the credentials object (which isn't ideal because actually the credentials object is a live asynchronous class that needs refreshing &c).

This plugin overrides that object to support SSO &c.

However, the aws-sdk-js v3 has a totally different approach to credentials. So as plugins move to v3 we'll see this start to happen more and more. Which is why the workaround of recreating the credentials file works; because now everything is where v3 expects it to be.

Although the good news is that it might mean that the serverless framework moves to just letting credentials be resolved the default AWS way (rather than their own approach), and tools like aws-vault will just work ™️ .