xray_ignore_rule error out when cves and vulnerabilities

[Osazz]

Describe the bug
TF resource xray_ignore_rule fails on plan when cves = [] and vulnerabilities = ["XRAY-170461"] with Conflicting configuration arguments

Requirements for and issue

• Xray Provider version

jfrog/xray v2.0.3

• Terraform Version

Terraform v1.5.2

Terraform Code

resource "xray_ignore_rule" "ignore_rule" {
  notes           = "delete me now test ignore rule iac"
  vulnerabilities = ["XRAY-170461"]
  cves = [] 
 
}

• Terraform Plan Output + Error

╷
│ Error: Conflicting configuration arguments
│
│   with xray_ignore_rule.ignore_rule,
│   on main.tf line 24, in resource "xray_ignore_rule" "ignore_rule":
│   24:   vulnerabilities = ["XRAY-170461"]
│
│ "vulnerabilities": conflicts with cves
╵
╷
│ Error: Conflicting configuration arguments
│
│   with xray_ignore_rule.ignore_rule,
│   on main.tf line 25, in resource "xray_ignore_rule" "ignore_rule":
│   25:   cves            = []
│
│ "cves": conflicts with vulnerabilities

• Expected Behaviour

Plan should be successful

Additional context
If you create ignore rule from UI and you import it using terraform import xray_ignore_rule.ignore_rule <rule-id>

• Your state file will have "cves": null,
• If you do a plan after import, you will get 1 destroyed and cves value changed to []
• So this is is conflicting

[alexhung]

@Osazz In your example, since you don't want to have any cves then you should omit it in the TF configuration. This will also match the imported value of null.

[Osazz]

@Osazz In your example, since you don't want to have any cves then you should omit it in the TF configuration. This will also match the imported value of null.

Here is my full use case , I have existing ignore rules that were created from the UI that I would like to manage using Terraform. Here are the steps I took and how I endup here :

• Import existing resource into IAC and state file looks like this :

"instances": [
        {
          "schema_version": 0,
          "attributes": {
            ...
            "cves": null,
            ...
          }
        }
      ]

• Do a terraform plan ( this should returns no changes)

Terraform will perform the following actions:
# xray_ignore_rule.ignore_rule must be replaced
-/+ resource "xray_ignore_rule" "ignore_rule" {
      ~ author          = "dosagie" -> (known after apply)
      ~ created         = "2023-11-17T18:10:49Z" -> (known after apply)
      + cves            = (known after apply) # forces replacement
      ~ id              = "d169e985-87f8-43f5-4bb8-67f73c76f0ef" -> (known after apply)
      ~ is_expired      = false -> (known after apply)
        # (4 unchanged attributes hidden)

        # (3 unchanged blocks hidden)
    }

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

N.B running apply means new destroying existing resources and creating new one. Not ideal

• Do terraform apply and then check the state file

"instances": [
        {
          "schema_version": 0,
          "attributes": {
            ...
            "cves": [],
            ...
          }
        }
      ]

So that is why I setting cves as [] in the resources so that I dont have to destroy existing resource and I think it should be allowed

[alexhung]

@Osazz Just so I understand correctly, the TF config you have before you import the resource contains cves: []? i.e.

resource "xray_ignore_rule" "ignore_rule" {
  notes           = "delete me now test ignore rule iac"
  vulnerabilities = ["XRAY-170461"]
  cves = [] 
}

If you omit cves attribute in your config, like:

resource "xray_ignore_rule" "ignore_rule" {
  notes           = "delete me now test ignore rule iac"
  vulnerabilities = ["XRAY-170461"]
}

Then import the resource. After that terraform plan shows updates for cves attribute?

The Xray APIs don't allow updating an existing ignore rule. Thus any mismatch of TF configuration and API data will mean the provider destroys and recreates new resource.

[Osazz]

@alexhung No that understanding is not correct. I have a TF config like this :

resource "xray_ignore_rule" "ignore_rule" {
  notes           = "delete me now test ignore rule iac"
  vulnerabilities = ["XRAY-170461"]
}

• I do an import and then i get state file like this

"instances": [
  {
    "schema_version": 0,
    "attributes": {
      ...
      "cves": null,
      ...
    }
  }
]

• then I do plan to make sure thing align and I get

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
-/+ destroy and then create replacement

Terraform will perform the following actions:

  # xray_ignore_rule.ignore_rule must be replaced
-/+ resource "xray_ignore_rule" "ignore_rule" {
      ~ author          = "someauthor" -> (known after apply)
      ~ created         = "2023-11-17T18:30:29Z" -> (known after apply)
      + cves            = (known after apply) # forces replacement
      ~ id              = "91ced9b-bb1e-4d9c-488c-6bf093a36d64" -> (known after apply)
      ~ is_expired      = false -> (known after apply)
        # (4 unchanged attributes hidden)

        # (3 unchanged blocks hidden)
    }

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

Changes to Outputs:
  ~ author     = "someauthor" -> (known after apply)
  ~ created    = "2023-11-17T18:30:29Z" -> (known after apply)
  ~ id         = "91ced9b-bb1e-4d9c-488c-6bf093a36d64" -> (known after apply)
  ~ is_expired = false -> (known after apply)

• When I go ahead to apply : I get this state file

"instances": [
  {
    "schema_version": 0,
    "attributes": {
      ...
      "cves": [],
      ...
    }
  }
]

What could have stopped the difference would have been me been able to give cves value as [] but then I am running into that conflict error which does not seems to be a conflict as cves = [] is not same as vulnerabilities = ["XRAY-170461"]

The only work around which I could think of was to change the state file manual by making cves=[]. that resulted in No changes. Your infrastructure matches the configuration. but of course this is a bad practice and state file should never be manually updated.

[alexhung]

@Osazz I see. Thanks for the clarification! I'll investigate this issue.

[ipowellBT]

@alexhung any update on this issue?