Cant use provider on a null_resource

[gtmtech]

Terraform 0.8.7

a null_resource doesnt support provider. How frustrating!

So when terraform doesnt support some aws functionality which I could do with a local-exec of aws cli stuff, then I have to all kinds of equivalent sts assume-role stuff first, because terraform cant supply provider based creds in the environment prior to running the null_resource.

I would assume this is a simple fix?

[apparentlymart]

Hi @gtmtech,

Reading between the lines here, I think you are asking about the local-exec provisioner running some script that wants to interact with AWS?

So I think what you would like to see here is a way to set some environment variables for the child process to pass the credentials created when the "aws" provider assumes a role.

Am I understanding that correctly?

[mitchellh]

I'm also not sure what you're asking here, could you please clarify? Thanks!

[gtmtech]

Hi @apparentlymart , @mitchellh - yes you're correct.

Right now I'm working my way around another problem (which is just that terraform doesnt allow you to create a vpc-to-route53-zone-association when the vpc and the zone are in different accounts. However the aws cli allows you to do this fine, and so I thought until such time that terraform implements it, I can easily implement it using null_resources and local-exec provisioners. And this is how I came across this problem.

As I do a lot of cross-account aws terraforming, I typically set up provisioners like this:

provider "aws" {
    alias = "account1"
    region = "eu-west-1"
    assume_role {
        role_arn = "arn:aws:iam::111111111111:role/my_terraform_role"
    }
}

provider "aws" {
    alias = "account2"
    region = "eu-west-1"
    assume_role {
        role_arn = "arn:aws:iam::222222222222:role/my_terraform_role"
    }
}

So for example, now when I create peering connections, I can easily create an aws_vpc_peering_connection with provider="aws.account1", and an aws_vpc_peering_connection_accepter with provider="aws.account2" - and it all works nicely.

On to something like an aws vpc route53 zone association across accounts.

I have two resources like this:

resource "null_resource" "create_vpc_association_authorization" {
    provider = "aws.account1"
    provisioner "local-exec" {
        command = "aws route53 create-vpc-association-authorization --hosted-zone-id ${aws_route53_zone.my.zone_id} --vpc VPCRegion=eu-west-1,VPCId=${aws_vpc.my.id}"
    }
}

resource "null_resource" "create_vpc_association_association" {
    provider = "aws.account2"
    provisioner "local-exec" {
        command = "aws route53 associate-vpc-with-hosted-zone --hosted-zone-id ${aws_route53_zone.my.zone_id} --vpc VPCRegion=eu-west-1,VPCId=${aws_vpc.my.id}"
    }
}

This obviously doesnt work because unfortunately null_resource does not accept provider. I think it easily could, because as @apparentlymart suggests, all that needs to happen is that the 4 AWS variables get set (or other variables for other provider types) - AWS_REGION, AWS_SECRET_ACCESS_KEY, AWS_ACCESS_KEY_ID, and AWS_SESSION_TOKEN
(http://docs.aws.amazon.com/cli/latest/userguide/cli-chap-getting-started.html#cli-environment)

As it is, I unfortunately have to call out to other scripts to do the monotonous work of assuming the right roles all over again, which results in duplication between assuming roles by the lovely terraform provider, and assuming roles as part of local-exec, using bash scripts.

[xynova]

Ive got the same problem, it would actually be nice to retrieve the provider credentials to perform other operations with the cli

[thyrion]

Or is there any other workaround to get sns email subscriptions working?
(https://www.terraform.io/docs/providers/aws/r/sns_topic_subscription.html)
currently we are doing:

resource "null_resource" "sns-email-subscription" {
  provisioner "local-exec" {
    command = "AWS_ACCESS_KEY_ID='${var.access_key}' AWS_SECRET_ACCESS_KEY='${var.secret_key}' AWS_SESSION_TOKEN='${var.session_token}' AWS_DEFAULT_REGION='${var.region}' aws sns subscribe --topic-arn ${var.topic_arn} --protocol email --notification-endpoint ${var.email}"
  }
}

[opetch]

Hey @gtmtech you might be interested in my module, it doesn't allow a provider to be used for a null_resource/local-exec but does encapsulate the sts bit that you mention above, maybe you've already created something similar in your project, thought I'd share anyway.
https://github.com/opetch/terraform-aws-cli-resource

[djhaskin987]

@opetch , @gtmtech , Writing an Amazon AWS CLI provider in golang is the way to go here. Provisioners provide zero life cycle management. You have to do that yourself if you use scripts. Far better to use the resource concept in Terraform and just write a slightly different provider. I did something similar with the Helm CLI, I just wrapped it in a small amount of golang code. Example: http://github.com/djhaskin987/terraform-provider-helmcmd . The initial release only took me a few hours because I was just wrapping the CLI.

[e-moshaya]

any update on this?

[deitch]

Oh just got bit by this too.

[apparentlymart]

This issue was migrated over to the null provider repository due to its original phrasing as a feature request for that provider, but I've left a comment over there explaining that this actually would be an AWS provider enhancement. I also shared a possible workaround in that comment, along with a possible feature request for the AWS CLI itself.

The AWS credentials belong to the AWS provider rather than Terraform Core; Terraform Core does not have access to them at all (they are in a child process) and so there is no change we could make to Terraform Core to meet this use-case. Instead, the AWS provider would need to somehow expose the credentials it allocated for use elsewhere in Terraform.

[deitch]

Thanks @apparentlymart . Will look there.

[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.