Intro​

A long time ago (2006), When I was still graduating in computer science, I’ve made a video showing the communication between 2 openBSD VMs configured with non-contiguous network masks (eg: 255.255.0.255 or 255.255.255.1) talking to each other.

At that time, I tried to use non-contiguous masks on Windows, Linux (Gentoo?), FreeBSD and OpenBSD. Only OpenBSD was able to make this kind of configuration.

Maybe having subnets with non-continuous masks aren't useful at all, but what about firewalls/filters? Having this possibility can be good and suppress some (many?) lines of rules depending on your scenario.

Intro​

VMWare has a nice product called NSX-T which allows you to build a sort of a cloud provider network infrastructure for your virtualized environment  (and K8s). It has network segmentation, routing, NAT, stateful firewall, IDS, traffic inspection, etc.

What if you already have a good and working cloud-like architecture and just want to insert some simple ACLs directly on the virtualization layer to outsource traffic filtering directly to the hypervisor, and do not want fancy things like firewall, NAT, IDS, etc. ?

vSwitch doesn't support this; NSX-T does, but it is expensive... What about VDS???

Python scripts used available at git repository: https://github.com/liviozanol/vmware_vds_traffic_filter

Conclusion​

This series of posts demonstrated how to use some nice tools to build a simple full-stack automation solution that can be  used to automate almost everything on your infrastructure.

The architecture demonstrated is not static and can be modified to best fit a team/company needs.

You can (and should) separate the API on 2 layers: One to deal with data validation and business rules (this is accessed by the user); One with basic validation, parsing and uploading data on gitlab.

You can make an audit function, either together on the pipeline/awx or separated. You gather info from your automated element (eg.: router) and compare it with the information on gitlab (reverse parsing it) to be sure that what was sent is really on the automated element.

You can (and really should) add a bastion host to access your automated elements, and make AWX use, for example, SSH tunnel prior to connecting to the automated element, protecting it even more from undesirable access.

Web Interface​

In this section we will build our web interface. Users can use it to get and update info from their WAN sites in a friendly interface. Note that using web interface is not mandatory. In fact, the web page will only convert data to/from API to show on a page, but users still request our API directly and can use it to make its changes. In some aspect this is good, since you give option to users to use any other tool to interact with our solution. They can use for example postman, curl, ansible, terraform, or even building its own web interface if they want to.

Service API​

In this section we will build our service API. It's responsible to receive direct user request, check permissions and if authorized, read and modify files on our gitlab repository.

We will use python as the API language, but as explained before, you could use any language you want that can be built to receive and process HTTP requests. To make things a little faster, will be used FastAPI framework. We will try to keep things as simple as possible for the demo, and some funtions may have some minor issues, but on your journey to build a production API you should take more cautions and make things as secure as possible.

After building the API, users should be able to access it using user/pass and view or change information from their WAN site.

All files generated on this section (and on previous) are on full-stack automation github repo (https://github.com/liviozanol/full-stack-automation), so you don't need to create it yourself again.

Gtilab-CI/Gitlab Runner​

In the previous post we have defined our structured data, stored it on gitlab, created our playbooks and inventories and imported them on AWX. Now we will prepare our CI/CD pipeline to monitor changes on our data on gitlab and tell AWX to execute our playbook. Gitlab runner will be responsible for these tasks, registering on our gitlab projects/group and executing a series of tasks once our data is changed, calling AWX API to run our workflow playbook passing our modified data and monitoring our job in execution also using AWX API.

All files generated on this section (and on previous) are on full-stack automation github repo (https://github.com/liviozanol/full-stack-automation), so you don't need to create it yourself again.

Everytime our gitlab repository is changed, gitlab-ci will get the contents of our wan_site_cfg.json file and send it to AWX as a variable, calling a job/playbook/template or a workflow that will implement the changes on our equipments.

After concluding this section you will have something like a GitOps for our wan automation service. If you change some information from your WAN site on gitlab repo, AWX will implement it on equipment.

Creating Playbooks and complements​

In the previous post we have defined our structured data and created sample projects on gitlab. Now that our data structure is defined we can start to build our playbooks and templates. In this section we'll build our inventory, templates, workflow and playbook.

All files generated on this section (and on previous) are on full-stack automation github repo (https://github.com/liviozanol/full-stack-automation), so you don't need to create it yourself again.

Ansible/AWX are only the executor of automation tasks and they are never accessed by end-users. So, we don't need to have separation/segregation on a client basis on AWX and you don't need to carry about this. More information about AWX and its role on this architecture can be found here

Everytime our gitlab repository is changed, gitlab-ci will get the contents of our wan_site_cfg.json file and send it to AWX as a variable, calling a job/playbook/template or a workflow that will implement the changes on our equipments.

After configuring AWX, you should be able to start jobs on it to implement changes on remote WAN sites.

Every file for AWX config to our demo can be found here

Demo Introduction​

The past 6 posts were about building the infrastructure needed to implement the full-stack automation architecture described.

From now on, we will start to build a demo scenario to use it. As stated on the first post, we will use a scenario as an example and will use the architecture to automate one service.

Assertions​

Consider these information assertions about you:

You work on a network service provider that serves WAN connections to several clients.

The network topology has CPEs (routers installed on clients premises) that is connected to the provider transport network. You are required to allow clients to modify some configurations on these CPEs.

• Clients should be able to change configuration for all CPEs installed on their sites.

• Clients must only modify configuration for the LAN interface of CPEs.

• Clients should be able to modify configuration for interface description (?), interface IP address/subnet, interface ACLs and helper/DHCP relay address.

• Clients should be able to access a web page to make modifications. They should be able to also do these actions through an API.

Now we can begin to define our service. Let's call it "Wan Sites". You could do something similar with other services, like "DNS records", "VMs", "Containers", etc.

Gitlab-CI​

Gitlab-CI, AKA Gitlab runner, is a Continuous Integration and Continuous Delivery/Deployment solution built by gitlab. It fully integrates with gitlab listening for changes on repositories and executing pipelines to automate build, test, approve and deploy applications.

It can run on a container and, after a change is triggered, uses docker images to execute steps configured on the pipeline.

More about Gitlab can be found on its site: https://docs.gitlab.com/ee/ci/

Ansible/AWX​

Ansible is an automation platform that supports a wide range of functions and can be used to automate almost anything: From network devices from different manufacturers to custom web APIs. The choice for ansible in this layer is for this reason and also because of AWX.