[Bug]: The IAM Role resource uses role names as external ID causing conflict between role using the same name but different paths about provider-aws HOT 4 CLOSED

Why is it a problem for multiple managed resources to have the same external name? I'm surprised to see the external name present as a label. I'd expect it to be an annotation.

Changing the external name configuration of this resource, which is quite possibly the single most commonly used resource in the provider, will require substantial testing around how it behaves in various cases, including before/during/after installing an upgraded provider.

I've never tried using multiple roles with the same name and different path. Given that the terraform id is the same, it's not a given that would work properly even without the label collision.

from provider-aws.

Hi @mbbush!

You are right about the external name, it should be an annotation. I fixed the examples in the description.

I agree that's a challenging change.

Let me explain our use case: In our platform based on Kubernetes we allow user to create AWS roles using a composition claim we provide. The composition takes the claim namespace and the claim name and compose the IAM role path and name following a standard similar to /<namespace>/<role-name>. The role is then attached to a service account using the IRSA annotation.

That allows users to create unique roles in different namespaces, as the namespace is included in the role path making it unique.

Everything works smoothly when creating the first role:

1. Claim for role-a is created in namespace namespace-y
2. Composition creates Role resource with name role-a-<unique-suffix-based-on-namespace-y> (we use the suffix to make the resource unique as it is not namespaced) and external name annotation role-a and role path set in the spec
3. IAM Role is created in AWS
4. Everyone is happy

When the second role is created:

1. Claim for role-a is created in namespace namespace-z
2. Composition creates Role resource with name role-a-<unique-suffix-based-on-namespace-z> and external name annotation role-a and role path set in the spec (I believe the issue is here as neither the path nor the arn is used in the external name annotation)
3. Role resource fails the sync with an error similar to resource already exists as a resource with role name role-a was already created from the namespace-y

We also considered a different approach putting the namespaces as prefix in the role name. The issue that we faced was that AWS have a 64 character limit on the role name and we reached this limit in some scenario where we had long namespace names.

Hope that helps in understanding what we are trying to do. Let me know what you think. It feels wrong to use an ID in the provider that cannot uniquely identify the related cloud resource. Meanwhile I'll open an issue in the Terraform provider to brainstorm ideas also from there.

from provider-aws.

I looked through the terraform provider implementation, and my conclusion is that it is probably unwise to use multiple roles with identical name parameters and different paths managed by any IaC tool based on terraform-provider-aws.

The fundamental constraint is the aws go sdk v2 iam GetRole operation, which accepts a single parameter, the role name, and returns a single result. Other operations like DeleteRole and PutRolePolicy have a similar schema. I don't even know what that would do if you invoke it on an account containing multiple roles with identical names but different paths. If you test this, I'd be curious to hear the result. I'm surprised to find this limitation in such a core part of the AWS SDK, and I wonder if it's simply an artifact of AWS adding support for paths several years after initially creating IAM, or if it's a sign that AWS itself doesn't support roles that differ only in their path but have the same name, or something else. Perhaps there's a different SDK operation that allows you to specify both the name and path, but I didn't immediately see one, and changing the provider to use that different operation would be a major undertaking.

The documentation in the aws sdk v2 claims that the only valid input for the role name is alphanumeric characters or _+=,.@-. If true, this would mean that you can't simply supply a full ARN for the role name, as you can for many other resources that accept multiple name formats in a single parameter. I tried invoking aws iam get-role --role-name [full arn of role] and got an error for the roleName being invalid, so it seems like the documentation is probably correct here.

Possible issues I'd be looking out for if I were to try to have multiple roles with the same name would include:

• If I create path1/common-name and path2/common-name, then update or delete path1/common-name, does the provider actually apply the change to the right resource?
• Is there different behavior if one of the paths is the default path /?

The only thing I can think of in this provider that might be able to handle this is the aws cloudcontrol api. You could look into whether that can handle managing IAM roles with identical names and different paths. If that works, a possible workaround could be to use the Resource.cloudcontrol.aws.upbound.io managed resource, which allows this provider to manage arbitrary cloudcontrol resources, but you'd have to test that to see how it behaves. It would certainly be less ergonomic than a native resource, it might have substantially worse performance than a native iam Role resource, but you could consider it.

Your description of how you want your platform to work seems reasonable and intuitive, but it seems like you're running into a pretty hard limitation on the implementation side. Perhaps you could get most of what you want with a compromise on some of the readability by simply adding a random suffix to the role names, like the first few characters of sha checksum of the path? That would allow you to prevent collisions between roles managed by users in different namespaces, without requiring the IaC to support multiple roles with identical names in different paths, in a way that it currently does not. You could still use paths to increase readability, and enable things like ABAC or other IAM policy restrictions based on path, with a role arn like arn:aws:iam::<account id>:role/<namespace>/<user-controlled name>-<short hash of namespace>

from provider-aws.

Morning @mbbush,
I got confirmation that the role name within the same AWS account must be unique, regardless of the path.
Sorry for the wasted time and thanks for the support

from provider-aws.