Inconsistent treatment of role argument in IAM

[mmdriley]

In this example, I want to create an IAM role, attach an inline policy, then create an EC2 instance profile with that role.

let assumeInstanceRolePolicyDoc = // ...
let instanceRolePolicyDoc = // ...

let instanceRole = new aws.iam.Role("ecsClusterInstanceRole", {
    assumeRolePolicy: JSON.stringify(assumeInstanceRolePolicyDoc),
});

let instanceRolePolicy = new aws.iam.RolePolicy("ecsClusterInstanceRolePolicy", {
    role: instanceRole.id,  // (a)
    policy: JSON.stringify(instanceRolePolicyDoc),
});

let instanceProfile = new aws.iam.InstanceProfile("ecsClusterInstanceProfile", {
    role: instanceRole,  // (b)
});

At point (a), the role is specified using a string ARN.

pulumi-aws/pack/iam/rolePolicy.ts

Line 76 in 8345675

readonly role: pulumi.ComputedValue<string>;

At point (b), the role must be specified as the Role object.

pulumi-aws/pack/iam/instanceProfile.ts

Line 90 in 8345675

readonly role?: pulumi.ComputedValue<Role>;

I haven't looked into how the code is generated yet, but the underlying Terraform schema entries are both schema.TypeString:
https://github.com/terraform-providers/terraform-provider-aws/blob/90d698c66db80d676e2db197be97c1a9977e5393/aws/resource_aws_iam_instance_profile.go#L99
https://github.com/terraform-providers/terraform-provider-aws/blob/90d698c66db80d676e2db197be97c1a9977e5393/aws/resource_aws_iam_role_policy.go#L50

[joeduffy]

This is, unfortunately, our own doing. It's ill-documented, however, we have the notion of "overlays" which can alter the underlying Terraform type to make it more idiomatic in the target language.

In this case, we are being clever and letting you use a capability-style of configuring resources, where you use object identity rather than strings. This is nice, because you don't need to know to .arn the Role, you just pass it and the right thing happens. (If all you see is string, how would you know if it's .arn, .name, .id, and so on, without consulting documentation.)

You can see where we've enabled it for InstanceProfile here

pulumi-aws/resources.go

Line 566 in 8345675

"role": {Type: awsrestok(iamMod, "Role")},

, but notably, we haven't made the equivalent change for RolePolicy. Frankly, we've been tackling these as we go, and we are due for a more coherent push to get consistent here.

But in parallel with this, we have the overall problem that, sometimes you actually may want to pass a string. E.g., maybe the Role exists outside of our purview. Things like Role.get("...") may help bridge this gap in a strongly typed way. But I still frequently wonder if we ought to fall back to typing things like this as Role | string (union type).

Anyway, a simple solution is to just add the overlays as we encounter them. This may be a fine approach for now so that we can learn more before deciding on the long term solution.

[mmdriley]

@lukehoban this doesn't feel like something I'm going to get to soon, but it feels like something to add to the pile of breaking changes we might consider in 0.11.

[jen20]

A similar issue for RolePolicy was fixed in #278. This shouldn't be too hard to go through and fix in the same manner without a breaking change using the same pattern.

Edit: Actually, I read the initial problem description too quickly, this is already fixed by #278 - RolePolicy now accepts string | Role for the role argument.

[lukehoban]

Fixed by #278. Thanks @jen20.