converting existing policies into ansible code

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

converting existing policies into ansible code

L1 Bithead

so - i'm just getting starting with ansible automation for my palo firewalls.  have some basic playbooks working...but now it's time to step it up.  One of my main east/west segmentation firewalls has roughly 100 policies.  Is there a way to ingest these rules into ansible - or somehow turn them into code so that future commits can become automation based - rather than manually building and pushing from panorama?

 

Can't imagine that i'm going to have to build these rules manually in ansible to reach the point of them all being deployed by automation. 

 

anyone else already cross this rubicon and have some guidance to offer a newb?

 

thanks!

11 REPLIES 11

L3 Networker

Do you plan to use ansible insted of panorama to create firewall rules? Any special reason?

I think there are alot of other things that can be automated before that makes alot more sense then firewall policy, specialy since you have panorama (if i have understood it correct?)

 

 

 

fair question!

My org has been spending an awful lot of time chasing soc2 compliance, CIS benchmarks, now NIST.  it's tedious work and I suspect will never end.

Being a career "network guy" one thing that has always been a challenge is building an environment that can be easily audited.  So, the reason we're moving forward with ansible to automate some of our palo stuff is because then our config is in code..we have commit histories, change control, etc... it will be very handy to say "this is our baseline security config - here's our code - here's our proof we comply," etc..

 

so - to the question "Do you plan to use ansible instead of panorama to create firewall rules? Any special reason?"

I think that's the direction we're headed...only because panorama is slow, lots of point & click, fairly cumbersome. 

Don't get me wrong...Panorama does a lot of good stuff...but it's also cumbersome, and still hand built manual.

 

Since I'm still pretty new to this I'd love to hear your thoughts on what other low hanging fruit you think is better to pursue first.

Im fairly sure its no way to convert the old configs to ansible playbooks. I dont really know how your policys look like and how many policys you are creating each day, but the thought of creating individuals policy in a playbook dont really sounds like something you would do in a the long run. Look at this example for a policy, https://github.com/PaloAltoNetworks/ansible-playbooks/blob/master/fw_rules.yml

Imagine just sorting out the application/service/hostname/hostgroup/tag without being able to browse the one that are already defined? 

 

 

I guess panorama has its problem but i rebuilding one sounds messy.

I dont know how your enviorment looks like, but i use ansible to create for example network interface, there you can also sync so it does config for switches, dns etc at the same time.

I have also done playbooks that load a list of policy from a report in (exported from panorama of unused rules for x amount of time) and disable them, i also have a playbook for software upgrades.

 

Here are some inspiration 

https://github.com/PaloAltoNetworks/ansible-playbooks

 

 

L0 Member

Here is a great example of how to use existing policies to establish guide rails using Ansible + OPA....https://www.ansible.com/blog/using-red-hat-ansible-automation-platform-to-enable-a-policy-as-code-so...

 

L2 Linker

@paul.dinapoli how did your migration from using Panorama to using IAC go?  I've been tasked with this for a number of reasons including the auditability by having your configs in code.  This all gets really complicated when you start using application based rules vs port based rules, ssl decryption...etc.  I still don't know of a good way to rename a rule via code as you can't simply go into your text based rule base (stored somewhere likely github) and just rename the rule.  Ansible will just create a new rule.  On the topic of new rules looking at the text file isn't' as easy to see your rule base and thus hard to know where to place a new rule...lots to think about.  Hoping you have some advise on how you accomplished this task.   

Hi @RyanH 

We're in the middle of it now - iterating over our process - but overall I'd say the underlying technical aspects are going fine.  I will try to pull apart your comments above and at least try to answer each one how we did it.  Your concerns sound just like mine at the start of this!

"This all gets really complicated when you start using application based rules vs port based rules, ssl decryption...etc"
full disclosure - we don't terminate TLS on our palos - so I cant speak to this for you.

but "app rules vs port rules".    from an ansible standpoint this is no biggie.   I would try to tackle in stages if you can.

  • when you go to write the ansible playbook to convert a hand-built rule into ansible code...just craft it identical to how it exists today. 
  • insert the new IaC rule right above the existing rule with all the same exact parameters (source/dest/app/logging/ etc... ) - just add. "-ansible" or whatever tag you like (-IaC) to the end of the name of the rule and use the 'location parameter' to have it land in the right location within your existing rule list.
    • location: 'before'
      existing_rule: 'existing_rule_namet'
  • This way when you or your larger team are looking at firewall configs...it's easy to see which rules are legacy hand-built rules - which are pushed via ansible.
  • Once you commit this rule into the firewall - it will be 1 rule ahead of your existing rule and the new one will start taking the hits.  you can reset the counters on the old rule to make sure nothing is matching it - then you could disable the old one (for a period to make for safe roll-back)
  • delete the disabled rules after a 30 day review period.
  •  rinse/repeat.

 

I still don't know of a good way to rename a rule via code as you can't simply go into your text based rule base (stored somewhere likely github) and just rename the rule.  Ansible will just create a new rule. 

yep - that's the point!  

 

My jira workflow goes like this:

  • we have 160+ firewall rules in our main east/west HA pair... they have all been hand built in panorama and pushed to a device group.
  • to turn all our firewall rules into code with a good clean audit trail we did this:
    • create a repo in bitbucket "network-ansible"
    • build out inventory, vars, etc... (we use ansible for cisco/f5/palo)
    • I wanted infosec to be default reviewers for anything related to firewall policy & security - but not general networking (cisco/f5) so we tag all our jira tickets with *net-seg* - so infosec can be alerted to commits and pull requests for palo stuff...but not all the other noise.
    • build out the ansible playbook ( yep - 160 rules = 160 jira tickets) but this is perfect...tedious as all hell...but perfect for the audit trail - and great for DR / fault tolerance.  god forbid you ever have to rebuild from zero - your rule base is just an ansible command away.
    • commit the code block
    • peer review / pull request. 
    • this whole git/jira/bitbucket workflow only takes care of the IaC part...you still have to go execute the playbook.  We do this by only running the playbook against Panorama (the ansible playbook for the rule will target the device group). This way we get the luxury of doing commit validation / and we then push to the firewall device group. 
    • This gives us lots of opportunity for catching mistakes and easy roll back.
  • rinse/repeat!

you're right...it looks like you're creating duplicate rules. for my use case - that's how we wanted to do it... plug in the new rule with -ansible tag...position it right above the existing.  seems like extra work - but it's the safe method...if you miss some parameter in your IaC deployed rule and it doesn't match 100% to the existing rule... instead of breaking something - you're still gonna match on the existing rule and your app still works.

 

if it helps - i'd be willing to do a show & tell via zoom if you need more details.
PD

Thanks for your response.  Several follow-ups and looking forward to seeing yours and other responses.  We're also tasked with not having humans manually go into the github IAC file and manually updating the IAC file for new rules.  We want to enable users to request things (in this case a FW rule modification) > have infosec approve it > and then ansible just does it so no FW engineer needs to be involved.  

 

1. In the previous comment i stated "I still don't know of a good way to rename a rule via code as you can't simply go into your text based rule base (stored somewhere likely github) and just rename the rule.  Ansible will just create a new rule." 

and you stated "yep - that's the point!".  After the new one is created, how are you removing the old rule + auditing that deletion?  Say I had a rule that was named "Access to TCP 443 from Internet for DMZ Web Servers", but then you realized you actually meant HTTPS and wanted to update the rule name to now say "Access to HTTPS from Internet for DMZ Web Servers".  What is your process from doing this as the moment you change the rule name, you will now have 2 rules that IAC created.

 

2. How are you modifying your rules.  Example, you find you need to move a rule up or down in the rule base for whatever reason say you have a rule that allows HTTPS from the internet to 100 address objects.  Then one of those address objects is being retired, how are you removing only that 1 address object from both the rule and from Panorama as to keep the rule clean and panorama clean of stale objects?  

 

3. Just because your rules are in IAC, doesn't mean a human couldn't log into panorama and create a rule (think like when ansible is down or something, or a human just not doing things they are supposed to do) and thus negate your IAC and auditing.  How are you accounting for this? 

 

4. How are you creating/maintaining all the things  (Objects, security profiles, custom apps, administrators access configs, EDLs, UserID configs, ldap/kerb configs... etc).  Without these objects and configs the firewall and it's rules wont work properly.

 

5. How are you accounting for commit errors?  Are you still going into Panorama and validate the commit happened?  

 

6. If you need to back out of a change how do you quickly revert to the last config?  Within Panorama it's easy, via IAC, i can't wrap my head around it as you can't just delete the rule (should you need to remove the rule) in IAC and say push.  Ansible in this case wont remove the rule.

 

7. You mention you have an HA pair of Panorama.  How are you checking which Panorama is the active Panorama with IAC before pushing the code?

 

8. As for your rebuilding everything from zero, why would you not just use the panorama backups as it has EVERYTHING where as your IAC only has the stuff that you've put into IAC.  

 

Looking forward to yours or others comments on the above as i try and decide if going through this IAC for palo automation is an appropriate use when going through panorama seems to have a lot of upside vs trying to turn every little config into code.  

 

 Thank you for your time. 

 

Yep - you bring up good questions - same issues/pain we've had - so rest assured you're not alone!

1. After the new one is created, how are you removing the old rule + auditing that deletion?
Me:  for us - still keeping this manual.  Once the new IaC rule is live I just use panorama UI to disable the existing hand-built rule.  We hang onto it for 30 days - then finally just delete/commit/push.

Say I had a rule that was named "Access to TCP 443 from Internet for DMZ Web Servers", but then you realized you actually meant HTTPS and wanted to update the rule name to now say "Access to HTTPS from Internet for DMZ Web Servers". 

What is your process from doing this as the moment you change the rule name, you will now have 2 rules that IAC created.

Me:  this is the beauty of running the playbook targeting your device-group in Panorama first.  If you noticed something you don't like - delete the rule from Panorama via the UI (quickest/easiest). Tweak the playbook and rerun it.  You sorta have to iterate over that a few times until you get it right - then finally you do the push to the firewall.

 

2. How are you modifying your rules.  Example, you find you need to move a rule up or down in the rule base for whatever reason say you have a rule that allows HTTPS from the internet to 100 address objects.  Then one of those address objects is being retired, how are you removing only that 1 address object from both the rule and from Panorama as to keep the rule clean and panorama clean of stale objects?  

Me: pretty straight-forward - if you are talking about a rule you have already codified - later you need to tweak it - ansible won't create the rule that already exists...it will only change the value that you tweaked.  add a source or dest address...it doesnt recreate another duplicate rule - it just adds the diff.


3. Just because your rules are in IAC, doesn't mean a human couldn't log into panorama and create a rule (think like when ansible is down or something, or a human just not doing things they are supposed to do) and thus negate your IAC and auditing.  How are you accounting for this? 

True, in my organization - for better or worse it's just me and my partner, there's only 2 of us that have full god-rights to the network and firewall infrastructure...so we are 100% in sync as parters in this journey. 
No exceptions...all firewall rule work goes through this jira/git/PR approval workflow.  

(think like when ansible is down or something,)
this isn't really a thing...Ansible runs from your laptop - or a jump host - unless it was a true emergency and you need to do something "RIGHT NOW" i would say - once you start your journey to all-rules-are-ansible - dont deviate.  it will be a mess.  if you have folks on your team that won't play nice...demote their account to read-only.

 

 

4. How are you creating/maintaining all the things  (Objects, security profiles, custom apps, administrators access configs, EDLs, UserID configs, ldap/kerb configs... etc).  Without these objects and configs the firewall and it's rules wont work properly.

True, there's a lot of dependencies.  We made the decision to only focus on the access rules and associated objects...but address objects / tags / etc... you can build a playbook with tasks - and you just create the dependencies first - then finally the firewall rule - that uses those objects





 

5. How are you accounting for commit errors?  Are you still going into Panorama and validate the commit happened?  

 

correct - we run the playbooks against panorama - then we use the validate tools for sanity check.  there's not really that many commit errors honestly - if the playbook has syntax issues it wont run...so by the time you have your playbook built correctly - it will execute against panorama without any issues.
Are you still going into Panorama and validate the commit happened?   <--- most definitely!

 

6. If you need to back out of a change how do you quickly revert to the last config?  Within Panorama it's easy, via IAC, i can't wrap my head around it as you can't just delete the rule (should you need to remove the rule) in IAC and say push.  Ansible in this case wont remove the rule.

(might be easier to show you this via zoom - too much typing!)


7. You mention you have an HA pair of Panorama.  How are you checking which Panorama is the active Panorama with IAC before pushing the code?
we only have 1 instance of panorama so this is not an issue for us.  we have HA firewalls...but for us panorama is just a single VM.

 

8. As for your rebuilding everything from zero, why would you not just use the panorama backups as it has EVERYTHING where as your IAC only has the stuff that you've put into IAC.  

yep - fair point.  many ways to skin the cat.  we bought into panorama after we'd already deployed several firewalls.  i would say this was a general PITA disaster.  some stuff panorama managed - other stuff it didn't. 
The general concept of panorama is pretty good...but in day to day use it has a lot of very confusing layers  / hard to navigate.  its an operational mistake to have feet in both worlds where some stuff is configured local - vs some stuff from panorama.

 

For us, we are trying to build this dynamically through ServiceNow and get FW IT Staff out of the day to day grind of operating FWs and let code do what it does best.  Thus some requestor who today puts in a ticket would go into a SNOW workflow, request a rule, some approval process happens and out the backend is a json file of all our rules in consumable via an API call.  From there we run our code on a task every x minutes hours and our code needs to iterate through each rule and do it's magic.  Fortunately we are starting with a new zone on the Firewall so all other existing rules wont have that new zone as a source or a destination, thus we can start with explicit denies in each direction.  For each new rule they would go "before" the explicit denies for that direction.  Lets say we have 10 rules that would go before the explicit deny.  With the ansible module can you specify "location" and "existing rule" https://paloaltonetworks.github.io/pan-os-ansible/modules/panos_security_rule_module.html.  The problem i'm running into is if you say that all 10 rules be BEFORE the deny rule, the module is literal.  It will check the first rule of the 10 and ask the question "is this rule DIRECTLY before the deny rule".  The answer will be NO.  Ansible will then move rule 1 DIRECTLY before the deny rule.  Then it goes to the next rule and asks the same question.  The answer is still NO, and now it moves it.  This continues until all rules are back exactly how they started EVEN IF NOTHING IN THE RULE CHANGES.  Thus every time we run a KCC to ensure the rules are correct, there is always a pending commit because from the FW perspective, a MOVE command was issued.  I've requested help here

https://github.com/PaloAltoNetworks/pan-os-ansible/issues/348

 

so if anyone sees this from the ansible module team, lets please work together.  I'm happy to beta new versions of the modules.      

L5 Sessionator

I know the conversation on this has gone beyond the original question, but I'd like to just state that the v2.12.0 Ansible collection has added gathered_filter for retrieving config, then outputs everything both as XML and as Ansible code.  Meta-parameters such as location and existing_rule won't show up in the output, but stuff like that can easily be derived:

 

 

- name: Get all rules
  panos_security_rule:
    provider: '{{ provider }}'
    state: 'gathered'
    gathered_filter: '*'
  register: ans

 

hi @gfreeman good to see you here.  Can you please take a look at https://github.com/PaloAltoNetworks/pan-os-ansible/issues/348

 

 

  • 6107 Views
  • 11 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!