Introduction
VMware vDefend objects can be created in both the UI and API. The vDefend API can be interacted with using tools like Postman, cURL, and Terraform along with scripting languages like Python and Golang. In this guide, we will be using Postman. The API documentation can be found here and has all the information you need to perform CRUD actions against the NSX Manager. In this article, we will be focusing on the absolute basics of how to use the NSX Policy API to gather information.
https://developer.broadcom.com/xapis/nsx-t-data-center-rest-api/latest/
Building the URL:
All queries to the NSX Manager will start with what protocol we want to use and the FQDN/IP Address of the NSX Manager. Let’s assume our NSX Manager IP was 192.168.1.10. Whether it be using a scripting language like Python or using tools like Postman or cURL, we will query it like this:
https://10.10.1.105
When you want to gather information from NSX, we need to query it using a URI containing the object we want information about. For example, if we want to gather information about groups, we would use the following URI
/policy/api/v1/infra/domains/{domain-id}/groups
{domain-id} will be default when working with the global NSX Manager context. So, the URI will look like this:
/policy/api/v1/infra/domains/default/groups
If we put the two parts above together, we will have the following:
https://10.10.1.105/policy/api/v1/infra/domains/default/groups
We need to couple this with a method like GET which will retrieve information based on the URL provided above. In order to complete the get request we also need to couple this with authentication. There are a few ways we can authenticate against the NSX Manager, but for this introduction, we will use the username and password of an admin account.
Postman
For Postman, we will configure Basic Authentication:
In the picture above, I have set environment variables for username and password. I encourage you to do the same with Postman. For details on how to do this, please refer to the Postman documentation.
Now that we have authentication information set, we can prep for the call.
With a GET call, we do not have to send any payload or body with the call. We are getting information from the NSX Manager and expecting a payload in the response.
Now that we have all of our information set, we will execute the call in Postman.
As we can see from the picture, we got a 200 status code which means it was successful. For more information about status codes, please see the option content at the end of this article explaining return codes and their meaning.
As a quick reminder, groups are objects that contain a collection of one or more static or dynamic members, such as IP addresses or VMs. Groups are used in the source, destination or “Applied To” field of firewall rules.
We can see we received a payload containing information about all the groups configured in the NSX Manager. We get information like:
– _revision
– ID
– display_name
– description
Each group will have all the properties of the group in a JSON format. These things can later be modified with PUT, POST, and PATCH commands as well. For now, we will continue to focus on GET. Let’s say we want to get information about a singular group. All we have to do, per the API documentation, is include a name of a group in the URI. So let’s look for a group that we know already exists called “Windows”
https://10.10.1.105/policy/api/v1/infra/domains/default/groups/Windows
As we can see, we only received the Windows group information as opposed to the call we did earlier where we got all of the groups in the NSX Manager. The URL above required us to query the group by the ID. There are two ways we could get that information. One way is querying for all of the groups like we did above and getting the ID from the result, or we can use the UI to get the path of the object like this:
/infra/domains/default/groups/Windows
Notice how the path matches what we had above after the /policy/api/v1/ part of the URI.
When writing code in python, GoLang, or any other scripting language, we would use the same logic to make calls against the NSX Manager. We will show real examples in the next blog post.
To learn more about automation, be sure to check out the following:
