Non-descript error message when IAM permissions are too restrictive.

[hashibot]

This issue was originally opened by @clstokes as hashicorp/terraform#2875. It was migrated here as part of the provider split. The original body of the issue is below.

---

When running a Terraform plan or apply using AWS keys that do not have sufficient permission, an error message occurs. The error message is sometimes descriptive enough to instruct the user of the permission that is needed, but in some cases it isn't.

When managing S3 buckets, if the IAM user does not have s3:GetBucket* permissions, a Terraform execution will result in a generic Access Denied message. Terraform should provide context of the provider API call when the API call fails so that the user knows which operation failed and can troubleshoot it - eg. Error while calling [S3 GetBucketLocation] - 403 Access Denied.

Terraform Output

$ terraform apply
aws_s3_bucket.bucket_test: Refreshing state... (ID: test_bucket_123321)
Error refreshing state: 1 error(s) occurred:

* 1 error(s) occurred:

* AccessDenied: Access Denied
    status code: 403, request id: []
$

Terraform Configuration

variable "access_key" {}
variable "secret_key" {}
variable "region" {}

provider "aws" {
    access_key = "${var.access_key}"
    secret_key = "${var.secret_key}"
    region = "${var.region}"
}

resource "aws_s3_bucket" "bucket_test" {
    bucket = "test_bucket_123321"
}

[hashibot]

This comment was originally opened by @kingpong as hashicorp/terraform#2875 (comment). It was migrated here as part of the provider split. The original comment is below.

---

I had this problem today when Terraform was creating a subnet. The error was related to the MapPublicIpOnLaunch, and not the CreateSubnet call as it appeared.

* aws_subnet.public.1: UnauthorizedOperation: You are not authorized to perform this operation.
    status code: 403, request id: []

[hashibot]

This comment was originally opened by @radeksimko as hashicorp/terraform#2875 (comment). It was migrated here as part of the provider split. The original comment is below.

---

@kingpong As you pointed out in the attached log, I think the situation is slightly better since @clstokes originally created this issue, because of hashicorp/terraform#2815

Any suggestions on how we can generally improve this apart from pairing up vague error messages from API with relevant resource IDs?

[hashibot]

This comment was originally opened by @kingpong as hashicorp/terraform#2875 (comment). It was migrated here as part of the provider split. The original comment is below.

---

@radeksimko The important piece of missing information is which API call failed. All I could tell was that it had something to do with creating a subnet. But since the account had CreateSubnet privileges, I was left scratching my head. I eventually dove into the Terraform source to figure it out.

[hashibot]

This comment was originally opened by @apparentlymart as hashicorp/terraform#2875 (comment). It was migrated here as part of the provider split. The original comment is below.

---

Maybe this could be improved by having a wrapping error type in the AWS provider, that can be used to easily return a consistent error message:

// ActionError wraps an error returned from an AWS API call to add context about
// which IAM action is relevant to the given API call, to help the user diagnose
// access-related errors.
type ActionError struct {
    // The action name as it would be expressed in an IAM policy
    // e.g. s3:GetBucketLocation, iam:ChangePassword
    ActionName string

    // The error that occured
    Err error
}

func (err *ActionError) Error() string {
    return fmt.Sprintf("%s: %s", err.ActionName, err.Err)
}

@kingpong in your MapPublicIpOnLaunch case, was it just that your credentials lacked access to ModifySubnetAttribute as a whole, or is there a special access control rule for that attribute in particular?

If the former, then we could improve the error handling of that call like this:

if err != nil {
    return &ActionError{"ec2:ModifySubnetAttribute", err};
} else {
    d.SetPartial("map_public_ip_on_launch")
}

This would then result in the following output:

* aws_subnet.public.1: ec2:ModifySubnetAttribute: UnauthorizedOperation: You are not authorized to perform this operation.
    status code: 403, request id: []

According to the EC2 permissions docs, this particular action can't actually be granted directly in an IAM policy and must instead be granted via the ec2:* wildcard, but at least this gives the user some additional info with which to consult the docs and figure out what needs to be added to the policy.

Of course the above setup would annotate non-access-related errors too, where arguably the IAM action name is less relevant, but the action names are usually reasonably human-readable and are likely to still provide some useful context to the user even if some other sort of error is returned.

[hashibot]

This comment was originally opened by @kingpong as hashicorp/terraform#2875 (comment). It was migrated here as part of the provider split. The original comment is below.

---

@apparentlymart: sorry, I'm not sure. I tried adding ModifySubnetAttribute, but as you mentioned, it can't be granted directly so I ended up just giving Terraform free reign.

[github-actions]

Marking this issue as stale due to inactivity. This helps our maintainers find and focus on the active issues. If this issue receives no comments in the next 30 days it will automatically be closed. Maintainers can also remove the stale label.

If this issue was automatically closed and you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. Thank you!

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