Terraform: Expose the discovered account_id via the aws provider

[gozer]

My precise use-case is really simple ,I am using terraform to build an IAM policy.

However, I am building the ARN of a known resource (not created by terraform), and it needs the account id. For now, I am making do by providing the aws account-id as a variable, alongside the secret-key and access-key, but it's one more piece of data that could be incorrect.

Since, from my looking at the provider's code, it already determines the accountid (for whitelist/blacklist matching), so I suspect exposing it as a variable might be simple and allow me to do ${aws.account_id} or something similar

[jen20]

Hi @gozer, this is definitely something we want to do, I was reasonably sure there was another issue opened for it but I can't find it right now.

[bradfeehan]

I'd also love to grab the region which is set by AWS_REGION or AWS_DEFAULT_REGION in the environment.

[enaeseth]

I can't find another issue open for this, either, and it would indeed be super useful for defining IAM policies. :smile:

[diroussel]

I need this to be able to put the account_id in an S3 policy.

[mdevs5531]

+1

[egoldschmidt]

+1

[vaidik]

+1

[jmahowald]

Not very proud of this, as it's making a side effect in a user edited file, but this is what I did

cat output_account_id_var.sh
#!/bin/bash

#HT: http://stackoverflow.com/questions/33791069/quick-way-to-get-aws-account-number-from-the-cli-tools
account_id=`aws ec2 describe-security-groups --group-names 'Default' --query 'SecurityGroups[0].OwnerId' --output text`
echo "account_id =\"$account_id\""

Then in my makefile I insert into tfvars

get_vars:
        if grep 'account_id =' terraform.tfvars; \
        then echo "already has account id"; \
        else ./output_account_id_var.sh >> terraform.tfvars; \
        fi

plan: .terraform get_vars

[ajcrites]

Note that this is acquired from aws_ecr_repository registry_id attribute. If you are creating an ECR and you can create it before you need the user ID to create ARNs, you can use that attribute. This is not ideal, but I think it is better than relying on a variable if you don't have to.

[cahlbin]

+1 (usecase: construct an ARN for a resource that is not managed by terraform, that requires the account id)

[kaaloo]

+1

[stahs]

+1

[cswingler]

+1

[dotariel]

+1

[mgresko]

+1

[nbr]

This would also be useful for the aws_vpc_peering_connection#peer_owner_id field (when you are the owner of both VPCs)

[ocsi01]

+1
@nbr Exactly, just faced the same issue.

[offbyone]

+1 on this (hey, doesn't GitHub let me +1 without commenting yet?)

[holybit]

+1

Same issue as OP with AWS provider and ARN where account id is required. Passing in to module as var now but would be great to get this from the provider resource.

[aadamovich]

+1

[vadanx]

+1

[adamwitherspoon]

+1

[apparentlymart]

One way to achieve this would be to add a data source around the sts:GetCallerIdentity operation:

data "aws_caller_identity" "current" {
  # no arguments
}

output "aws_account_id" {
  value = "${data.aws_caller_identity.current.account_id}"
}

The other elements of the GetCallerIdentity response are not as useful in the general case for Terraform, since in many cases lots of different IAM users and roles will be running the same config and so it wouldn't make sense to interpolate the caller ARN or userid. However, we might as well include them anyway for the sake of completeness, possibly with a caveat in the docs noting that account_id is the primary use-case here.

[elafarge]

+1

[apparentlymart]

What I described in my earlier comment was implemented in #8206, so you can now do the following using aws_caller_identity:

data "aws_caller_identity" "current" {}

You can then interpolate ${data.aws_caller_identity.current.account_id} to get the account id.

Thanks for the discussion here, everyone! I'm going to close this now, since I think the original request has been addressed.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.