_This issue was originally opened by @knope as hashicorp/terraform#14575. It was migrated here as part of the provider split. The original body of the issue is below._
Hi there,
0.9.2
output "iamaccesssecret64" {
value = "${aws_iam_access_key.user.encrypted_secret}"}
yields the expected output
iamaccesssecret64 = dGhpc2lzYXNlY3JldGtleS4uLm9yc29tZXRoaW5nCg==
output "iamaccesssecret64" {
value = "${aws_iam_access_key.user.encrypted_secret}"}
yields no output in STDOUT outputs and the tfstate file does not show that the output was created either, however, the key was clearly created for the user
i.e.:
"aws_iam_access_key.user": {
"type": "aws_iam_access_key",
"depends_on": [
"aws_iam_user.user"
],
"primary": {
"id": "someidandstuff",
"attributes": {
"id": "someidandstuff",
"secret": "somesecretkeyandstuff",
"ses_smtp_password": "someseskeyandstuff/mr0KhS",
"status": "Active",
"user": "username"
},
"meta": {},
"tainted": false
},
"deposed": [],
"provider": ""
},
I am unable to recreate this issue with terraform 0.9.11
My config
variable "region" {
default = "us-east-1"
}
provider "aws" {
region = "${var.region}"
assume_role {
role_arn = "arn:aws:iam::1234567890:role/admin_access_role"
}
}
resource "aws_iam_access_key" "lb" {
user = "${aws_iam_user.lb.name}"
pgp_key = "keybase:puneeth"
}
resource "aws_iam_user" "lb" {
name = "loadbalancer"
path = "/system/"
}
output "secret" {
value = "${aws_iam_access_key.lb.encrypted_secret}"
}
This outputs the encrypted secret key which I am able to decrypt with keybase.
terraform output secret | base64 --decode | keybase pgp decrypt
I think I was just missing the keybase part. 🤦♂️
This can be closed down now I think :)
Yes thought so. You need to give it a base 64 encoded PGP key or a Keybase ID
This can be closed down now I think :)
The lack of any error message complaining about the key could reasonably be regarded as a bug. Ideally the key would be verified at the plan stage.
We are currently having this issue as well, but with aws_iam_user_login_profile - in our case aws_iam_access_key works.
Terraform Terraform v0.10.0
Example which gives and encrypted key, and ID, but an empty password:
variable "region" {
default = "us-east-1"
}
provider "aws" {
region = "${var.region}"
assume_role {
role_arn = "arn:aws:iam::1234567890:role/admin_access_role"
}
}
resource "aws_iam_user" "user" {
name = "user"
path = "/"
force_destroy = true
}
resource "aws_iam_access_key" "user" {
user = "${aws_iam_user.user.name}"
pgp_key = "keybase:keybase_username"
}
resource "aws_iam_user_login_profile" "user" {
user = "${aws_iam_user.user.name}"
pgp_key = "keybase:keybase_username"
}
output "password-user" {
value = "${aws_iam_user_login_profile.user.encrypted_password}"
}
output "key-user" {
value = "${aws_iam_access_key.user.id}"
}
output "secret-user" {
value = "${aws_iam_access_key.user.encrypted_secret}"
}
Example output:
Apply complete! Resources: 0 added, 3 changed, 0 destroyed.
Releasing state lock. This may take a few moments...
Outputs:
password-user =
key-user = AKIADSAKJLKADSFQ
secret-user = YnVsbHNoaXRhc2Rhc2zDtmtkw7ZzYWxkYXNidWxsc2hpdGFzZGFzbMO2a2TDtnNhbGRhc2J1bGxzaGl0YXNkYXNsw7ZrZMO2c2FsZGFzYnVsbHNoaXRhc2Rhc2zDtmtkw7ZzYWxkYXNidWxsc2hpdGFzZGFzbMO2a2TDtnNhbGRhc2J1bGxzaGl0YXNkYXNsw7ZrZMO2c2FsZGFzYnVsbHNoaXRhc2Rhc2zDtmtkw7ZzYWxkYXNidWxsc2hpdGFzZGFzbMO2a2TDtnNhbGRhc2J1bGxzaGl0YXNkYXNsw7ZrZMO2c2FsZGFzYnVsbHNoaXRhc2Rhc2zDtmtkw7ZzYWxkYXNidWxsc2hpdGFzZGFzbMO2a2TDtnNhbGRhc2J1bGxzaGl0YXNkYXNsw7ZrZMO2c2FsZGFzYnVsbHNoaXRhc2Rhc2zDtmtkw7ZzYWxkYXNidWxsc2hpdGFzZGFzbMO2a2TDtnNhbGRhc2J1bGxzaGl0YXNkYXNsw7ZrZMO2c2FsZGFz=
Hi all,
You're right that it's a bug that no error message was produced in this case. That bug is due to hashicorp/terraform#9080, where currently all errors during evaluation of an output are silently ignored as a side-effect of how outputs can get evaluated before all of their referenced variables have been updated. We do intend to fix this after we've done some foundational work to improve how outputs are handled, but since we're already tracking that in a core bug, and it seems like the AWS-specific portion of this was explained, I'm going to close this one to consolidate the discussion over there.
There's some additional trickiness here in that the encrypted_secret attribute's presence is based on the presence of pgp_key, which Terraform's diff logic is currently not sophisticated enough to detect at plan time. hashicorp/terraform#8769 may help with this by allowing this resource to mark the unset-ness of encrypted_secret in the diff, thus allowing the later check of the output expression to fail during plan. (Today, it'll get seen as <computed> during plan, because Terraform core can't predict whether or not encrypted_secret will be set without the provider's help.)
In general, if you see missing outputs like this on the root module it can be instructive to run terraform console and try to evaluate the output expression (without the ${ and } delimiters) there. Errors are _not_ suppressed in the console, so often the error message shown there can help explain what's going on.
@apparentlymart close #1394 as well? :)
I still have the same issue.
Terraform version: Terraform v0.11.1
This works fine:
resource "aws_iam_access_key" "accesskey" {
user = "${aws_iam_user.user.name}"
pgp_key = "${var.pgp_key}"
}
output "secretkey" {
value = "${aws_iam_access_key.accesskey.encrypted_secret}"
}
var.pgp_key is a variable where I declare a Base64 encoded PGP public key. It works for the Secret Key, but it doesn't work for the password.
resource "aws_iam_user_login_profile" "login_profile" {
user = "${aws_iam_user.user.name}"
pgp_key = "${var.pgp_key}"
}
output "password" {
value = "${aws_iam_user_login_profile.login_profile.encrypted_password}"
}
The output is empty for that one.
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!
Most helpful comment
Hi all,
You're right that it's a bug that no error message was produced in this case. That bug is due to hashicorp/terraform#9080, where currently all errors during evaluation of an output are silently ignored as a side-effect of how outputs can get evaluated before all of their referenced variables have been updated. We do intend to fix this after we've done some foundational work to improve how outputs are handled, but since we're already tracking that in a core bug, and it seems like the AWS-specific portion of this was explained, I'm going to close this one to consolidate the discussion over there.
There's some additional trickiness here in that the
encrypted_secretattribute's presence is based on the presence ofpgp_key, which Terraform's diff logic is currently not sophisticated enough to detect at plan time. hashicorp/terraform#8769 may help with this by allowing this resource to mark the unset-ness ofencrypted_secretin the diff, thus allowing the later check of the output expression to fail during plan. (Today, it'll get seen as<computed>during plan, because Terraform core can't predict whether or notencrypted_secretwill be set without the provider's help.)In general, if you see missing outputs like this on the root module it can be instructive to run
terraform consoleand try to evaluate the output expression (without the${and}delimiters) there. Errors are _not_ suppressed in the console, so often the error message shown there can help explain what's going on.