ID Sharing on AutoScaling

[ChristianCastil]

Use case; since the VMSS setup on Azure allow to customers connect the On-Prem to cloud with Native VPN GW or Express Route and redirect the traffic to the VMSS members (Check Point Gateways), like the next diagram.

Transit vNET based on VMSS

Now let's work on the need to use Identities on the rules and since this comes from the On-Prem, the identities will be based on AD, there is a good way to achieve this, in Check Point exist the ID-Sharing feature, where an On-Prem Check Point Gateway with connectivity to the AD can grab the Login events on the AD and create the list based on AD groups and share this to another GW, so the other GW don't need to reach the AD.

ID Sharing feature explained

But this needs to be configured per GW basis, this in autoscaling scenarios need automation, the CME tool that handles the automation of the CG IaaS deployment also have the capability to customize based on scripts that can run on Management side or GW side.

So I created a bash script that allows to enable the identity sharing on each VMSS new deployed GW.

First we need to enable the capability to share identities on the On-Prem GW, this is done on the Gateway object under Identity Awareness menu.

this is done on the On-Prem previously configured AD-Query GW

Once we prepare this, we need to set up the CME based on CloudGuard Network for Azure VMSS R80.10 and Higher Administration Guide (This link was edited by Check Point on 19 Dec 2021)

Once all is done, we need to download the bash script and pass it to the management, the script is here Github, you can use curl_cli to do it.

curl_cli -k 'https://raw.githubusercontent.com/christiancastilloporras/Indentity-Sharing-with-CME----Check-Point/master/cme_identitysharing.bash' -O

and give it execution permissions.

Then on the CME need to add this file to the Management, make sure to put the correct path;

autoprov-cfg set management -cs 'path/to/script'

Then on the template need to call the Custom Parameter feature, this feature call the management script and pass params to the script, the script uses 5 parameters, the 1 and 2 are passed by the CME by default each time you call this feature ('add' or 'delete' as $1 and newly deployed GW Name as $2), then the script needs an action this should be "IDSHARING", needs the rulebase to install; this needs to be exactly the name of the Policy Package of the deployed Gateways and exactly the GW name where the VMSS will grab identities; all this will setup the next addition to the CME;

autoprov-cfg set template -tn "name-of-template" -cp 'IDSHARING rulebase gwname'

And now every newly deployed GW will have the identities and we can set up rules for the VMSS based on AD Groups.

[PhoneBoy]

In other words, you've figured out how to enable Identity Awareness blade programmatically.
Nicely done!

[JaydenAung]

Awesome!

[ChristianCastil]

actually is focused on ID Sharing, because IA is enabled by the CME with the "-ia" flag on the template.

[D_W]

Very nice input thx!
I was not aware that Identity Shareing isn't already useable by default for automatic deployed VMSS.

What will happen in the following case when I do not use an onPrem CP for Identity Shareing with the VMSS:
2 VMSS GWs (let us call them A and B) are always deployed and have their own DC to collect AD Idenitites. Something happens, for example very high load on the two GWs A and B and a third GW (C) will be deployed. And with the script it knows now where to get the Identities - good. But however, the load is still there, a fourth GW (D) will be deployed. Will GW C and D also share identities? And what happens the GWs A and B are under so much load that they cannot share the IDs to C and D?

I understand that Gaia Settings like add admin users and routes etc must be configured via script after the deployment. But i miss some automation and simplification in this process for the settings that are already done in the Management for the VMSS Gateways.

Is there somewhere a list available where I can see which features have to be configured via script after the deployment of a GW?
Would it be not easier to "copy" the same configuration in the Managemet of the always on VMSS GWs to newly deployed VMSS?

thx
David

[dehaasm]

Hi Christian, I am also looking into this limitation that the CME template is not able to configure some parameters such as the identity agent which i believe still would be the best solution here. The solution you provided is using PDP and share the identities to other firewalls (currently active in VMSS or newly added lateron), however how do you guarantee the High Availability for the PDP because if the PDP gateway has an issue IA is affected as well as rules using access roles. In a "normal" setup you would have a ClusterXL with 2 gateways with PDP enabled which is always available. Is there any other improvement made to accomplish something similar with Azure VMSS?

[ChristianCastil]

hi, ID Agent, are you referering to ID COllector? if that's the case, the ID collector needs a pass peer connection this is not capable with only CME and is truly dificult to automate, since the collector is not connected to any API.

for HA, the script can be modified to use a Cluster as Sharing GW, when I created the script the get simple-cluster API was not there, but I've helped some customers to use it in newer versions.

I went with PDP since the ID Agent (the endpoint that sends info in this case for MUH) only supports 1 IP to communicate with, so you can set the Single GW or Cluster in any other network that is reachable by the agent and then share identities with the VMSS or ASG or MIG members.

[dehaasm]

Hi Christian, yes I mean the ID collector which is also deployed in Azure. We would like to have a High Available PDP inside the VMSS as there is no other gateways present (or not planned for) to retrieve the identities.

I believe we understand the problem, you created a nice solution / workaround but I believe for a ONLY Azure deployment would not suffice when there is a strict requirement for HA with regards to identities.

So there is nothing on the roadmap to be able to automatically enable the Identity log collector on blade settings as well as add it to the collector as well that would be the best I believe we both agree on that.

Thanks for the quick response and thinking with me.

[Norbert_Bohusch]

I tried to see what you are doing in the shell script and see there you have 6 parameters.

But in your explanation above the 6th (policy package name of sharing gw) is not explained/used, there you speak about 5.

So this should be mentioned because currently the install policy on sharing gw will not work.

[ChristianCastil]

yes, the script have been modified several times, since some adaptation has to be done, but yes, basically there is 6 params, where 2 are been passed by the CME bu default, then the sharingGW name and the sharingGW policy package to install.

[Chris_Van_Kriek]

Hello,

I've used this script to configure Identity Sharing on a Cloudguard MiG in GCP. When a new instance is added (out scaling), Identity Sharing is configured, but the sharing GW is not added. Is there a dependency on the version of the API ? We are running 81.20 Cloudguard and the management is R81.10 with JHF Take 95.

[ChristianCastil]

can you explain your architecture?

is the Sharing GW a Cluster?

[Chris_Van_Kriek]

The sharing GW is a vsx node. ID sharing works perfectly when configured on the existing instances of the MiG, with that vsx node as a sharing GW.

[ChristianCastil · Accepted solution]

ok, to obtain the GW_UID of the Sharing Gateway, I use the line 42, in this case it's trying to use the show simple-gateway API, if a cluster is involved you need to change to "show simple-cluster", but for VSX node, I found no API to call the object and obtain the UID, so maybe you can put a fixed value with the UID of the VSX and set it in the Line 47, where I add the sharing gateway with the variable $GW_UID_SH

[Chris_Van_Kriek]

Thanks for the answer, Christian.

There appears to be only one command possible in the mgmt_cli for vsx: mgmt_cli vsx-run-operation

But it does not include something like "get-member" or alike. Any idea how I can retrieve the UID for a vs ?

[PhoneBoy]

I believe show gateways-and-servers will show the objects and their UIDs (even ones without API support like VSX objects): https://sc1.checkpoint.com/documents/latest/APIs/index.html#cli/show-gateways-and-servers~v1.9%20

[Chris_Van_Kriek]

Thanks PhoneyBoy ! I executed the commands in the script one by one and the ID Sharing is configured correctly now, including the sharing GW. I presume running it through the cme will work aswell. Many thanks Dameon and Christian !

Regards,

Chris.

[Chris_Van_Kriek]

I ran the script in cme, but the restrictive policy installation keeps cycling for the added gateway. I also notice that the Identity Awareness blade is not being installed on the added gateway, so the script runs but there is no IA blade. Although IA blade was enabled on the MiG.

custom-parameters: "IDSHARING policy_gcp"
identity-awareness: true

When I remove the script, the policy is installed and a IA blade is available.

Any ideas ?

[Chris_Van_Kriek]

Looks like it is solved now. Thanks all !

[Martin_Valenta]

any reason why this is not official script/feature?

[Nüüül]

Thanks Christian for your script. I changed it a little bit (in case, Sessions have to be named /described for publishing)

https://github.com/leinadred/CP_Identity-Sharing-with-CME/