CNGFW Plugin VM-Auth-Key FAQs

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements

Content translations are temporarily unavailable due to site maintenance. We apologize for any inconvenience. Visit our blog to learn more.

L4 Transporter
No ratings

Overview:

 

Today, Cloud NGFW deployed in Azure requires validation when being managed by Panorama. This is done through VM Auth-key. The Auth-key has an expiration date of maximum up to 1 year. Up until now, Customers were required to make sure the auth-key is not expired. However, Cloud NGFW being a Service, we would like to take care of the auth-key renewal also. Hence for the customers who have VM Auth-key expired, we need one time help to get it regenerated. Post which this will no longer be a requirement for the customers. The following FAQ can clarify more on this topic and what needs to be done in order to take advantage of this improvement. 

 

FAQ:

 

  1. Why is the customer authkey showing either expired or not matching?

The original vm-auth-key created for azure CNGFW is of maximum possible lifetime which is 365 days. Once this time elapses that specific key gets expired. And thus shows expired. Before the azure-5.2.0 plugin, SRE had to manually update the backend with a new auth-key that was generated. Additionally, before the azure-5.2.0 plugin implementation, a new registration key was getting generated on clicking the ‘generate’ button. Hence every time a new auth-key was generated, the customer would have not known that this key has to be manually updated in our backend. Hence the mismatch status.

 

2. What is the consequence of not updating the auth-key?

 

VM-auth-key is used only once during FW boot-up. Once the firewall is up and running, even if the auth-key expires, there is no harm for existing FWs. But for new scale-out instances, this will be a problem as registration to Panorama will fail due to VM-auth-key expiry. (Scale out happens when there can be more traffic on the customer end, this can also occur during upgrades/rolling upgrades initiated by our SRE). 

 

  1. Since the auth-key generated under panorama is not perpetual, is this considered on-going issue for customers with the lower Azure plugin version?

Yes for VM-auth key auto-remediation, we need panorama Azure plugin 5.2.0 or above. Also instances should be running with PanOS 10.2.7-c51 and above. The recommended panorama version is 11.1.0 and above. This is the ideal combination for VM-auth-key auto-remediation to take place else manual intervention is required.

 

  1. What will upgrading Azure plugin 5.2.1 do with respect to expiry/renewal issues?

With the new Azure 5.2.0/5.2.1 plugin, there is a proactive check done by the plugin to see whether there is a valid VM-auth-key present. If not, it regenerates the VM-auth-key. Newly scaled-out instances will pick up the new VM-auth-key. If the key is due for expiry, the plugin will generate a new VM-auth-key before 7 days of its expiry. Azure plugin 5.2.0/5.2.1 would not be able to help environments in which the key has already expired. That would still need manual intervention.

 

  1. Do customers still have to provide a new auth-key even after the 5.2.1 upgrade? If yes, why?

No, if they are running on 10.2.7-c51. Panorama version should be 11.1.0 and above



Rate this article:
  • 246 Views
  • 0 comments
  • 0 Likes
Register or Sign-in
Contributors
Article Dashboard
Version history
Last Updated:
‎12-04-2024 11:57 AM
Updated by: