Network & Security as a service via the NSX Policy API, Git, and Jenkins

When getting started with infrastructure automation, it is common to put together a script that sequentially performs the steps we would have done through the UI or the CLI.  There is nothing wrong with that. Still, the more I played with APIs and Automation tools, the more I realized that to really treat my infrastructure as code (IaC), I needed to embrace some of the processes developers use when working and collaborating on their code.

The first step in that direction is to fully embrace version control. There is no project that is too small to be checked in a version control system. That includes small scripts, ansible playbooks, or JSON files I am planning to push to an API. The second crucial realization I made is that it is way easier to get closer to the infrastructure as code ideal using declarative APIs and tools. This is because your “script” will reflect the desired state of the system and do not need to be altered based on the initial state the system is at a specific moment.

In this post, I am going to explore how to provide Network and Security as a Service via the NSX Policy API (A declarative API). I will use the infrastructure as code approach and will leverage tools that are commonplace in the DevOps community, such as Git and Jenkins. To start, I am going to lay out some basic general requirements for a generic NSXaaS solution.

Requirements

Must-Have:

1. End-User should be able to self-service Network and Security Services (Routing, Load Balancing, Security Groups, Security Policies, etc.) with minimal or no intervention from the NSX Administrator.
2. The End User should not be able to harm the system ( like removing NSX from a cluster…..)
3. One End-user should not be able to alter other end-users configurations

Nice-to-have:

1. Have the possibility to expose every NSX features to the end-user, but also to restrict some
2. Ability to version control and roll back end-user configurations
3. The end-user workflow should be easy

Solution Outline

1. The NSX Admin generates Principal Identity Credentials for Tenant 2. Using a Principal Identity instead of a regular user ensures that any object created by Tenant 2 cannot be modified or deleted by others
2. Pipeline and PI Credentials are added to the Jenkins server. Not providing direct access to the PI credentials or the NSX API to the end-user allows for an additional layer of control. The NSX Admin can hard code the allowed API calls in the Pipeline and parse the content of the JSON file downloaded from Github for unauthorized actions ( i.e., create a security group)
3. End-user push Policy API representation of the desired state in a Git repository. The end-user will use the NSX Policy API Hierarchical structure to describe the required topology.
4. The end-user triggers the Pipeline in Jenkins. Jenkins can be configured so that the end-user is only allowed to run the specific pipeline and nothing else
5. Jenkins retrieves the configuration from Github and pushes it to NSX Manager using the credentials dedicated to Tenant 2. The Jenkins Pipeline includes two stages. The first download the JSON file from the Github repository managed by the end-user, then unpack the certificate credentials to be included in the API call against NSX Manager. The second stage performs the API call.
6. NSX Manager realizes the topology. Because the NSX Policy API is declarative, the topology described in the GitHub repository will be achieved regardless of the current state of the system.

Demo

References

Policy API JSON data used in the demo

Jenkins Pipeline used in the demo

 

Advertisement