Smart Rule Resource Proposal

[harhan]

When working with DevOps Teams, used to develop with cloud native options, we need a smart resource that finds/creates host/group/service objects and puts them into the rule in a single resource.

In case a object is not found the provider has to create the object based on a set templates for names, tags etc, so we easily can create rules without knowing if a host, service, network object exists in the object database.

Take the azurerm_firewall_policy_rule_collection_group resource for instance. It is very easy to create a loop that creates all the element in one resource.

PS! Even if one can disable warnings and create duplicate objects, this is not a recommended approach and is still a lot more complex than the one resource approach.

[b-diggity]

@harhan - it would be interesting to see if something like that is possible here given how management is structured. That said, we also had to solve this problem and here's what we did. All our Terraform is in GitHub and changes are made via our pipeline (GitHub Actions). Our Terraform projects are split between a number of different repos, some interacting with overlapping MDS domains and others interacting with different domains. We also have some repos that have multiple projects in the same repo split up by folder structure. The goal of the setup was for our dev ops community to be able to contribute their changes and here lies our first problem: objects.

• We ignore warnings on resources to allow duplicate IP objects/services (which you called out)
• We require a "repo code" variable that is a unique string that gets appended to the name of any object created by the repo. This prevents errors for duplicate names across repos. It also allows us to easily track which repo created the object in SmartConsole. The repo code is an env var we set in our pipeline, which Terraform pulls in (example: set TF_VAR_repocode="azure" and then on the resource, name = "myobj_${var.repocode}").
• Instead of building a boat load of resources for services, we put this into a module and we just pass in a list of ports, the repo code and the protocol. This results in two modules (one tcp, one udp) with a list of ports. We point out the naming standard the module uses when creating a new service so the rule can be defined. The module just does a for_each on the list passed in. Engineers can quickly look at the list to see if their port is there. If not, they just need to add the port number to the list as a string. It's important to use a depends_on on the rule resource for the services module since we have to use the name of the service and not the implicit reference. If you didn't want a module, you could achieve the same thing by defining a local that's a list of ports and doing a for_each on the resource.
• We added some common port names to the README so users know they don't need to be built (ssh, https, postgres, etc) and those names can be used on their rule.
• Each object type has its own .tf file for organization. (network.tf, service.tf, etc)

In the end, if a host, network, service or group doesn't exist in a repo, it gets created, repo code appended. The only thing we decided to risk conflicts on are access roles but we haven't seen one yet.

Now that we solved our services problem, we decided to abstract our access rule resources into a module to provide standardization. There are lots of settings that can be set, some we don't care about and some settings we do care about. The average user cares about 3 things. Source, destination and service. We just added those as inputs to the module (each a list), along with the layer, position, name and optional comments. This created a streamlined rule setup in each repo where we only have the pertinent info per module (access rule).

We also broke each possible zonal traffic flow on the firewall into an in-line layer and then made each traffic flow it's own .tf file for readability and understanding by the community. For example, internet.tf, datacenter_to_cloud.tf, cloud_to_datacenter.tf, etc.

This setup has served us well for firewalls deployed in the public cloud and firewalls on prem.

I hope this info is helpful!

[harhan]

Thank you for the feedback, very useful. I've been thinking something similar, though on a smaller scale.

The problem is still that while all this is achievable, the independent DevOps teams just scoff at the complexity and say Azure Firewall is good enough ...

[deutmeyerbrianpfg]

My guess is that the API would need to support this before the Terraform provider can support it...

[harhan]

The API supports this just fine. I just made all the smart stuff in python, exported that to JSON and use the terraform provider as a state machine until CP improves the provider so it can be competitive with Azure and GCP offerings.
The customer has a baseline requirement to use Terraform.

[b-diggity]

Interesting... can you share which API call allows this? I took a look at the api doc but didn't see one that stood out.

[harhan]

@b-diggity; I have a JSON file containing the rules and groups of ip objects, then use a python script to query the management database for existing objects and prepare tfvars in json format for any objects that are not available. Any custom object is marked with an automation tag to prevent manual users from meddling.

When you look at other providers, like the resource azurerm_linux_virtual_machine, it is possible to create virtual disks, interfaces etc inside one resource.

I think CP has to solve this in another manner, which probably requires new API calls; it might be time to make the rulebase automation friendly by removing the concept of network and service objects all together when automation is used. Maybe by using the features that are used for dynamic objects?
For instance one can create a rule with "automation flags" enabled and ephemeral source and destination objects connected to this rule. The objects disappear as soon as the rule is deleted.
Any rule created with an automation flag is read only in Smart Console and can only be deleted through the API.

[b-diggity]

Yup! That's Exactly my point. I like the idea but their API would need to support it first so terraform can interact with said api. Anyway, +1!

[chkp-alonshev]

Hi @harhan ,
As mentioned by @b-diggity , this feature is a great idea, but unfortunately it is not yet supported by the API.
We will support it as soon as the API will.

Thank you,
Alon

[harhan]

I've made a request to the local office.
This lack of feature parity with cloud native solutions is causing the devops teams to select other security vendors.