User and Project Update Fails

[jpautz]

Terraform Version and Provider Version

Terraform v1.5.3

required_providers {
  wiz = {
    source  = "AxtonGrams/wiz"
    version = "~> 1.1.4"
  }
}

Affected Resource(s)

• wiz_user
• wiz_project

Expected Behavior

User and Projects should handle update in place

Actual Behavior

Users and Projects fail to update in place

Steps to Reproduce

Normal Terraform use

Important Factoids

Digging through the Wiz API Console and Audit Logs I am able to see what Wiz expects for the GraphQL queries. The update functions for these resources are out of date and do not match what is presented in the API Console.

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

[jschoombee]

could you add more info around behaviour and include any steps to reproduce?

[jpautz]

Using

terraform {
  required_providers {
    wiz = {
      source  = "AxtonGrams/wiz"
      version = "~> 1.1.5"
    }
  }
}

provider "wiz" {}

resource "wiz_user" "bobsmith" {
  email    = "[email protected]"
  name     = "bob smith"
  role     = "PROJECT_READER"
  assigned_project_ids = ["<PROJECT_ID>"]
}

plan and apply then update to be

resource "wiz_user" "bobsmith" {
  email    = "[email protected]"
  name     = "bob smith"
  role     = "DOCUMENTATION_READER"
  assigned_project_ids = ["<PROJECT_ID>"]
}

plan and apply will create the following state

{
  "version": 4,
  "terraform_version": "1.5.3",
  "serial": 14,
  "lineage": "68b385f2-6374-7a9b-4d70-e2af0dd975d3",
  "outputs": {},
  "resources": [
    {
      "mode": "managed",
      "type": "wiz_user",
      "name": "bobsmith",
      "provider": "provider[\"registry.terraform.io/axtongrams/wiz\"]",
      "instances": [
        {
          "schema_version": 0,
          "attributes": {
            "assigned_project_ids": [
              "<PROJECT_ID>"
            ],
            "email": "[email protected]",
            "id": "<USER_ID>",
            "name": "bob smith",
            "role": "DOCUMENTATION_READER",
            "send_email_invite": false
          },
          "sensitive_attributes": [],
          "private": "bnVsbA=="
        }
      ]
    }
  ],
  "check_results": null
}

Note how however the Role is a global role and therefore does not need a list of project scopes, none the less it is persisted to state.

Following this by changing the role back to PROJECT_READER and plan will result in

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # wiz_user.bobsmith will be updated in-place
  ~ resource "wiz_user" "bobsmith" {
        id                   = "<USER_ID>"
        name                 = "bob smith"
      ~ role                 = "DOCUMENTATION_READER" -> "PROJECT_READER"
        # (3 unchanged attributes hidden)
    }

Note the projects IDs are missing because they are not changing. This will then cause apply error

╷
│ Error: user update reported errors
│ 
│   with wiz_user.bobsmith,
│   on main.tf line 12, in resource "wiz_user" "bobsmith":
│   12: resource "wiz_user" "bobsmith" {
│ 
│ Response: [
│       {
│               "message": "Project scoped role ProjectReader must have assigned projects",
│               "extensions": {
│                       "code": "INTERNAL",
│                       "exception": {
│                               "message": "Project scoped role ProjectReader must have assigned projects",
│                               "path": [
│                                       "updateUser"
│                               ]
│                       }
│               }
│       }
│ ]
╵

[jpautz]

Using

terraform {
  required_providers {
    wiz = {
      source  = "AxtonGrams/wiz"
      version = "~> 1.1.5"
    }
  }
}

provider "wiz" {}

resource "wiz_project" "project" {
  name        = "testing"
  description = "testing"

  risk_profile {
    business_impact = "MBI"
    is_regulated = "YES"
    regulatory_standards = ["HIPPA_HITECH"]
  }
  
  cloud_account_link {
    cloud_account_id = "<PROJECT_ID>"
    environment      = "DEVELOPMENT"
    shared           = false
  }
}

plan and apply work great...

make no changes...

plan again shows a diff

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # wiz_project.project will be updated in-place
  ~ resource "wiz_project" "project" {
        id                 = "<PROJECT_ID>"
        name               = "testing"
        # (6 unchanged attributes hidden)

      ~ risk_profile {
          ~ regulatory_standards  = [
              - "HIPAA_HITECH",
              + "HIPPA_HITECH",
            ]
            # (9 unchanged attributes hidden)
        }

        # (1 unchanged block hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

This is only for HIPPA_HITECH, not for any other compliance option

[jpautz]

I believe my initial suspicion on graphQl query could be incorrect, however the query does show a delta when compared to the API Console in Wiz.

The wiz_user concern is likely solvable by always populating the project_ids field in the query regardless of the change. (I dont know if this breaks how tf maintains diffs) But if the fields were to be passed then the Wiz API will fail the request appropriately meaning no broken state file

[jschoombee]

I believe my initial suspicion on graphQl query could be incorrect, however the query does show a delta when compared to the API Console in Wiz.

The wiz_user concern is likely solvable by always populating the project_ids field in the query regardless of the change. (I dont know if this breaks how tf maintains diffs) But if the fields were to be passed then the Wiz API will fail the request appropriately meaning no broken state file

I think the best might be validation to avoid getting into this situation in the first place. AFAIK user roles aren't in the schema so if anything can be done to fix this, perhaps simply checking for if the role strings.HasPrefix of PROJECT then to error out in the plan stage. A CustomizeDiff is probably best suited here