As a fairly new systems engineer at Pensando Systems, and with the UK being in pretty much full lockdown over the holidays, I set myself a little bit of a pet project to help me demonstrate the value of the Pensando Distributed Services Platform.

Working for Pensando I get to see how the platform works and can visualise how customers can get value out of the technology, but when you only have a 30 minute or hour slot with the customer you know that sometimes they are not going to be able to visualise the value. So, I built TAPAS, the TAP-as-a-Service demo.

TAPAS makes use of just one of the features of the Pensando Platform – the ability to generate line rate filtered ERSPAN traffic directly from the Distributed Services Cards (DSCs) deployed in the servers as a 10G/25G or 100G network interface card (that all servers need), out to the tooling of customer choice.

You might already have physical TAPs in your network, or you might be able to enable similar functionality on your TOR or Core switches, so why is Pensando interesting?

Simply put, the Pensando architecture, with its centralised management console (the Pensando Policy and Services Manager), and the distribution of the DSC’s  in servers you have a scalable/dynamic TAPing environment that has an abstraction layer with a single API interface to manage (now that was a mouthful).

With the Pensando Policy and Services Manager (PSM), when I need a TAP of a specific workload, I don’t need to know where it is in my datacentre, the host it exists on, what TOR it is connected too, or even if I have a physical TAP at the location. All I need to know is what it is I want to TAP and where do I want the data forwarded to. Great, nice and simple, but I still need the network team to provision, and that could take some time (they are busy).

With TAPAS I built a solution that takes advantage of the REST API that the PSM has available and built a service portal. The concept of the service portal is to enable the application owner to drive the “TAP request to generation process” without the need for the Networks team to get involved. I am not taking the networks control away from the Networks team, as they would still need to set up the respective authorisation for the application owner to use TAPAS, but it removes the need for them to be involved in what could be the mundane task of setting up the TAP, monitoring it and then removing it (if that happens), especially if this is a process that gets repeated on a regular basis.

Did I mention how long it takes to setup the TAP’s using TAPAS? SECONDS……

1. App owner logs into the TAP portal, and sees a list of approved TAP destinations, and filters i.e. the workloads he/she is allowed to collect data from. He/she selects the require workload and duration and enables the TAP.
2. The TAPAS service portal, makes the API request to PSM.
3. PSM with it relationship with the likes of vCenter, knows the workload, and pushes the policy down to the DSC.
4. The DSC implements the policy and forwards the ERSPAN traffic to the registered tooling for the application owner.
5. Application owner has the data he wants at the click of a button, and once he is happy he can repeat the process to delete the TAP, or based on the duration he set the TAPAS service will clean up the TAP and save the network from unnecessary traffic.

As I mention previously, I built this as a concept to help demo the “art of the possible”, but it would be very easy to take the concept a step further.  For example, it could be integrated with other third party tools like ML/AI engines that already use the Telemetry data being generated from the DSC cards, or third party threat detection engines that see something happening on the datacentre network and dynamically enable a TAP so a security analyst has access to all the data when he/she is investigating the event.

The fact is the possibilities are endless due to the architecture of the Pensando Platform with the PSM centralised management console managing the services of the DSC cards.

A bit of detail on TAPAS

TAPAS is built as a python flask APP, with a MySQL backend, and all the code is available on GitHub to view and edit. It is distributed as a single docker image that is very easy to deploy and test the concept.

The ADMIN web GUI above, allows your networks and/or security teams to set up what I have broken down the required configuration to build a TAP into 2 areas, TAP targets and TAP filters. And then assign them to the application owners that they want to have permission to enable the TAP.

Now a filter could be a specific workload, or workload relationship between a Webserver and SQL server as an example. But something that is probably requested first time by the application owner when they first need a TAP. The TAP target is the location of the tooling that you want the traffic forwards to, and could be set up to only allow headers or full payload. In this example the tooling could be the development teams Wireshark terminal, or a commercial network traffic recorder.

Once the TAP targets and Filters are created, they can be assigned to the application owner. An application owner might have one or two tooling servers he/she uses, but most likely has a number of different filters registered.  This is so the application owner when they login to the TAPAS servers are only allowed to enable a TAP that they are authorised to run and see the data from the specific workload filters (a bit of RBAC).

The Application owner would select from the drop-down menus, the tooling, the filter and the duration of the TAP, and click enable. “That’s it” – the API call is made to the PSM, the PSM updates the DSC, and the TAP is enabled.

On the backend, I have built an audit trail, so you can track who enabled a TAP and when, if it was disabled by the user or an admin user or expired based on its duration, and if needed a re-activate option.

Summary

The TAPAS demo, is a great example to demonstrate the “Art of the possible” with Pensando. The advantages of a centralised management console and API framework. The flexibility of dynamic enablement of services distributed at the edge, and this is the beginning of my Journey with Pensando, so expect to see more demos coming to light… Dynamic Encryption as a service might be next.