aws provider allowed_account_ids does not work with iam instance profile

[mnylen]

provider "aws" {
  region = "${var.region}"
  allowed_account_ids = ["${var.allowed_account_id}"]
}

With this provider config, terraform apply fails when running on EC2 instance with IAM instance profile. The error message I'm getting this:

* Failed getting account ID from IAM: ValidationError: Must specify userName when calling with non-User credentials
      status code: 400, request id: [...]

If I remove the allowed_account_ids attribute, it starts to work.

[mnylen]

Terraform version: 0.6.3

[stack72]

@mnylen are you providing IAM keys as well? or just the region and allowed_account_ids?

[radeksimko]

@stack72 I don't think he is.

when running on EC2 instance with IAM instance profile

which means that credentials are coming from the internal metadata service.

[apparentlymart]

This is handled in config.go.

It looks like the implementation is to call iam:GetUser with no UserName argument. According to the docs that returns "the user making the request". Makes sense that this wouldn't work for an instance profile since that's not a user, and so there is no "current user" to return.

The particular error you are getting seems to have been fixed in b95e7a9, where it became silently ignored. However, I think a bug may still remain here: if the GetUser call fails then we presumably won't have a user ARN, and so line 248 will either produce a crash or an empty string.

So all of this is to say: as currently implemented it doesn't look like allowed_account_ids can work with instance profile credentials, since we depend on being able to retrieve the user object making the request. In the next version of Terraform this will behave differently, but may stil have some issues in this case.

[stack72]

@radeksimko d'oh! Missed that :(

[apparentlymart]

It looks like in the case where we're running with instance credentials we can get an instance profile ARN from the metadata endpoint http://169.254.169.254/latest/meta-data/iam/info.

Perhaps it would be sensible to detect whether we got the credentials from the environment or from the instance metadata, and do the account checks differently in the latter case so we'll get the right result from the metadata API.

[radeksimko]

we can get an instance profile ARN from the metadata endpoint http://169.254.169.254/latest/meta-data/iam/info.

That looks like a good plan. 👍

[bwalding]

There doesn't appear to be a great solution for identifying the current account (they're all hacks) when dealing with IAM/STS assume-role generated credentials.

Since an account always has security groups - you could pull the OwnerId off the first entry. The downside for a regular program would be that it may not have access to security groups, but I would assume Terraform would always have at least read access to them.

aws ec2 describe-security-groups

[radeksimko]

Since an account always has security groups

I'm afraid this isn't true. It is possible to remove the default ones in the default VPC and I wouldn't rely on any security groups outside of default VPC either. You don't really need any SGs in cases where you're running background jobs for example.

I think that gracefully falling back to the metadata endpoint if IAM call fails is ok.
Here's an example of response from that endpoint:

{
  "Code" : "Success",
  "LastUpdated" : "2015-10-28T16:49:39Z",
  "InstanceProfileArn" : "arn:aws:iam::101636750127:instance-profile/aws-elasticbeanstalk-ec2-role",
  "InstanceProfileId" : "AIPAREU6ES7PV7RYRYPIC"
}

[apparentlymart]

Right... I think it doesn't even need to be implemented as a fallback, because Terraform "knows" whether it got the credentials from the instance metadata, and so it knows it's using an instance profile without needing to try the initial GetUser request to see if it will fail.

[catsby]

Hey all – doing a review of old issues , is this still relevant?

[radeksimko]

This is still relevant. Essentially #3313 caused that allowed_account_ids/forbidden_account_ids are being ignored on instances w/ IAM Instance Profiles.

[roderickrandolph]

As a fallback when a user name is not provided (i.e. STS roles/credentials) why not attempt to grab the first IAM user's ARN within the account and parse out that user's account ID. It would require the iam:ListUsers permission which is one more than the iam:GetUser permission that's currently required for allowed_account_ids / forbidden_account_ids to work anyway.

It's certainly a hack but it'll work since all users within an account will have the same ID and terraform requires at least one user to exist.

[roderickrandolph]

I hit this problem while using terraform and STS outside of an instance (i.e. where instance metadata is not available)

[roderickrandolph]

d'oh looks like #4290 may solve the problem

[radeksimko]

See #5030
I just tested that ^ with both EC2 & instance profile and federated account and it worked aok.
Any feedback is welcomed, especially before we merge that PR.

[radeksimko]

Fixed via #5030 and #6536 which is also re-enabling credentials validation on EC2 instance (will be part of 0.7.0 release).

[ghost]

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.