Cannot import template-instantiated custom policies (isDefault=false, templateId!=0)

[ArdzivBullish]

Summary

The provider has no first-class way to bring a Sysdig policy that was instantiated from a Sysdig-provided template (isDefault: false, templateId != 0) under Terraform management. Both candidate resource types reject the import:

• sysdig_secure_custom_policy.Import errors with "unable to import policy that is not a custom policy" because of:

  if policy.IsDefault || policy.TemplateID != 0 {
      return nil, errors.New("unable to import policy that is not a custom policy")
  }

• sysdig_secure_managed_policy exposes no Importer, and terraform import errors with "resource sysdig_secure_managed_policy doesn't support import". The Create handler is also strict — it requires IsDefault: true, so it cannot adopt a template-instantiated customer-owned policy either.

This leaves a gap: a real category of customer-owned policies (instantiated from a Sysdig template but customer-managed thereafter) cannot be brought under Terraform management via either resource type.

Reproduction

1. In the Sysdig UI, create a new policy by clicking "Add Policy" → choose one of the Sysdig-provided templates (e.g. "Sysdig Runtime Notable Events").

2. Confirm via API that the resulting policy has isDefault: false, templateId: <non-zero>.

3. In Terraform, declare the resource and an import { ... } block:

   resource "sysdig_secure_custom_policy" "example" {
     name = "Notable Events Customised"
     type = "falco"
     # ...
   }
   
   import {
     to = sysdig_secure_custom_policy.example
     id = "<policy_id>"
   }

4. Run terraform plan → Error: unable to import policy that is not a custom policy.

5. Switch to sysdig_secure_managed_policy → Error: resource sysdig_secure_managed_policy doesn't support import.

Suggested fix (either approach unblocks the gap)

1. Add an Importer to sysdig_secure_managed_policy that adopts any policy with templateId != 0 (regardless of isDefault). Update the Create handler to also accept isDefault: false policies when templateId != 0.
2. OR relax sysdig_secure_custom_policy.Import so it accepts templateId != 0 policies as long as isDefault: false. The CRUD handlers already treat them as customer-owned (they're not Sysdig defaults; the customer can edit them), so this is a relatively small change.

Versions affected

• Provider 3.8.1 (latest at time of writing). Confirmed by reading provider source at master.

Workaround

The affected policies can currently only be managed via the Sysdig UI. Terraform imports must skip them, leaving the only meaningful operator interactions (disabling individual rules, adjusting enabled / scope / notification_channels) outside GitOps coverage.

[aaronm-sysdig]

Hi @ArdzivBullish

Looking at the above, please let me know if I haven't understood the problem correctly but i think you're wanting to create a copy of one of our managed policies and then customise from there? If that's right, could you please review the below (working) tf snippet and let me know if you feel it meets your requirement(s)?

It copies an existing managed policy, disables one rule, and scopes it to an example kubernetes.cluster.name = "prod"

  terraform {
    required_providers {
      sysdig = {
        source  = "sysdiglabs/sysdig"
        version = ">= 1.50"
      }
    }
  }

  provider "sysdig" {}

  # Demo for issue #736:
  # Create a customer-owned copy of "Sysdig Runtime Notable Events"
  # (a Sysdig-managed default policy, isDefault: true, templateId: 1398).
  #
  # sysdig_secure_managed_ruleset is purpose-built for this situation: a
  # customer-owned policy that inherits an existing Sysdig-managed ruleset.
  resource "sysdig_secure_managed_ruleset" "notable_events_prod" {
    name        = "Issue #736 demo - Notable Events (prod scope)"
    description = "Customer-owned copy of Sysdig Runtime Notable Events, scoped to production workloads with one rule disabled to demonstrate ruleset-level customisation."

    inherited_from {
      name = "Sysdig Runtime Notable Events"
      type = "falco"
    }

    enabled  = true
    severity = 4
    scope    = "kubernetes.cluster.name = \"prod\""

    # Locked ruleset - you can disable rules but cannot add/edit/remove
    # them with a managed ruleset.
    disabled_rules = [
      "Modify ld.so.preload",
    ]
  }

The provider has three policy resources, partitioned by the isDefault / templateId fields the API returns:

• sysdig_secure_managed_policy -> for tweaking Sysdig's own default policies in place (isDefault: true)
• sysdig_secure_custom_policy -> for fully customer-authored policies with no template link (templateId: 0)
• sysdig_secure_managed_ruleset > for customer-owned policies that inherit a Sysdig ruleset (isDefault: false, templateId != 0), which is the case you hit I believe

That's why the two resources you tried rejected the import. Equally, import { ... } blocks against sysdig_secure_managed_ruleset work for adopting policies you've already created in the UI.

I think there's a gap in the docs here — secure_custom_policy.md and secure_managed_policy.md don't cross-reference secure_managed_ruleset.md, which is why this resource is easy to miss. I'll take care of a PR to fix this up - apologies.

[ArdzivBullish]

noted thanks for the gap analysis and workaround - i will give it a try

[ArdzivBullish]

Confirmed working end-to-end on all four affected policies in our tenant — thanks @aaronm-sysdig for the fast and detailed reply.

For anyone landing here later, the resource takes both terraform apply (Create) and terraform import cleanly:

resource "sysdig_secure_managed_ruleset" "example" {
  name        = "<your customised copy name>"
  description = "..."
  severity    = 4

  inherited_from {
    name = "Sysdig Runtime Notable Events"   # or "Sysdig K8s Notable Events", etc.
    type = "falco"                            # or "k8s_audit", matching the parent template's type
  }

  lifecycle {
    ignore_changes = [enabled, scope, disabled_rules, notification_channels]
  }
}

import {
  to = sysdig_secure_managed_ruleset.example
  id = "<policy_id>"
}

The docs PR in #737 is exactly the right fix — secure_custom_policy.md and secure_managed_policy.md cross-referencing secure_managed_ruleset.md would have saved us a couple of failed plan iterations. Feel free to close this once #737 merges.