cp_mgmt_access_rule_facts - does not show all rules

[GitHub2022]

Hi there,

via ansible calling the function cp_mgmt_access_rule_facts implicates that you can see all existing rules. That is not the case. You only see the first layer but when you use inline layer - multiple times - they are not visible. Instead you need to run a very complicated way to read all rules - parse for inline layer and for each inline layer you need to do the same.

Problem is: Ansible is not made for that! So please add this to your library. Otherwise this function is useless when you use inline layer.

[chkp-dorbe]

Hi,

Since Ansible resources rely on the Management API, they are limited to its capabilities. Because our Management API does not support this, it cannot be applied in Ansible playbooks.

In some cases, you can work around this by using loops. Here is a link from the Ansible documentation:

https://docs.ansible.com/ansible/latest/playbook_guide/playbooks_loops.html

Best regards,
Dor

[GitHub2022]

But thats answer is not correct. The idea behind ansible is to have a smooth and readable task management. Ansible was never been developed to loop into infinity section headers or even inline layers. Therefore this library exists - written in python. So please improve your library and implement it the correct way! Show access-list means clearly that this command is displaying all access rules - not half - not with an exclusion of inline layers or whatever. In 2025 it can not be so hard to code something which simply works and does what everybody would expect.

[duanetoler]

The access rulebase is more complicated than it appears on the surface in R80+ because of the unified policy design (integrating many other components plus inline layers and ordered layers). SmartConsole visually combines all these elements for GUI purposes, but they did all the work for you. When parsing the policy programmatically with the API, "things change".

The API server, by default, only returns the first 50 rows. The module has options to return more rows, but this is a trade-off with performance and resources on the server side; "you have been warned". Each "rulebase" is only for a given layer; the default layer is the Network layer (unless your server has been upgraded from pre-R80, in which case it's likely "Security" for the Security policy layer, versus the Application policy layer). Each inline layer is its own "rulebase". This is the point of the Unified Policy.

If you just want to fetch a copy of the rulebases (yes, plural) for your own collection purpose, Ansible is unlikely the right tool for that job. You will be better served writing your own API script for that singular purpose, where you can collect the total number of rules in each rulebase, loop in a respectable fashion against the API server (50 at a time is fine, but you can also pull 100 at a time; I wouldn't go above that, tho), and decode the JSON yourself into whatever fashion you want. Be aware, you will have to decide if you want the API to return UUIDs for every object and use the object dictionary, or not; using the object dictionary is much less work for the API server but it means more work for you. (another trade-off) Again, this is the hard work that SmartConsole does for you behind the scenes (albeit just not with the API; SmartConsole uses another method to communicate with the server).

Ansible is better suited for pulling portions of the rulebase and making changes as needed. Ansible isn't the best tool for an audit-style purpose.

I hope this helps explain things better!