Possibility to add an object to a group without the group being in my current terraform state

[ex1570almbrand]

Hi All

This is both a question if it can be done in any way with current implementation, in that case I would welcome a solution. Secondly if it is not possible (which is what I assume), then I would ask if it is a feature that you would be interested in to having (I have forked the code and currently working on it as a posibility)

But first let me explain what I have done so far and what I would like to achieve:

What I would like to achieve

Using the checkpoint provider for terraform to update existing groups with network objects specifying a given subnet in our Azure Cloud subscription.

What have we tried out

Experimenting with the checkpoint provider, reading the provider documentation & code and the API documentation, we tried out following terraform configuration:

terraform {   
  required_providers {     
    checkpoint = {        
      version = ">=1.4.0"       
      source = "CheckPointSW/checkpoint"     
    }
  }
}
"checkpoint" {    
  server = ""
  username = "" 
  password = ""
  context = "web_api"
}

resource "checkpoint_management_network" "service_subnet1" {
  name = "net-192.168.2.0-m24"
  subnet4 = "198.168.2.0"
  mask_length4 = 24
}

resource "checkpoint_management_network" "service_subnet2" {
  name = "net-192.168.3.0-m24"
  subnet4 = "198.168.3.0"
  mask_length4 = 24
}

resource "checkpoint_management_group" "group" {
  name = "terraformtestgroup" # We would like to create this group directly in checkpoint, and update it using terraform
  members = [ checkpoint_management_network.service_subnet1.name, checkpoint_management_network.service_subnet2.name ]
}

Then we run publish using the provided excutable to publish the session.

The Problem

The provider resource "checkpoint_management_group" creates a group in checkpoint if it is not present in terraform state. There seems to be no option for updating members of a specific group without managing a group in terraform as well.

Proposed solution

We propose to add functionality to the checkpoint provider allowing management of group memberships seperately of the group, the terraform configuration could look like this:

terraform {   
  required_providers {     
    checkpoint = {        
      version = ">=1.4.0"       
      source = "CheckPointSW/checkpoint"     
    }
  }
}
"checkpoint" {    
  server = ""
  username = "" 
  password = ""
  context = "web_api"
}

resource "checkpoint_management_network" "service_subnet1" {
  name = "net-192.168.2.0-m24"
  subnet4 = "198.168.2.0"
  mask_length4 = 24
}

resource "checkpoint_management_network" "service_subnet2" {
  name = "net-192.168.3.0-m24"
  subnet4 = "198.168.3.0"
  mask_length4 = 24
}

data "checkpoint_management_data_group" "group" {
    name = var.checkpoint_group_name # Input variable
}

resource "checkpoint_management_group_member" "group_subnet1" {
  name = checkpoint_management_data_group.group.name
  member = checkpoint_management_network.service_subnet1.name
}

resource "checkpoint_management_group_member" "group_subnet2" {
  name = checkpoint_management_data_group.group.name
  member =checkpoint_management_network.service_subnet2.name
}

Kind Regards Jakub Iwanczuk

[chkp-royl]

Hi @ex1570almbrand, You can run terraform import command to tell terraform to import that group into state file and then any change to the group will be consider as update. Try this solution and let me know if you still face any problem.

Thanks, Roy

[ex1570almbrand]

Hi @chkp-royl

Thanks for the response. We have the solution you describe as a consideration, however it has pitfalls in our case, so it is not the optimal solution. The reason for it being so is that we maintain a configuration and logic in a terraform module and fwOne groups are part of this configuration. To do it with import it would require us to implement and maintain this configuration and logic both in terraform and outside terraform as imports can be automated using scripts. This leaves us with duplication of configuration and logic that we then need to maintain in parallel. Yes it can be done, but we would rather control and maintain all of this inside terraform (in one place).

I forked you provider project and currently we work on a POC that has the modifications that will give us the result above, but scrictly speaking it goes against the principles stated by HashiCorp saying one API method=one resource/data resource. (We are using the "set-group" operation to modify members of existing group)

Would you consider a change in the provider that would accomodate a solution I have described in the issue or is it totally out of the question? To obey to the principle the checkpoint API could change, but I guess that is a bigger change request that goes outside of the provider project scope.

Kind regards Jakub Iwanczuk

[chkp-royl]

Hi @ex1570almbrand,

Like you said, it's not a good practice. The solution you proposed goes against the principles stated by HashiCorp and we don't find any use case for it. Terraform is open source so if you wish you can add any logic/resource to the provider and use it locally.

Thanks, Roy

[ex1570almbrand]

Hi @chkp-royl

Thanks for a clear answer. So basically to do this change in the provider would require checkpoint to change the API? I will let that go through a different channel.

I can see a use case for this, so I do not agree with on that point. Since it is a good practice to split you terraform IaC implementation in modules, for reuse or to do seperation of concerns in different states. The way the checkpoint provider is organized (and the API) does not leave much room to do that.

Fo us it means that we in practice cannot maintain groups in one statefile, network objects and their relationships to groups with another. Unless we use the terraform import (which is really not a good way for us in this case)

But again thanks for your replies.

Kind regards Jakub Iwanczuk