AlgoBuzz Blog

Everything you ever wanted to know about security policy management, and much more.

Search
Generic filters
Exact matches only
Search in title
Search in content
Search in excerpt
Search in comments
Filter by Custom Post Type
Posts

DevOpsifying network connectivity: the Ansible-based option

by

In my previous blog post, I described the dream of agile application delivery with DevOps, and how it’s painfully shattered as soon as the tiniest firewall or network connectivity change is required. I also described how, using AlgoSec, you can seamlessly address this gap, and truly enjoy the benefits of DevOps.

Cool idea. Now let’s look at how we can actually implement it.

So first, a few pre-requisites:

  1. You need the AlgoSec solution deployed, managing all the important firewalls, routers, cloud security groups and private cloud SDNs, to make sure you cover everything that does network security filtering.
    Note that the solution describes here utilizes AlgoSec BusinessFlow and AlgoSec FireFlow.
  2. Ansible – Ansible is one of the more popular configuration management, IT orchestration and application deployment tools out there.
    The solution described here assumes you are using it to implement your DevOps pipeline and flow. If you use other tools, the same concepts can still be followed (plus check out my comments at the end about other implementation options)
  3. That’s it!

Good.

Now, let’s download and install the AlgoSec role for Ansible on your Ansible environment. You can find it in the Ansible Galaxy repository. Note there are a few required packages to install first. You then need to configure your AlgoSec server details into the role as configuration parameters (IP, credentials, etc.).

Note, the package includes a sample playbook, as well as a sample inventory YAML file.

The inventory file describes the application connectivity requirements of your application – “Connectivity as Code”. You need to list there all the flows required for the application to work, both internally (between application servers) and connections to/from the outside world. You don’t, however, need to know anything about firewalls, routing, etc., or even know where the application or external servers are (in the data center, in the cloud, outside your network, etc.). You can either use IP addresses or subnets, or pre-defined object names (that are already defined in AlgoSec BusinessFlow), for a more elegant, as well as future proof, solution.

This inventory should now be treated as some of the application’s code (or configuration), and should be updated by the developers whenever there is a change to the application’s connectivity requirements. One inventory file per application.

BTW, AlgoSec Ansible role code is distributed as open-source – so feel free to customize it or extend it to your own needs as you see fit (or just use as-is, that’s fine too).

Now simply incorporate the AlgoSec role into your Ansible automation flow, so that it will run whenever the application is integrated/delivered.

The role will connect to AlgoSec BusinessFlow, check whether anything has changed in the connectivity requirements, and quickly verify that the required connectivity is indeed correctly configured on the firewalls. If everything is fine – great (returns success immediately). But if there is some new connectivity requirement, that is not yet configured on the firewalls and security devices, the application connectivity requirements will be updated automatically in AlgoSec BusinessFlow, which will also initiate a change request using AlgoSec FireFlow (the change automation piece). AlgoSec FireFlow will then run through the change workflow, finding the relevant devices that require a change, verifying no risks or compliance issues will be introduced by the change, designing the optimal way to implement the changes, and then push them onto the devices – all with zero touch! Minutes later, the flow is open.

If, however, the requested change does not adhere to the compliance definitions pre-approved by Security, the change request will stop and will be escalated to the relevant people to approve, as needed.

That’s it. Network Security is now DevOpsified, and is no longer a painful bottleneck.

Note, now that you automagically have all the application’s connectivity requirements up to date in BusinessFlow, application owners get immediate visibility into the network connectivity status of their specific application, as well additional important information such as risk, compliance and server vulnerability – all in the context of the specific application. There are also other perks such as a cool connectivity diagram of the application, and a nice summary of all its details that can be exported as a pdf file.

For the network security guys, having all the applications’ connectivity details in AlgoSec BusinessFlow provides immediate application context to everything they touch on the firewalls. Why is this rule here? Oh, it looks like it is supporting the billing application. Can I shut this firewall down for maintenance? Can I quarantine this server because it looks like it’s under attack? Who do I need to talk to when the auditor wants clarification about these rules? BusinessFlow can provide the network security team immediate answers to all these questions (and more) so that they can do their job without breaking (important) stuff.

Awesome.

But what if I’m not using Ansible…?

The exact same concept and flow can be implemented for any other orchestration system. In addition, stay tuned for my next blog posts on how to easily utilize AlgoSec APIs and SDK to implement the above, as well as additional plugins to be delivered for other popular systems.

Subscribe to Blog

Receive notifications of new posts by email.