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
Labels

Comments

@gozer
Copy link

@gozer 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 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 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 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 diroussel commented Jan 25, 2016

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

@mdevs5531
Copy link

@mdevs5531 mdevs5531 commented Jan 29, 2016

+1

2 similar comments
@egoldschmidt
Copy link

@egoldschmidt egoldschmidt commented Feb 22, 2016

+1

@vaidik
Copy link

@vaidik vaidik commented Feb 26, 2016

+1

@jmahowald
Copy link

@jmahowald 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 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 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 kaaloo commented May 19, 2016

+1

4 similar comments
@stahs
Copy link

@stahs stahs commented Jun 8, 2016

+1

@cswingler
Copy link

@cswingler cswingler commented Jun 9, 2016

+1

@dotariel
Copy link
Contributor

@dotariel dotariel commented Jun 26, 2016

+1

@mgresko
Copy link

@mgresko mgresko commented Jun 29, 2016

+1

@nbr
Copy link

@nbr 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 ocsi01 commented Jun 30, 2016

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

@offbyone
Copy link

@offbyone offbyone commented Jul 6, 2016

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

@holybit
Copy link

@holybit 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 aadamovich commented Jul 10, 2016

+1

2 similar comments
@anvaughan
Copy link

@anvaughan anvaughan commented Jul 11, 2016

+1

@adamwitherspoon
Copy link

@adamwitherspoon adamwitherspoon commented Jul 21, 2016

+1

@apparentlymart
Copy link
Member

@apparentlymart 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 elafarge commented Sep 11, 2016

+1

@apparentlymart
Copy link
Member

@apparentlymart 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
@hashibot
Copy link

@hashibot hashibot bot 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.

@hashibot hashibot bot 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
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.