You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Apply the change.
The key has now been uploaded and attached to the user.
Now change the file from first.pub to second.pub
Run terraform plan
It will show that the resource is going to be updated because the public_key field is different. You can see the first -> second in the plan, as expected.
Run terraform apply
It will show you the change has been applied successfully.
Running terraform plan shows that there are no more change to apply.
Fetch the key with the aws cli
aws iam list-public-ssh-key --user-name nico
aws iam get-public-ssh-key --user-name nico --ssh-public-key-id <id>
and see that the key is the first one, not the second.
2016/11/16 15:18:22 [DEBUG] Checking resource noop: aws_iam_user_ssh_key.nico2
2016/11/16 15:18:22 [DEBUG] No diff, not a noop
Debug Output
I have logs but they have a lot of resources in them and scrubbing them will take time.
Given the code and the fact that the bug is easy to reproduce I don't think my logs are required, but let me know if you need them.
Expected Behavior
Since the field can't be updated, terraform should flag the resource in the plan and force the user to delete and recreate it. Automatically deleting and recreating the key is another option but would result in a different id generated which might not be safe?
In any case it shouldn't look like the key was updated successfully.
Actual Behavior
See above
Steps to Reproduce
See above
The text was updated successfully, but these errors were encountered:
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.
ghost
locked and limited conversation to collaborators
Apr 10, 2020
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Terraform Version
terraform 0.7.7
(looking at the source in master and changelog this should affect 0.7.11 as well)
Affected Resource(s)
aws_iam_user_ssh_key
Terraform Configuration Files
First generate 2 ssh keys and save them as
first
andsecond
in the current folderApply the change.
The key has now been uploaded and attached to the user.
Now change the file from
first.pub
tosecond.pub
Run terraform plan
It will show that the resource is going to be updated because the
public_key
field is different. You can see thefirst -> second
in the plan, as expected.Run terraform apply
It will show you the change has been applied successfully.
Running terraform plan shows that there are no more change to apply.
Fetch the key with the aws cli
and see that the key is the
first
one, not the second.This is because the AWS api doesn't allow an update to the
public_key
field, only the status, as documented here https://docs.aws.amazon.com/cli/latest/reference/iam/update-ssh-public-key.htmlLooking at the terraform code https://github.com/hashicorp/terraform/blob/master/builtin/providers/aws/resource_aws_iam_user_ssh_key.go#L102 You can see that the resource is only updated if
status
has changed. The debug log showsDebug Output
I have logs but they have a lot of resources in them and scrubbing them will take time.
Given the code and the fact that the bug is easy to reproduce I don't think my logs are required, but let me know if you need them.
Expected Behavior
Since the field can't be updated, terraform should flag the resource in the plan and force the user to delete and recreate it. Automatically deleting and recreating the key is another option but would result in a different id generated which might not be safe?
In any case it shouldn't look like the key was updated successfully.
Actual Behavior
See above
Steps to Reproduce
See above
The text was updated successfully, but these errors were encountered: