Include access_key, secret_key, and session_token in aws_caller_identity

[twang817]

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

Ex:

provider "aws" {}
data "aws_caller_identity" "current" {}

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

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

Fixes #8242
Release note for CHANGELOG:

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

Output from acceptance testing:

$ make testacc TESTARGS='-run=TestAccXXX'

...

[twang817]

Having a little trouble running tests on my dinky laptop. Will try again on a bigger machine when I get the chance.

[jamroks]

Hi ,

Can we have an update on this issue, is it good enough to be merged or is there anything still blocking in order for it to be reviewed and merge ?

Thanks for clarification

[AyliD]

Any update on that?

[zopanix]

@bflad Is it possible to have this reviewed ?

[twang817]

I wrote this PR, but having recently been more involved with my company's security organization, I don't believe that this is a good solution to the problem.

Having keys stored in the tfstate, even if temporary, is a generally bad idea. Even worse, this implementation doesn't give users that may need aws_caller_identity a choice. Users could unwittingly publishing their potentially long-term keys through their tfstate into an unencrypted S3 bucket (or worse, Github!).

A slightly better solution would be to break this out into a separate data resource that can be used explicitly to fetch keys for those that are unconcerned with the security implications. I mentioned that I had done this in my last comment in #8242. I will close this and open a new PR with those changes.

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