Support for IAM "Role Chaining"

[dkujawski]

Community Note

• Please vote on this issue by adding a 👍 reaction (https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/) to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Support a list of IAM roles to be assumed where currently only a single IAM role is allowed. When a list of IAM roles is encountered, assume the roles in the order that they are listed.

New or Affected Resource(s)

The provider

• provider "aws" {}

Potential Terraform Configuration

provider "aws" {
  region = "us-west-2"

  assume_role {
    role_arn_chain = [
      "arn:aws:iam:01234567890:role/origin",
      "arn:aws:iam:01234567890:role/role_a",
      "arn:aws:iam:01234567890:role/role_b",
      "arn:aws:iam:01234567890:role/role_c"
    ]
  }
}

An alternate implementation:

provider "aws" {
  region = "us-west-2"

  assume_role {
    role_arn       = "arn:aws:iam:01234567890:role/role_origin"
    role_arn_chain = [
      "arn:aws:iam:01234567890:role/role_a",
      "arn:aws:iam:01234567890:role/role_b",
      "arn:aws:iam:01234567890:role/role_c"
    ]
  }
}

References

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html

[jbg]

Neither of the proposed implementations would support using external_id for arbitrary roles in the chain.

Why not just remove the restriction that there is at most one assume_role block? That seems cleaner:

provider "aws" {
  region = "us-west-2"

  assume_role {
    role_arn = "arn:aws:iam:01234567890:role/origin"
  }

  assume_role {
    role_arn = "arn:aws:iam:2389472384:role/role_a"
    external_id = "foo"
  }

  assume_role {
    role_arn = "arn:aws:iam:2389472384:role/role_b"
  }
}

[gdavison]

Hi @dkujawski, this looks like an interesting idea. As @jbg notes above, we will need more than just the role ARNs for each role. Each role can potentially define the full set of parameters defined by the assume_role block.

The bulk of the work will have to be done in https://github.com/hashicorp/aws-sdk-go-base.

[djotanov]

Or:

provider "aws" {
  region = "us-west-2"

  assume_roles = [
    {
      role_arn = "arn:aws:iam:01234567890:role/origin"
    },
    {
      role_arn = "arn:aws:iam:2389472384:role/role_a"
      external_id = "foo"
    },
    {
      role_arn = "arn:aws:iam:2389472384:role/role_b"
    }
]

[jbg]

The block approach has the advantage of being directly backward-compatible with existing configurations that just assume a single role, and being consistent with the rest of the terraform ecosystem (lists of arbitrary objects are not really common in resources, repeated blocks are far more typical).

[mbamber]

Out of interest, would the block approach have a consistent order?

[JHeilCoveo]

Out of interest, would the block approach have a consistent order?

If it isn't consistent a simple fix would be to add an order property and sort them according to that field.

[jack-parsons-bjss]

Did a format get agreed upon? Perhaps a separate argument for a source_provider with a full provider block for each step of the chain?

[ustulation]

This is also useful in CD Pipelines. The pipeline "machine" can assume a role in target account A0 to deploy to it, but that target account might need to setup peering with another account A1. A1 allows A0 to assume a role in A1 to set up peering. That way anyone logged into A0 with appropriate role/creds can deploy to A0 as well as assume the role in A1 to setup peering. When the pipeline needs to do the same it will need to assume A0 role to deploy to A0 and then assume A1 after assuming A0 to also do peering. Currently this is not possible in terraform.

As a workaround we either use on-the-fly generated aws-config to set up this chain OR ask A1 to additionally allow the pipeline account to assume that peering role in it (ie. in addition to allowing A0). The former is messy and the latter is an OK compromise but now every such A1 account needs to give perms to both, the corresponding A0 account (to allow whoever is logged into A0 locally to conveniently run terraform apply) and the pipeline account (for automated deployments) to assume the peering role in A1.

[mikedizon]

any movement on this?