0
votes

I'm having a strange issue where ARNs get changed at some point. This is happening for both a bucket policy and KMS key policy.

In the policy document, I specify Role ARNs in an external account:

...
principals {
  type        = "AWS"
  identifiers = var.list_of_arns
}
...

The terraform plan output looks normal:

Principal = {
  AWS = [
    "arn:aws:iam::account-id:role/role1",
    "arn:aws:iam::account-id:role/role2",
  ]
}

However, the actual resources that get created are different.

{
  "Statement": [
  ...
  "Principal": {
    "AWS": [
      "SOMESTRINGOF21CHARS",
      "OTHERSTRINGOF21CHARS"
    ]
  }
  ..
}

Why is this happening?

Thanks

1
A complete minimal reproducible example would be niceHelder Sepulveda

1 Answers

1
votes

It looks like terraform/aws is subsituting the user-friendly ARN with the equivalent ID. From the AWS documentation:

When IAM creates a user, group, role, policy, instance profile, or server certificate, it assigns to each entity a unique ID that looks like this:

AIDAJQABLZS4A3QDU576Q

For the most part, you use friendly names and ARNs when you work with IAM entities. That way you don't need to know the unique ID for a specific entity. However, the unique ID can sometimes be useful when it isn't practical to use friendly names.

One example pertains to reusing friendly names in your AWS account. Within your account, a friendly name for a user, group, or policy must be unique. For example, you might create an IAM user named David. Your company uses Amazon S3 and has a bucket with folders for each employee. The bucket has a resource-based policy (a bucket policy) that lets users access only their own folders in the bucket. Suppose that the employee named David leaves your company and you delete the corresponding IAM user. But later another employee named David starts and you create a new IAM user named David. If the bucket policy specifies the David IAM user, the policy allows the new David to access information that was left by the former David.

However, every IAM user has a unique ID, even if you create a new IAM user that reuses a friendly name that you deleted before. In the example, the old IAM user David and the new IAM user David have different unique IDs. You can create resource policies for Amazon S3 buckets that grant access by unique ID and not just by user name. Doing so reduces the chance that you could inadvertently grant access to information that an employee should not have.