Difficulty adding Exceptions to existing Falco rules

[raserma]

Description

It’s unclear how to add an exception to an existing Falco rule using the Sysdig Terraform provider. Currently, it seems that to add an exception to an existing Falco rule (e.g., "Delete DB Snapshot"), I need to create a new copy of the rule from scratch and then add the exception.

This process requires copying every field from the existing rule, which can lead to redundancy and makes it difficult to maintain parity with the rule updates provided by Sysdig. To simplify this, I attempted to use the sysdig_secure_rule_falco data source to extract the values from the existing rule and avoid hard-coding them.

Here's an example:

resource "sysdig_secure_rule_falco" "aws_db_snapshot_deleted" {
  name        = "AWS Delete DB Snapshot"
  description = data.sysdig_secure_rule_falco.delete_db_snapshot.description
  tags        = data.sysdig_secure_rule_falco.delete_db_snapshot.tags

  # Using the condition and output from the existing rule
  condition = data.sysdig_secure_rule_falco.delete_db_snapshot.condition
  output    = data.sysdig_secure_rule_falco.delete_db_snapshot.output

  # The priority field needs conversion to lowercase as Terraform fails with uppercase
  priority  = lower(data.sysdig_secure_rule_falco.delete_db_snapshot.priority)
  source    = data.sysdig_secure_rule_falco.delete_db_snapshot.source
  
  # Attempting to copy the exceptions block dynamically
  # it doesn't work, values return `null`
  dynamic "exceptions" {
    for_each = data.sysdig_secure_rule_falco.delete_db_snapshot.exceptions

    content {
      name   = exceptions.value.name
      fields = exceptions.value.fields
      comps  = exceptions.value.comps
      values = exceptions.value.values
    }
  }
}

data "sysdig_secure_rule_falco" "delete_db_snapshot" {
    name = "Delete DB Snapshot"
}

While this works for copying most of the rule's fields, I could not find a way to properly copy and reuse the exceptions block. This means I need to recreate the rule entirely, which feels cumbersome and counterintuitive.

Proposed Improvement

I suggest allowing exceptions to be managed as individual resources within the Terraform provider. This would enable referencing existing rules directly and appending or modifying their exceptions without duplicating the rule itself.

Advantages of This Approach

• Avoid redundancy: No need to recreate an entire Falco rule just to add exceptions.
• Seamless updates: Rules remain managed by the Sysdig team, so updates to rules propagate automatically without additional effort on our part.
• Cleaner code: Terraform code becomes simpler and easier to maintain, focusing only on the customizations (like exceptions) instead of duplicating and managing entire rules.

Example Usage

Here's how I envision managing exceptions as separate resources:

resource "sysdig_secure_rule_exception" "delete_db_snapshot_exception" {
  rule_name = "Delete DB Snapshot"
  
  exceptions {
    name   = "new_exception"
    fields = ["ct.user"]
    comps  = ["="]
    values = "example-user"
  }
}

This would:

• Automatically reference the existing Delete DB Snapshot rule.
• Add only the new exceptions block.
• Keep the rule updates managed by Sysdig without disrupting customizations.

Questions

• Is the current approach of duplicating rules the intended workflow for adding exceptions?
• Would you consider supporting exceptions as separate resources in a future release to simplify this use case?

Let me know if additional details or clarifications are needed! Thank you!

[tembleking]

I don't know how feasible is to add single rule exceptions as resources in the terraform provider. The main reason is that the API does not support single exception creation throw API calls, they are added to existing rules. Terraform expects that each managed resource has CRUD endpoints to manage its lifetime.

[raserma]

I don't know how feasible is to add single rule exceptions as resources in the terraform provider. The main reason is that the API does not support single exception creation throw API calls, they are added to existing rules. Terraform expects that each managed resource has CRUD endpoints to manage its lifetime.

Thank you for the explanation, @tembleking. It initially made more sense to me to treat exceptions as independent resources to avoid needing to recreate the entire rule from scratch.

However, I may have misunderstood how to create Falco rules using the provider. Could you clarify the process? Specifically:

1. When adding an exception to an existing Falco rule, is it necessary to create a completely new rule?
2. Is there a way to reference an existing rule rather than recreating it?

When I try to use the Data Source for existing Falco rules, I noticed it doesn't return the exception values. Here’s an example of the output I’m getting:

$ terraform console
> data.sysdig_secure_rule_falco.delete_db_snapshot.exceptions
tolist([
  {
    "comps" = tolist([])
    "fields" = tolist([
      "ct.user",
      "ct.region",
    ])
    "name" = "user_region"
    "values" = "null"
  },
])

The exceptions are shown in the Sysdig UI, so they do exist. This Falco rule is one already provided by the Sysdig Team. Is this expected behavior from the Terraform provider? Or is there additional configuration required to retrieve these exception values correctly?

[tembleking]

Regarding your questions:

When adding an exception to an existing Falco rule, is it necessary to create a completely new rule?

You can append exceptions to an existing rule, you don't need to create the whole rule.

Is there a way to reference an existing rule rather than recreating it?

Yes, you can reference an existing rule using the sysdig_secure_rule_falco data source.

If you need more help to understand how to do it, I can create a code example for you in terraform.

[tembleking]

There's already an example in the tests we have to validate the provider:

terraform-provider-sysdig/sysdig/resource_sysdig_secure_rule_falco_test.go

Lines 453 to 463 in fa105cf

	resource "sysdig_secure_rule_falco" "attach_to_cluster_admin_role_exceptions" {
	name = "Terminal shell in container" # Sysdig-provided
	append = true
	exceptions {
	name = "proc_name_%s"
	fields = ["proc.name"]
	comps = ["in"]
	values = jsonencode([["sh"]])
	}
	}`, name)

[tembleking]

A couple more examples:

terraform-provider-sysdig/sysdig/resource_sysdig_secure_rule_falco_test.go

Lines 526 to 536 in fa105cf

	resource "sysdig_secure_rule_falco" "okta_append" {
	name = "User changing password in to Okta"
	source = "okta"
	append = true
	exceptions {
	name = "actor_name"
	fields = ["okta.actor.name"]
	comps = ["="]
	values = jsonencode([ ["user_b"] ])
	}
	}`

terraform-provider-sysdig/sysdig/resource_sysdig_secure_rule_falco_test.go

Lines 555 to 565 in fa105cf

	resource "sysdig_secure_rule_falco" "github_append" {
	name = "Github Webhook Connected"
	source = "github"
	append = true
	exceptions {
	name = "user_name"
	fields = ["github.user"]
	comps = ["="]
	values = jsonencode([ ["user_c"] ])
	}
	}`