add aws_provider_credentials data source

[twang817]

Community Note

• Please vote on this pull request by adding a 👍 reaction to the original pull request comment to help the community and maintainers prioritize this request
• Please do not leave "+1" comments, they generate extra noise for pull request followers and do not help prioritize the request

This allows local-exec provisioners to be able to retrieve the
credentials that the aws provider is using.

Ex:

provider "aws" {
    version = "~> v2.33.1" # to use local copy of terraform-provider-aws
}

data "aws_provider_credentials" "current" {}

resource "null_resource" "my_resource" {
  provisioner "local-exec" {
    command = "echo $AWS_ACCESS_KEY_ID - $AWS_SECRET_ACCESS_KEY - $AWS_SESSION_TOKEN"
    environment = {
      AWS_ACCESS_KEY_ID = "${data.aws_provider_credentials.current.access_key}"
      AWS_SECRET_ACCESS_KEY = "${data.aws_provider_credentials.current.secret_key}"
      AWS_SESSION_TOKEN = "${data.aws_provider_credentials.current.session_token}"
    }
  }
}

Closes #8242

Release note for CHANGELOG:

Allows credentials (access_key, secret_key, and session_token) to be fetched from new data source aws_provider_credentials to be used within local-exec provisioners.

Output from acceptance testing:

$ make testacc TESTARGS='-run=TestAccXXX'

I was not able to run acceptance testing as I don't have access to a personal AWS account. I did run make tests.

[twang817]

Supersedes #8517

[twang817]

Question: Is there a maintenance branch for v0.11 support?

I suspect there are lots of people out there that are stuck on v0.11.x and would appreciate a backport to support this feature.

[bflad]

Question: Is there a maintenance branch for v0.11 support?

I suspect there are lots of people out there that are stuck on v0.11.x and would appreciate a backport to support this feature.

@twang817 all versions of the Terraform AWS Provider including the most recent released today support Terraform CLI 0.11. The only restriction at the moment is Terraform CLI 0.12 requires Terraform AWS Provider version 2.7.0 or higher. We will be deprecating Terraform CLI 0.11 and earlier support at some point in the coming months, but the timing and announcement have not yet occurred.

---

Regarding the content of this pull request, I think its best that we are upfront with saying that we would be hesitant to make it easy to exfiltrate active AWS credentials from a Terraform run. There are valid use cases within Terraform as shown above, but those credentials may be then used completely outside of Terraform's context (e.g. if they are visible to CI logging then anyone with CI log access can see and use them locally). While this is opt-in, setting up controls/policies to block its usage is also opt-in and has to be known, so even having this ability within an officially released Terraform AWS Provider binary may not be acceptable in many organizations.

[twang817]

Being closely involved in security at organization, I wholly understand and appreciate the feedback. It is largely why I have let this PR languish for so long.

We have internally worked around this problem by providing credentials to both Terraform and any local-exec provisioners in a consistent manner. This moves credentials management out of Terraform. It is ugly, and it's not DRY, but it solves the issue and allows us to move forward. Even if this PR is indeed merged, I couldn't say with confidence that our organization would opt in to using the data source, despite the fact that we don't have any long term-credentials, use encrypted state buckets, etc.

I only recently picked this up as there seemed to be some activity and interest on #8517.

Perhaps we can take this opportunity to start a dialog and search for alternative solutions. The set of problems that this solves is relatively common and I suspect there are many who are in more relaxed security contexts and are eager to find a solution.

[zopanix]

Hey, thanks for opening this PR. I also am concerned security whise but it's my best solution to keep things inside terraform. My use case is that EKS is really poorly implemented. For EKS to work you need specific tags on the subnets in which you deploy it. Which is easy enough to do when you're managing the subnets within you terraform code. Unfortunately, VPC infrastructure is handled in a seperate account in my case by another team which leads to the conclusion. I have to partially handle the subnet resources (which is also ugly). Now since the credentials that we use in terraform are temporary (max 1h) I don't mind it being stored in the statefile. In addition, only the terraform credentials are allowed to read the statefile in our case, nobody else has access. I would really appreciate this being resolved becasue without it. I would need to generate additionnal creds outside of terraform and pass these as variables. But in my current use case we use modules a lot. In fact those credentials would the be passed as parameters to 4 modules becasue of dependency handling.

I agree there should be a huge warning sign whether to use this or not and the risks it can bring. But I'm strill convinced that this is still better that working around the problem in another manner.

[bflad]

Hi @zopanix 👋 Would either/both of these EC2 tagging improvements help in your situation?

• New aws_ec2_tag resource (allowing you to manage individual tags on a EC2 resource): Introduce the aws_ec2_tag resource for managing individual tags on EC2 resources #8457
• Provider-wide ignore tags functionality: [Proof of Concept] provider: Ignore tags implementation #10418 (proof of concept) / Implement Provider Ignore Tags Functionality Across All Resources #10689 (full implementation)

[bflad]

Hi again 👋 There hasn't been any additional comments on this functionality for awhile now and the maintainers are still extremely hesitant to merge this in (see #10694 (comment) above), so rather than keeping this pull request open when its not likely to be merged, I'm going to close this. Thanks again for contributing this and please create a new GitHub issue if you wish to discuss this functionality further.

[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 feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thanks!