IAM roles supporting both SPIFFE (AWS Roles Anywhere) and OIDC

[kemv]

Is your request related to a new offering from AWS?

N/A

Is your request related to a problem? Please describe.

I want to migrate my devs away from using OIDC clusters and over to using SPIFFE with AWS Roles Anywhere. I want to accomplish that in small steps, by offering them a solution which supports both methods, so their migration can be performed completely safely.

Describe the solution you'd like.

To help this migrating process i'd like a submodule which supports trusting a Roles Anywhere trust anchor.
I also think it valuable if the submodule still supports OIDC to help migration, and i think the submodule should be opinionated towards SPIFFE to make life easier for the devs that have to use it.

Additional context

I've already written the code which implements this: https://github.com/kemv/terraform-aws-iam/tree/feature/spiffe-iam-role.

I am however opening an issue before creating a PR because the contributors guide seemed to prefer that.

About my implementation

The new submodule which i've created (iam-role-for-service-accounts-eks-with-spiffe) is a copy of the already existing iam-role-for-service-accounts-eks. The functionality i've implemented is purely new additions, and they could've been added to the original submodule.
The reason i haven't done this is because:

1. I'm assuming you don't want the module to be overloaded with lots of features.
2. The solution is opinionated to use SPIFFE. I don't want a user to see the "Trust Anchor" feature, only to be disappointed when it can only be used towards the SPIFFE use case. By creating a new submodule, it's clearly stated in the submodule name what it can be used for.

As already mentioned, this submodule should be usable to help user migrate away from OIDC using iam-role-for-service-accounts-eks. It is for this reason that i've made sure that this new submodule is completely backwards compatible. Users can change the module and run terraform plan without nasty surprises.

Despite all this, i'd still be open to implement the feature in a different way depending on the discussion :)

Describe alternatives you've considered.

Hosting the forked module internally. Our devs would have to migrate not only submodule, but the entire repository. This is possible, but once again, i'd really like to make their migration as simple as possible.