Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose the discovered account_id via the aws provider #4390

Closed
gozer opened this issue Dec 18, 2015 · 26 comments
Closed

Expose the discovered account_id via the aws provider #4390

gozer opened this issue Dec 18, 2015 · 26 comments

Comments

@gozer
Copy link

gozer commented Dec 18, 2015

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
Copy link
Contributor

jen20 commented Dec 18, 2015

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
Copy link
Contributor

bradfeehan commented Jan 5, 2016

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

@enaeseth
Copy link

enaeseth commented Jan 20, 2016

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

@diroussel
Copy link

diroussel commented Jan 25, 2016

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

@mdevs5531
Copy link

mdevs5531 commented Jan 29, 2016

+1

2 similar comments
@egoldschmidt
Copy link

egoldschmidt commented Feb 22, 2016

+1

@vaidik
Copy link

vaidik commented Feb 26, 2016

+1

@jmahowald
Copy link

jmahowald commented Mar 1, 2016

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
Copy link

ajcrites commented Mar 8, 2016

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
Copy link

cahlbin commented Apr 7, 2016

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

@kaaloo
Copy link

kaaloo commented May 19, 2016

+1

4 similar comments
@stahs
Copy link

stahs commented Jun 8, 2016

+1

@cswingler
Copy link

cswingler commented Jun 9, 2016

+1

@dotariel
Copy link
Contributor

dotariel commented Jun 26, 2016

+1

@mgresko
Copy link

mgresko commented Jun 29, 2016

+1

@nbr
Copy link

nbr commented Jun 30, 2016

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

@ocsi01
Copy link

ocsi01 commented Jun 30, 2016

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

@offbyone
Copy link

offbyone commented Jul 6, 2016

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

@holybit
Copy link

holybit commented Jul 8, 2016

+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
Copy link

aadamovich commented Jul 10, 2016

+1

2 similar comments
@vadanx
Copy link

vadanx commented Jul 11, 2016

+1

@adamwitherspoon
Copy link

adamwitherspoon commented Jul 21, 2016

+1

@apparentlymart
Copy link
Member

apparentlymart commented Jul 25, 2016

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
Copy link

elafarge commented Sep 11, 2016

+1

@apparentlymart
Copy link
Member

apparentlymart commented Sep 11, 2016

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.

phillbaker added a commit to phillbaker/terraform-provider-elasticsearch that referenced this issue Nov 11, 2019
@ghost
Copy link

ghost commented Apr 22, 2020

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.

@hashicorp hashicorp locked and limited conversation to collaborators Apr 22, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests