sysdig_secure_zone_posture_policy_assignment returns 404 for zones served by the platform zones API (v1 fallback)

[jamiezieziula]

Summary

On Sysdig backends that do not expose /platform/v2/zones, sysdig_secure_zone falls back to the platform v1 zones API (/platform/v1/zones, added in #742) and its id attribute is a platform zone ID. sysdig_secure_zone_posture_policy_assignment then POSTs that ID to the CSPM API at /api/cspm/v1/zones/{id}/policies, which is a different ID namespace. The platform zone ID does not resolve there, so every assignment create fails:

Error: error creating zone policy assignment: 404 Not Found

Provider version

• 3.8.2 (observed)
• Endpoint unchanged in 3.9.0 (latest release) and on master, so upgrading does not resolve it.

Relevant source

• Assignment writes to the CSPM API: sysdig/internal/client/v2/zone_policy_assignment.go

  const zonePolicyAssignmentPath = "%s/api/cspm/v1/zones/%d/policies"

• But on the v1 fallback the zone comes from the platform API: sysdig/internal/client/v2/zones.go

  platformZonesPath = "%s/platform/v1/zones"

• The deprecated sysdig_secure_posture_zone uses the CSPM namespace (/api/cspm/v1/policy/zones/{id}) and works, which is consistent with the two zone APIs using distinct ID spaces.

Reproduction

On an account where /platform/v2/zones is not exposed (so sysdig_secure_zone uses the v1 fallback):

resource "sysdig_secure_zone" "example" {
  name = "example"
  scope {
    target_type = "gcp"
    expression {
      field    = "label.environment"
      operator = "in"
      values   = ["prd"]
    }
  }
}

resource "sysdig_secure_zone_posture_policy_assignment" "example" {
  zone_id    = sysdig_secure_zone.example.id
  policy_ids = [14, 7]
}

terraform apply:

1. sysdig_secure_zone.example is created via /platform/v1/zones and gets a platform zone ID.
2. sysdig_secure_zone_posture_policy_assignment.example POSTs /api/cspm/v1/zones/<that id>/policies → 404 Not Found.

Expected behavior

The assignment resource should resolve the zone under whichever API the zone was created in (mirroring the v1/v2 fallback already implemented for sysdig_secure_zone in #742), or the provider should expose a CSPM-side zone ID / data source so the two can be bridged. Failing that, the docs for sysdig_secure_zone_posture_policy_assignment should note it is incompatible with zones created via the v1 platform fallback.

Impact

sysdig_secure_zone + sysdig_secure_zone_posture_policy_assignment is the documented migration path off the deprecated sysdig_secure_posture_zone, but it is not usable on backends that fall back to the v1 zones API. The only working option today is to remain on the deprecated resource.