Page MenuHomePhabricator

Automate diff and commit of frack ACL
Open, LowPublic


The current workflow for updating network frack ACLs is:

  1. fr-tech generates the new policies
  2. fr-tech copy them to the firewall's /var/tmp/ folder (identified by their timestamp)
  3. fr-tech opens a netops (SRE) task to push the changes with an instruction if it's safe to be done anytime or needs to be scheduled with fr-tech
  4. SRE stage the change, analyze the diff for any unexpected changes
  5. For large or unsure diff, SRE shares the diff with fr-tech for confirmation
  6. If any issues, repeat the previous steps
  7. If all good, SRE commits the change
  8. fr-tech checks that everything went as expected

I think this process could be improve in 2 ways:
As a prerequisite: grant ACL changes permission to the fr-tech users

  • Edit the ACL generation script to stage and diff the ACLs

This prevents the back and forth between fr-tech and SRE if there are any unexpected diff

  • Edit the ACL generation script to commit the ACLs

This would alleviate the need of SRE, especially for minor changes

If SRE's input is needed, fr-tech could either add the diff to a task for analysis or follow the current process (with the file in /var/tmp/).

This task is to start the conversation, nothing here is strict, please let me know what you think.
I'm happy to help and provide guidance on Juniper libraries/APIs.

Related Objects

Event Timeline

ayounsi created this task.
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

Is this a process that would be prompted over ssh at the same time as we push the policy to /var/tmp? Or would there be a separate process that watches for a new policy and sends out a diff somehow?

The former, instead of (or in addition to) copying the file over, it would display the diff, and could prompt the user with a "Commit? (y/N)"
It could also do a "commit confirmed" which mean it would auto rollback the change if connectivity to the router is lost for any reason (eg. bad ACL).

For example the Homer UI does:

ayounsi@cumin1001:~$ homer cr1-eqiad* commit "test"
INFO:homer:Generating configuration for
Configuration diff for

[edit interfaces xe-3/0/5]
-   description "Peering: Cloudflare (CLF-xxx) {#}";
+   description "Peering: Cloudflare (CLF-xxx) {#8434}";

Type "yes" to commit, "no" to abort.

Ok, happy to work this into our deployment-prep script.

We can use Juniper permissions system to restrict which part of the config a user can change:
It still needs to be tested to know if:
1/ we can allow a user to get a diff without commit right
2/ we can allow a user to only get a diff on specific parts of the config