cancel
Showing results for 
Search instead for 
Did you mean: 
Create a Post
Highlighted

CloudGuard ARM Template

Hi Community,

I am trying to deploy cloudguard in Azure via ARM templates, but I am hitting an issue with the artifacts location parameters.

As I can see in the template, the artifacts location is no longer hard coded, instead it is using the deployment function to call the artifacts uri.

Long store short, when I run the template installation from local files on my computer, I get the error below saying that the templateLink doesn't exist:error.PNG

Apprantly it happens because the deployment function does not respond with the templateLink information if you run the deployment using local templates.

Anyone ran into this issue before? Trying to install r80.30 using ARM template version below:

"templateVersion": "20190805"

thanks in advance.

0 Kudos
2 Replies

Re: CloudGuard ARM Template

Running into the same issue on Azure with R80.30 manager installation.

Completed the store and downloaded the templates so I could modify them.  

Same issue with the URI missing.

 

Did you happen to find a fix?

 

 

Re: CloudGuard ARM Template

Working with Mike, we understood that this missing URI is supposed to be some secure storage account somewhere in Azure cloud or whatever.  That holds the missing linking template JSON file.  Doing some reverse engineering, I was able to determine that the function of that linking template defines the output for a variable called VNETID.  Once I understood that, I realized that I did not need it because I was not interested in creating a new vNET.  I wanted to use the existing vNET and Subnets ( we were upgrading it from R8010 to R8030 - database export method ).

This is the variable it created which is needed by the deployment output in the main template JSON file:

  "variables": {
    "vnetId": "[resourceId(parameters('virtualNetworkExistingRGName'),'Microsoft.Network/virtualNetworks', parameters('virtualNetworkName'))]"
  },
  "resources": [],
  "outputs": {
    "vnetId": {
      "value": "[variables('vnetId')]",
      "type": "string"
    }
  }

Just a disclaimer - the above might be different for the new R80.30 based template but looking at the R80.20 linking template, I determined it was trying to get the same information, just different access method ( aka more secure with SAS Tokens and various Cloudy speaks ).

Quite honestly.. this could had been done without a linking template but every programmer have their preferences and reason behind it. 

The variable in the main template that is requesting this value is:

Snap 2019-10-17 at 15.46.19.png 

The above value being output by it is being fed to the 'networkInterface' resource in the main template:

Snap 2019-10-17 at 15.44.38.png
 
The 'outputs.vnetId.value' is derived from that linking template outputs.
 
If you can understand this process, then perhaps you can easily replace this with a more static variable entry.  My solution was to extract that data without using linking template, adding this variable ( tweaking is needed to make this work right ) into the main template JSON file:
 

"variables": {
"vnetId": "[resourceId(parameters('virtualNetworkExistingRGName'),'Microsoft.Network/virtualNetworks', parameters('virtualNetworkName'))]"

 

As for needing a new vNET, heres the linking template code ( without the parameters )( Sorry I couldnt paste it cleanly 😞

"resources": [
{
"type": "Microsoft.Network/virtualNetworks",
"apiVersion": "[parameters('apiVersion')]",
"location": "[parameters('location')]",
"name": "[parameters('virtualNetworkName')]",
"properties": {
"addressSpace": {
"addressPrefixes": [
"[parameters('virtualNetworkAddressPrefix')]"
]
},
"subnets": [
{
"name": "[parameters('subnet1Name')]",
"properties": {
"addressPrefix": "[parameters('subnet1Prefix')]"
}
}
]
},
"tags": {
"provider": "[toUpper(parameters('Check_PointTags').provider)]"
}
}
],
"outputs": {
"vnetId": {
"value": "[resourceId('Microsoft.Network/virtualNetworks', parameters('virtualNetworkName'))]",
"type": "string"
}
}
}

You can see that these linking templates only end up gathering the necessary outputs to be extracted for the resources.

I realize this might be a bit more technical for the average user who might not be well versed in ARM Template coding, but that's the gist of it all.

I was also using Azure portal in the Template section to deploy this instead of Powershell - no need to fumble around with Powershell.

0 Kudos