aws_iam_user_ssh_key incorrectly reports updating of the key value #378
Labels
bug
Addresses a defect in current functionality.
service/iam
Issues and PRs that pertain to the iam service.
Milestone
This issue was originally opened by @hamstah as hashicorp/terraform#10160. It was migrated here as part of the provider split. The original body of the issue is below.
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: