While I have all new features and awesomeness of the new version of vRealize Network Insight; 4.1, covered in my official VMware blog post (still can’t believe I get to post there 😀 ), I thought I’d also cover what’s new in the API. As it’s quite a lot!
With Network Insight 4.1, the API version was updated to 1.1.1.
New Data Source Types
All the new data sources in 4.1 have also been made available in the API and all missing data sources from the 4.0 have also been added. This means you can add and otherwise manipulate F5 load balancers, Cisco ACI, Huawei, VMware PKS, Kubernetes, VMC and ServiceNow data sources.
Here’s the list of new API calls:
User Management
Network Insight 4.1 now has support for VMware Identity Manager (VIDM) as an authentication source. VIDM has enterprise-grade authentication and authorization functionality, like Multi-Factor and location-based authentication. Integrating VIDM with Network Insight means to configure it as an authentication source and then adding groups or individual users with a MEMBER or ADMIN role so that they can get access to Network Insight. The entire workflow can be managed using the API.
Here’s the list of new API calls:
Misc.
Apart from a heavy focus on data sources and VIDM, there’s also some other new API calls. You can retrieve an audit log of all changes inside Network Insight. You can also retrieve all members from an application.
Conclusion
I’m pretty happy with the progress of the API. Most other essential tasks in Network Insight have API calls available and it’s only getting better! I should also mention that PowervRNI is getting these new API calls really soon. 🙂
November 19, 2019 at 18:26
I’m just starting to do some work with the vRNI API and have reached the point where I know how to run basic searches with filters, but I’m having trouble figuring out how to do more complex searches. In my specific case, we need to retire a bunch of manually created NSX firewall rules that have been replaced by policies, but we want to verify that our policies cover all of the traffic that’s currently hitting each current rule before we disable it.
We’ve worked out a process through the GUI where we can basically run these two queries:
“flows where firewall ruleid = 2080”
and then, for each flow found that uses that rule, run:
“NSX firewall rule where source IP = [Source from Flow] and destination IP = [Destination from Flow] and port = [Port from Flow] and Appliedto != DISTRIBUTED_FIREWALL and action = allow”
to determine if we have any policy-based rules that would allow that flow (in this case, the old rules are applied to the whole DFW, so the “appliedto” field is an easy way to distinguish between them).
I feel like we’ve figured out a thorough process to investigate these old firewall rules, but it’s so labor intensive as to be useless without automation… which is what inspired me to learn about the API!
My challenge is that, when I try running a search through the API with an entity_type of “flow”, the objects that are returned don’t have a “firewall ruleid” property, so I can’t figure out how to put together my filter. Similarly, the entity_type “NSXFirewallRule” objects don’t have the IP fields (although I might be able to track that down by dereferencing the source/destination security groups that are there).
Do you have any advice about how I could approach this situation or put together those filters for the API calls? I appreciate any help that you can give =)
November 23, 2019 at 11:26
Hi Jason,
Good to see you’re diving into it! Executing search API calls is a bit tricky as of now, as it does not use the search queries that are done inside the interface search engine itself; you need to use the internal search queries. To get these, open up your browser developer tools while doing searches and catch the /search internal API call that vRNI does – the right search query for the API call will be in there.
If you’ve done that and see that there’s info missing in the public API, that is returned in the private API, please contact VMware (or me; msmit at vmware.com) to see how it can be completed. You can also simply use the private API, but that’s not documented.