PagerDuty / terraform-provider-pagerduty

Terraform PagerDuty provider
https://www.terraform.io/docs/providers/pagerduty/
Mozilla Public License 2.0
205 stars 210 forks source link

403 when updating account owner resource, despite using account owner's user-level API key #378

Open katkasian opened 3 years ago

katkasian commented 3 years ago

Terraform Version

Terraform v1.0.5 + provider v1.10.1

Affected Resource(s)

Terraform Configuration Files

resource "pagerduty_user" "main" {
  email = "xxxx@xxxx.com"
  name = "Kat Kasianenko"
  job_title = "test"
  role = "owner"
  lifecycle {
    ignore_changes = [role]
  }
}

Debug Output

Please provider a link to a GitHub Gist containing the complete debug output: https://gist.github.com/katkasian/1ade5d7da6971cf4ccea8e89761b87fc

Expected Behavior

As described in a closed issue related to 403 for attempts to update account owner user resource and a community thread it references, when using a user-level API key created under account owner's profile, one should be able to manage the profile with Terraform.

Actual Behavior

Despite using the user-level API key with account owner permissions, getting a 403. This appears to be related to the fact that the role attribute (owner) is always being passed in the PUT payload to PagerDuty by the provider. When making a PUT request to the account owner profile directly using PagerDuty API, I only get 403 response when including the role property.

Steps to Reproduce

Please list the steps required to reproduce the issue, for example:

  1. Define a pagerduty_user resource with account owner details.
  2. Import account owner terraform import pagerduty_user.main PXXXXX
  3. Change a property of the resource, for example job_title
  4. Run terraform apply and observe a 403 error. If using debug level of logging, also observe how "role":"owner" appears in the PUT request payload.
jhoscar1 commented 2 years ago

Also experiencing this

tmd-tech commented 2 years ago

+1

sudo-dliberty commented 1 year ago

+1

jmehnle commented 1 month ago

This issue still persists in 2024. Are there any plans to fix this or provide a workaround? Right now I can't manage any properties of the account owner user, because the illegal role="owner" attribute is always included in the PUT request.