Support for AWS access via IAM - AssumeRole
Closed this issue · 77 comments
I get it's probably a lot of complexity to add, but it'd be great if Terraform supported using IAM roles in its AWS provider authentication.
This adds a few steps to how API credentials are used – you use your normal AWS access key and secret key to call sts assume-role in the API, and this responds with a temporary access key, secret key and session token which you use for the rest of the session. An example with AWS's own CLI is here.
The big use case for this is cross-account access. We have lots of AWS accounts to isolate billing to individual projects, and we link these to one parent account with AWS's consolidated billing. The cross-account roles let us have one set of IAM users in the parent account (eg one IAM user for each actual developer using AWS), and then just a single IAM role in each sub-account, which the developers can assume when needed. This saves having to create a new set of IAM users in each sub-account.
I imagine this would involve adding extra AWS provider config fields to describe the role to assume (using an AWS ARN like arn:aws:iam::account-of-role-to-assume:role/name-of-role), and would also involve changing the AWS API access layer to use the temporary role access/secret keys and a session token.
This should be linked to the AWS meta-issue. I felt the explanation was long enough to warrant a full issue.
I'm currently working on #1049 which is providing IAM support via the aws-sdk-go library, but it's not covering the assume-role use-case (yet?).
The only use-case for the IAM authorisation at the moment is to call the metadata API from inside a running EC2 instance: https://github.com/awslabs/aws-sdk-go/blob/440f9da54cf714e7c27b5b4ffa789793a5fbd658/aws/auth.go#L203-228
To fully understand the suggested solution, would you expect the provider config to have following options?
provider "aws" {
credentials_provider = "iam"
iam_role_arn = "arn:aws:iam::account-of-role-to-assume:role/name-of-role"
}How do you expect to provide the initial pair of access_key & secret_key to call the STS API which will give you the token for further API requests? Statically? File config? ENV vars?
Related: http://docs.aws.amazon.com/IAM/latest/UserGuide/roles-usingrole-switchapi.html
Also if you use MFA for the AssumeRole, it would require some other changes in the whole TF CLI workflow as well, e.g. Terraform interactively asking for the TOTP and providing it in that API request to STS.
btw. there's a lot more use-cases = workflows for this...
http://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-web-identity.html
http://docs.aws.amazon.com/cli/latest/reference/sts/assume-role-with-saml.html
Ain't saying it should all be covered in the first implementation, just thinking loudly about it...
Adding an iam_role_arn config is about as much as I think would be required, though maybe iam_role_to_assume or similar might be more meaningful and readable.
How do you expect to provide the initial pair of access_key & secret_key to call the STS API which will give you the token for further API requests? Statically? File config? ENV vars?
I would expect to provide them the same way access_key and secret_key are currently provided, as fields within the provider "aws" { block, as in the current docs.
I'm not sure if the credentials_provider = "iam" setting is needed, unless we're going to add a lot more providers.
So, to clarify, I'd expect this to be enough for the cross-account assume-role use case:
provider "aws" {
access_key = "${var.aws_access_key}"
secret_key = "${var.aws_secret_key}"
iam_role_to_assume = "arn:aws:iam::account-number:role/name-of-role"
region = "us-east-1"
}
I admit the other role workflows and MFA would add a lot of scope.
I'm primarily interested in this for the cross-account use case I described, because it seems to be the only method AWS supports for accessing a consolidated billing sub-account from the parent account, other than creating a new set of IAM users for each sub-account.
Ah, looking at PR #1049, it does look like you've added support for more complex AWS credential provider configurations?
Sorry, I don't actually know the Terraform codebase or goamz, aws-go-sdk, etc very well. Currently I don't know Go (though Terraform may motivate me to learn), so my issues and comments are largely from the point-of-view of someone using Terraform and using AWS's own tools and API.
Another use case for IAM roles is when you are running Terraform from an EC2 instance with an IAM role in its instance profile. In this case the temporary access credentials (access, secret & token) for the account can be obtained directly from the EC2 instance metadata. This relieves you from the need to manage these credentials manually if you are willing to run terraform in an EC2 instance and would make things very easy for the use case of deploying into the same account.
For the cross-account access you would only need to specify the IAM role to assume in the other account and Terraform would call AssumeRole using the credentials from the instance profile to get a new set of access credentials for the other account.
These temporary credentials from the instance profile can expire so some logic would need to be implemented to renew from the instance metadata when necessary, although it is unlikely that a terraform invocation would run longer than the minimum lifetime a set of credentials obtained from the instance metadata.
Another use case for IAM roles is when you are running Terraform from an EC2 instance with an IAM role in its instance profile.
Yes, that's already included in the linked #1049
For the cross-account access you would only need to specify the IAM role to assume in the other account and Terraform would call AssumeRole using the credentials from the instance profile to get a new set of access credentials for the other account.
Good point with cross-account access in general. I'd personally say that it's actually a reason to implement the whole assume-role logic separately in another PR as it's increasing the scope of the original PR quite significantly.
These temporary credentials from the instance profile can expire so some logic would need to be implemented to renew from the instance metadata when necessary.
The renewing logic is already part of the go library we use:
https://github.com/awslabs/aws-sdk-go/blob/440f9da54cf714e7c27b5b4ffa789793a5fbd658/aws/auth.go#L212-217
The expiration period though is unfortunately currently hardcoded. I will have a look if there's any way we can find the expiration period automatically, if not, I will probably expose it as another variable, that user will need to set or overwrite.
Ah... thanks for the code pointers. Agreed on splitting to another PR... significant scope creep :-)
The expiration time is available in the EC2 metadata along with the temporary credentials:
http://169.254.169.254/latest/meta-data/iam/security-credentials/ROLE/Expiration
The expiration time is available in the EC2 metadata along with the temporary credentials:
👓 read the code more carefully, before you post, Radek... 😑
My bad, the hard-coded time period actually only applies to token provided from a config file:
https://github.com/awslabs/aws-sdk-go/blob/master/aws/auth.go#L130
there might be a way on how to track down the IAM policy which has the time period value, but it may not be that easy as the user calling the API may not have access to the actual IAM resource (can't see any details of policies which are affecting him).
More importantly even if we track it down, then we've got another much bigger problem ahead. These temporary credentials inside files are usually generated using another set of credentials (which only have privilege to generate tokens and not access any other APIs) and the generation process often includes MFA/SAML authorisation.
The IAM provider already reads the expiration period from the API:
https://github.com/awslabs/aws-sdk-go/blob/master/aws/auth.go#L250-259
All of the above means that for the basic implementation we're IMO good to go with #1049 😃
@ncraike would you mind modifying the issue title to "Support for AWS access via IAM - AssumeRole" or something along those lines?
Done.
I feel I've opened a can of worms here, though.
+1 as cross-account access is a desire of ours too. 😍
Some news about this feature?
It's not as clean as a proper solution in terraform would be, but in the short term if you're using the fish shell you can use the credentials file and this function to handle setting up environment variables to authenticate with. It doesn't have support for using AssumeRole (yet) but you can change up the sts arguments pretty easily to manage that.
While this is a little late for this ticket, here is the solution I worked out to work with AssumeRole for the time being: https://gist.github.com/mlrobinson/944fd0e2ad4926ba71c9.
It works with the latest version of terraform, and also with the aws cli tools as well as anything that respects the environment variables used here.
Cross-account deployments via IAM is definitely preferred over using API keys for our use cases. Any more news about this feature?
So much this.. +1
+1
+1
+1 yes right now it is not possible to set up AWS instances with Terraform and variabilize the account that they use to do the setup in any automated way. I tried for a day to make this work.
Given the description of how this mechanism works from @ncraike in the initial issue description, I wonder if this could instead be implemented via a separate tool outside Terraform that would be able to wrap any command that uses the standard AWS environment variables. For example:
aws-with-assume-role {any-neccessary-arguments} terraform plan
Here's how I'd expect that to work:
aws-with-assume-rolelooks in the environment or in standard AWS config files for a set of AWS credentials.- It calls the
AssumeRoleAPI with those credentials and any necessary arguments to specify the role. - If that call is successful, it gets back a new set of credentials.
- It launches the given command (
terraform planin this case) with the environment updated so thatAWS_ACCESS_KEY_IDandAWS_SECRET_ACCESS_KEYare set to the temporary credentials, rather than those that were originally provided.
Splitting the problem up into these two steps means that aws-with-assume-role would be usable with any tool that supports the de-facto standard AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables, including terraform and packer and presumably the AWS CLI.
That might be a good thing to include in the AWS CLI. 😀
Not to say that Terraform couldn't have explicit support for this to make things simpler, but if such a tool were to exist it could be a reasonable alternative.
Edit: reading the thread again, I see that this is actually pretty similar to the script that @mlrobinson shared, except that script outputs environment variables to help you update your shell environment for future commands rather than just running one command as I'd suggested. Maybe that script could be adapted to support what I described above as an extra utility, but as-is it basically addresses this use-case.
It seems possible to variabilize aws instances with user_data field from terraform resources.
--
Julien Lavergne
+33670273883
http://julienlavergne.com
Sent with Airmail
On October 16, 2015 at 12:51:55 PM, Spencer Brown (notifications@github.com) wrote:
+1 yes right now it is not possible to set up AWS instances with Terraform and variabilize the account that they use to do the setup in any automated way. I tried for a day to make this work.
—
Reply to this email directly or view it on GitHub.
As a temporary workaround, is there anything preventing us from wrapping terraform calls in a script that will use AWS cli to obtain temporary assumed role credentials, set those in the environment and then call terraform itself?
IMHO it’s just a trick. Terraform must be isolated from 3rd parties but custom providers.
--
Julien Lavergne
+33670273883
http://julienlavergne.com
Sent with Airmail
On October 31, 2015 at 4:58:45 AM, Alexandr Kurilin (notifications@github.com) wrote:
As a temporary workaround, is there anything preventing us from wrapping terraform calls in a script that will use AWS cli to obtain temporary assumed role credentials, set those in the environment and then call terraform itself?
—
Reply to this email directly or view it on GitHub.
For now, I'm using https://github.com/jbuck/assume-aws-role to solve this problem, but it would really be great to be able to specify within a provider block.
With assume-aws-role, AWS_PROFILE={profile} assume-aws-role {role} opens a shell in which you can just run terraform ... without specifying any more credentialss. This does require your actual AWS credentials to come from the AWS CLI environment variables, and not Terraform, but is a good workaround until this issue is resolved.
assume-aws-role is working great for me when running terraform locally, but I'm just now investigating using Atlas, and I don't think there is a solution that would work there. I hope I can figure one out, but it seems like this feature is required in order to use Atlas with consolidated accounts.
Stumbled over this which has the workaround suggested above (shell script wrapping Terraform): http://blog.sinica.me/aws_multi_account_with_terraform.html
It seems we all are re-inventing the wheel for this: https://github.com/mlrobinson/aws-profile
I built this to mimic the AWS CLI built-in usage of AWS_PROFILE=name aws...., found here: http://docs.aws.amazon.com/cli/latest/userguide/cli-roles.html
However when could this feature be in Terraform? Any idea?
Le 4 févr. 2016 à 05:42, Matthew Robinson notifications@github.com a écrit :
It seems we all are re-inventing the wheel for this: https://github.com/mlrobinson/aws-profile
—
Reply to this email directly or view it on GitHub.
I've confirmed with that there's no native way to make this work with Atlas. You can push the AWS session tokens to Atlas, but they expire relatively quickly so at some point Atlas will no longer be able to plan or apply.
The best solution I've found is to create an "atlas" user inside each AWS sub-account, then use these credentials in Atlas. Not too difficult, especially since you can use Terraform to manage these users. :) This coupled with assume-aws-role (for local terraform) is working great for me (for now). Still wouldn't complain about native Terraform support however...
+1 I also would like EC2 instance profile role support. We have multiple AWS accounts and we do administration using jump boxes with administrative roles attached to their instance profiles (and then lock down access to that box).
+1 it will good if we get assume role support to start.
What is the last status in this thread about AWS IAM AssumeRole implementation? In fact your opinion?
Le 25 févr. 2016 à 14:59, avdhoot notifications@github.com a écrit :
+1 it will good if we get assume role support to start.
—
Reply to this email directly or view it on GitHub.
Just want to add my $0.02. This is a huge deal. We are very close to being able to finally use roles across the board and not having to manage access keys in source control anymore. Terraform is one of the remaining outliers.
That's really a good news ;)
Le 11 mars 2016 à 20:10, Bryan Murphy notifications@github.com a écrit :
Just want to add my $0.02. This is a huge deal. We are very close to being able to finally use roles across the board and not having to manage access keys in source control anymore. Terraform is one of the remaining outliers.
—
Reply to this email directly or view it on GitHub.
@bmurphy1976 Would you mind sharing some details about your use-case?
As I described above, there's quite a few different use-cases that will very likely require very different approach.
At least knowing which one of these API calls do you intend to use (or using already) would help:
sts:AssumeRole(with MFA?)sts:AssumeRoleWithSAML(what's your workflow like, IdP provider and/or solution for parsing the SAML assertion and turning it into the AWS credentials)sts:AssumeRoleWithWebIdentity
I think there are "work arounds" for most of these ^ since Terraform AFAIK supports the session token everywhere - i.e. if you have an external tooling which generates the API keys & session token, then you should be just fine.
It might be nice to have built-in support for this - i.e. you'd give Terraform API keys that only have sts permissions and Terraform would Assume the role for you and regenerate the keys if necessary. That also means however that Terraform might need to ask the user for MFA code or credentials for the SAML IdP.
@radeksimko, what we are doing is pretty simple. Every developer gets an IAM user and associated access key. That IAM user is given permission to only call sts:AssumeRole on a role called devops which has a limited and strictly defined set of permissions.
Setting up and using AWSCLI is exceedingly easy now:
$ cat ~/.aws/config
[default]
output = json
region = us-east-1
role_arn = arn:aws:iam::AWSACCOUNT:role/devops
source_profile = default
aws_access_key_id = IAM_USER_ACCESS_KEY
aws_secret_access_key = IAM_USER_SECRET_KEY
Now, the important piece here is that the configuration is environmental. It works on our local machines, but in production and our continuous integration environments it uses IAM boot roles instead.
In a few limited cases our employees are also given permissions to assume other roles (i.e. a role with full IAM access). In those cases, AWSCLI supports both --profile and export AWS_DEFAULT_PROFILE. Ideally Terraform would be able to do something similar.
I know we can script around this (and will likely do this in the interim), but having this built into Terraform seems like a slam dunk. Our environments are already configured to do the right thing, it would be nice if Terraform fell in line with the other tools.
In addition to the above our use case is we have multiple AWS accounts for
different environments. We use assume role from a central AWS account to
specify who is allowed to which environment account for simpler user
administration.
On Fri, 11 Mar 2016 at 22:07, Bryan Murphy notifications@github.com wrote:
@radeksimko https://github.com/radeksimko, what we are doing is pretty
simple. Every developer gets an IAM user and associated access key. That
IAM user is given permission to only call sts:AssumeRole on a role called
devops which has a limited and strictly defined set of permissions.Setting up and using AWSCLI is exceedingly easy now:
$ cat ~/.aws/config
[default]
output = json
region = us-east-1
role_arn = arn:aws:iam::AWSACCOUNT:role/devops
source_profile = default
aws_access_key_id = IAM_USER_ACCESS_KEY
aws_secret_access_key = IAM_USER_SECRET_KEYNow, the important piece here is that the configuration is environmental.
It works on our local machines, but in production and our continuous
integration environments it uses IAM boot roles instead.In a few limited cases our employees are also given permissions to assume
other roles (i.e. a role with full IAM access). In those cases, AWSCLI
supports both --profile and export AWS_DEFAULT_PROFILE. Ideally Terraform
would be able to do something similar.I know we can script around this (and will likely do this in the interim),
but having this built into Terraform seems like a slam dunk. Our
environments are already configured to do the right thing, it would be nice
if Terraform fell in line with the other tools.—
Reply to this email directly or view it on GitHub
#1275 (comment)
.
Ideally this would be supported via profiles similar to aws-cli
[profile marketingadmin]
role_arn = arn:aws:iam::123456789012:role/marketingadmin
source_profile = default
mfa_serial = arn:aws:iam::123456789012:mfa/jonsmith
Changes need to happen to aws-sdk-go upstream to support similar config to aws-cli/botocore
(boto/botocore#721). If these were implemented in aws-sdk-go then users could use profile as a workaround until an additional argument was added to the aws provider in terraform.
This appears to have been started in: aws/aws-sdk-go#472
In lieu of this I have a wrapper (that also supports MFA) that will use botocore's support to set aws access_key/secret_key/token environment variables, which are supported by aws-sdk-go:
AWS_DEFAULT_PROFILE=marketingadmin ./aws-profile terraform args
please note: the aws-profile approach causes problems if you're using multiple aws accounts since it bypasses terraform's allowed_account_ids check.
The allowed_account_ids bugs is most likely related to the use of roles and
is discussed in #3431. If you
are using a token which getUser() returns a valid arn the account_id is
parsed correctly.
On 12 April 2016 at 09:24, Matthew Robinson notifications@github.com
wrote:
@jefforulez https://github.com/jefforulez Can you message me about that
issue privately? We are using it with multiple AWS accounts, and everything
works fine, but we haven't setup allowed_account_ids either. I want to make
sure we aren't hurting something else in the process.—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub
#1275 (comment)
@mlrobinson @atward i created gist which outlines what i'm seeing: https://gist.github.com/jefforulez/c25b325f3ae169993f884859149ea926
the aws-profile approach causes problems if you're using multiple aws accounts since it bypasses terraform's allowed_account_ids check.
That is being fixed in #5030
crap. i take that back. it's still not working for me. i tested incorrectly. sorry!
We created a gem to deal with this issue using terraform and other community tools:
https://github.com/manheim/awssume
I went through the solutions in this ticket, seems most of them need seperate profile files. I prefer to follow the standard AWS CLI (Command Line Interface) settings to read exist .aws/credentials and .aws/config.
.aws/config supports profile and defines as below:
[profile stag]
region = us-east-2
source_profile = default
role_arn = arn:aws:iam::xxxx:role/CrossAccount
[profile prod]
region = us-east-1
source_profile = default
role_arn = arn:aws:iam::xxxx:role/CrossAccount
Why we need manage two or more aws api key configurations? Make it simple and no duplication.
So we should have something set as below
export TF_AWS_PROFILE=stag
terraform plan/apply
or
terraform plan/apply -aws_profile=stag
UPDATES:
Ok, seems my ideal is similar as @bmurphy1976 and @atward
In reference to the wrapper solution, the use-case this doesn't cover is where you're trying to manage cross-account details. For example, peering VPCs between two accounts. So, say you have an IAM account in the "primary" account, and then you have a "prod1" and "prod2" account each with a unique "ops" role, and you want to setup peering between those two VPCs with one in each prod account.
With the aws provider's alias capability you can setup two aws targets, and individual access key data. What would be ideal is if you could have the auth already in place for your user account, and then set the role within each aws target that should be used for handling resources within that account.
provider "aws" {
alias = "primary"
region = "us-east-1"
# Keys and Session token picked up from environment
}
provider "aws" {
alias = "prod1"
region = "us-east-1"
source_credentials = "primary"
role_arn = arn:aws:iam::222222222222:role/ops
}
provider "aws" {
alias = "prod2"
region = "us-east-1"
source_credentials = "primary"
role_arn = arn:aws:iam::333333333333:role/ops
}Does that make sense as a use-case for cross-account roles?
@mbainter I'm having the same issue. An alternative implementation which leverages the profile attribute would look something like (this doesn't currently work, just another example of what the ux could look like). I think I prefer your example in some use-cases, and mine in others, so both would probably be worth having :)
# ~/.aws/config
[profile myself]
region = us-east-1
[profile prod1]
role_arn = arn:aws:iam::111111111111:role/ops
source_profile = myself
[profile prod2]
role_arn = arn:aws:iam::222222222222:role/ops
source_profile = myself
# ~/.aws/credentials
[myself]
aws_access_key_id = XXX
aws_secret_access_key = YYY
# main.tf
provider "aws" {
alias = "a"
profile = "prod1"
}
provider "aws" {
alias = "b"
profile = "prod2"
}
For several weeks we discuss about an implementation.
Any consensus ;) ?
Le 28 juin 2016 à 20:11, Matt Conway notifications@github.com a écrit :
@mbainter I'm having the same issue. An alternative implementation which leverages the profile attribute would look something like (this doesn't currently work, just another example of what the ux could look like). I think I prefer your example in some use-cases, and mine in others, so both would probably be worth having :)
~/.aws/config
[profile myself]
region = us-east-1[profile prod1]
role_arn = arn:aws:iam::111111111111:role/ops
source_profile = myself[profile prod2]
role_arn = arn:aws:iam::222222222222:role/ops
source_profile = myself~/.aws/credentials
[myself]
aws_access_key_id = XXX
aws_secret_access_key = YYYmain.tf
provider "aws" {
alias = "a"
profile = "prod1"
}provider "aws" {
alias = "b"
profile = "prod2"
}—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
👍 this is a blocker for my use case also
The wrapper idea is a neat workaround, but how are people handling expiring API tokens mid terraform run?
Normally the STS token will be expired in 1 hour, should be enough for a terraform run.
That's a good question ...
Le 7 juil. 2016 à 02:27, Ian Duffy notifications@github.com a écrit :
The wrapper idea is a neat workaround, but how are people handling with expiring API tokens mid terraform run?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
Any implementation to come?
Le 7 juil. 2016 à 05:32, Bill Wang notifications@github.com a écrit :
Normally the STS token will be expired in 1 hour, should be enough for a terraform run.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
+1
Would love to have this as well.
Very soon?
Julien Lavergne
+33670273883
http://julienlavergne.com
Le 14 juil. 2016 à 18:07, Marduk notifications@github.com a écrit :
+1
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
Any updates on this issue ?
This issue is so important
Good implementation is needed
Le 21 juil. 2016 à 23:48, ShwethaBallariMallappa notifications@github.com a écrit :
Any updates on this issue ?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
A solution to this is needed.
Writing a wrapper to populate environment variables (which would be the most elegant solution) is broken on instances with EC2 roles. See #7768.
Here's the wrapper I use it anyone find it useful: https://gist.github.com/dbrandt/b440f3be67897222cdc4650db510e262
I ported the aws-profile python script to pure bash if anyones interested. It caches the creds in the same file your CLI uses, so you only have to MFA once if it's enabled. It requires the python aws cli tools. https://github.com/zoltrain/aws-profile
These wrappers will not work when the instance is using an EC2 IAM role (standard procedure when inside AWS) as it will always use the token from the EC2 IAM role (see #7768).
I think this change made upstream would address this problem. It looks like the upstream aws-go-sdk library now supports this as of version 1.3.0.
If I'm right that this addresses that problem, hopefully we'll see this being brought into terraform soon-ish then.
Not sure if this is related:
I want to use the delegation set in Account A when creating a hosted zone in Account B.
Account A:
resource "aws_route53_delegation_set" "Platform" {
reference_name = "${var.environment}"
}
Account B:
resource "aws_route53_zone" "Product" {
name = "${var.product_domain}"
delegation_set_id = "the_id_of_the_delegationset_in_account_a"
}
Would any of the suggestions in this issue allow me to achieve this?
At the moment I get the following error when trying to apply the terraform script for Account B:
Error applying plan:
1 error(s) occurred:
* aws_route53_zone.Product: AccessDenied: User: arn:aws:iam::123456789012:user/terraform is not authorized to access this resource
status code: 403, request id: 6cc22c52-64bd-11e6-bf31-a1ca9bc0fefa
That error looks like the user you are running terraform with for account B doesn't have access to create route53 zones.
Added a potential solution for this over in the PR at #8506
It adds support for specifying a roleArn in the provider block.
It will use any valid credentials it finds in the credentials chain to execute the assume role.
I'm a Golang newbie so would love people to jump in to get it across the line and merged.
When will this issue be resolved?
Julien Lavergne
+33670273883
https://julienlavergne.com
On 31 Aug 2016, at 14:37, Ian Duffy notifications@github.com wrote:
Added a potential solution for this over in the PR at #8506
It adds support for specifying a roleArn in the provider block.
It will use any valid credentials it finds in the credentials chain to execute the assume role.
I'm a Golang newbie so would love people to jump in to get it across the line and merged.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
@julienlavergne, it'll be resolved when there's resolution.
There is always a solution. Any AWS engineer wants to help us?
Julien Lavergne
+33670273883
https://julienlavergne.com
On 31 Aug 2016, at 15:04, ketzacoatl notifications@github.com wrote:
@julienlavergne, it'll be resolved when there's resolution.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
Hey, @jen20 and @imduffy15. Is it supposed to work in latest master?
Thanks for the work!
provider "aws" {
region = "${var.aws_region}"
profile = "${var.aws_profile}"
+
+ assume_role {
+ role_arn = "arn:aws:iam::<123>:role/<name>"
+ }
}
$ terraform plan
2016/09/03 15:50:59 [INFO] Terraform version: 0.7.3 dev b02041062f605002c6605d9656f7dc58ce8a1ae1+CHANGES
Errors:
* provider.aws: : invalid or unknown key: assume_role
I did @jen20. Not sure why is it complaining. With TF_LOG=debug its displaying the proper (master) terraform version at the beginning of the run.
Quick question - support for mfa wasn't implemented in that PR, right?
We just released a tool assume-role (https://github.com/coinbase/assume-role) that can export the credentials without using a profile. This means we don't have to use assume_role on the AWS provider. Although this issue is closed, this is how we manage dozens of accounts and roles that have MFA and temporary credentials.
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.