Nutanix Flow Security Central API Docs - Flow Security Central API Docs

Network monitoring has been done in countless different ways over the years. From running GUI-based reports, to scheduling data dumps to looking at logs, all are valid and common methods. The data is readily available, hopefully in a format that doesn’t need any modification and really just “does what you need”.

The requirement for this data certainly hasn’t changed but we’ve been seeing much tighter levels of integration between products. The demand for these levels of integration have driven the accompanying demand for standardised practices, including one very common practice – doing “things” via REST API.

Flow Security Central

Let’s first take a quick look at how Flow Security Central (FSC) is described on the FSC product page:

Success with a zero-trust policy comes not just from security controls, but also from the ability to monitor and maintain those controls. Nutanix helps businesses create and manage network security policies, establish and maintain a security and compliance baseline, audit in real-time, and easily remediate security vulnerabilities.

Doesn’t that sound like something that would fit beautifully into our automation workflows? Let’s see how.

Quick note: The deployment and configuration of FSC is beyond the scope of this article. As such, this article assumes you have already deployed and configured FSC for your environment. The official process is covered in the Flow Security Central guide.


Built around the same paradigm as other Nutanix REST APIs, the FSC APIs are, unsurprisingly, aimed at integrating core FSC features into automation workflows. For example, we can control how FSC interacts with different hybrid cloud types:

  • Nutanix clusters
  • AWS Accounts
  • Azure Subscriptions

Within those, we can control various aspects of how FSC interacts with those cloud environments. For example:

  • Onboarding new Nutanix clusters
  • Delete and update of Nutanix clusters
  • Getting information about Nutanix clusters that have already been onboarded
  • Similar steps as above but for AWS Accounts and Azure Subscriptions

Today we’ll focus on Nutanix clusters only.

FSC APIs – Existing Nutanix Clusters

The API examples I’ll briefly look at today are covered in the new Flow Security Central API reference. They’re being reproduced here simply to show how easy these APIs are to consume.

In today’s development environment, the FSC VM has been deployed and a user account has been configured with appropriate API token and cluster connection. The single Nutanix AHV cluster registered to the Prism Central instance has been registered with FSC as ntnxdev_pc.

Using your preferred API testing suite/application (e.g. Postman), we can quickly build a request to get a list of clusters that have been registered with FSC.

Sending this request returns a JSON response that provides information about the ntnxdev_pc instance already setup with FSC.

    "items": [
            "accountName": "ntnxdev_pc",
            "authKey": "{{auth_key}}",
            "clusters": [
                    "resourceGroupid": "{resource_group_id}}",
                    "clusterName": "Dev",
                    "clusterUUID": "{{cluster_uuid}}",
                    "isDisabled": false,
                    "city": "{{city}}",
                    "country": "{{country}}",
                    "latitude": {{latitude}},
                    "longitude": {{longitude}},
                    "antonEnabled": false

FSC APIs – More Useful Data

Listing connected clusters is all very well, but in the context of overall site or environment management and reporting, it’s not particularly useful on its own. Sure, we can check that clusters are correctly connected, but at some point we’ll want to start gathering more detailed Flow Security Central information, too. Let’s do that now.

The end goal of this section is to get a list of FSC issues that have been suppressed. In our isolated development environment, for example, DAR (Data-At-Rest) encryption is disabled. For this demo, let’s assume our policies allow this issue to be suppressed. Before making this sort of change, please make sure any changes to Flow Security Central issue suppression status are approved by processes appropriate for your organisation. To suppress this issue type:

  • Login to the FSC console
  • In the main menu, open Findings and Alerts
  • Locate then click the Nutanix Clusters without DAR Encryption issue (see screenshot below this list)
  • Check the box next to the rule name, select the Actions menu and select Suppress Selected
  • Enter a reason for the issue suppression and click Suppress

Why use this API request for this demo? Given that one of FSC’s core features is to establish compliance baselines, it is critical to know which rules aren’t being reported on.

List Suppressed FSC Issues – Get IDs

There are two items of information we need before we can send the final request. The final request requires a JSON POST payload that contains two mandatory items, as follows:

  • Resource group ID
  • Policy ID

To get the resource group ID, we can send an FSC API request that lists all resource groups:

In our demo environment, the response from this request is as follows:

    "items": [
            "resourceGroupId": "{{resource_group_id}",
            "resourceGroupName": "Dev",
            "accountId": "{{account_id}}",
            "resourceGroupType": "NX",
            "beamId": {{beam_id}},
            "hasWritePermission": false,
            "cloudAccountType": "COMMERCIAL",
            "cloudProviders": [
            "realtimeEnabled": false,
            "isDeleted": false

From the response above, the important item is resourceGroupId. Take a note of that value for upcoming steps.

To get the policy ID, we can send a similar request, as follows:

  • Request URL:{{resource_group_id}} (replace {{resource_group_id}} with the value noted down from the previous request)
  • Request type: GET
  • Authentication headers: X-Bm-Token: {{api_token}}
  • Content-Type: application/json
  • Documentation URL:

Part of the JSON response from this request is shown below:

    "items": [
            "name": "Default Audit Policy",
            "description": "Comprehensive policy consisting of all Security and Compliance checks.",
            "id": "{{policy_id}}",
            "createdBy": {
                "id": "nx-onboard-service",
                "name": "System"
            "createdAt": 1597801336705,
            "updatedAt": 1597801336705,
            "isSystemCreated": true,
            "isDefault": true,
            "isDisabled": false,
            "isCompliance": false,
            "cloudProviders": [
            "isProductDefault": true
[etc ...]

The important item to note down here is the value of {{policy_id}}, since the DAR Encryption issue falls under the Default Audit Policy in this example.

Building the Final Request

Now that we have the values required to build our JSON payload, we can construct it as follows:

    "filters": {
        "policyIds": [
    "resourceGroupIds": [

With the JSON payload built, the final request will be as follows:

Upon sending this request, the successful JSON response will be as follows:

    "items": [
            "issueId": "{{issue_id}}",
            "severity": "HIGH",
            "state": "Suppressed",
            "reason": "Chris R - Test FSC APIs for article",
            "suppressedAt": 1627349882731,
            "issueMetaData": {
                "kind": "CLUSTER",
                "clusterName": "Dev",
                "clusterUuid": "{{cluster_id}}"
            "isSystemSuppressed": false,
            "policy": {
                "id": "{{policy_id}}",
                "name": "Default Audit Policy"
            "resource": {
                "id": "{{resource_id}}",
                "name": "Dev",
                "location": "{{location}}",
                "cloudProvider": "NX",
                "account": {
                    "id": "{{account_id}}",
                    "name": "Dev"
                "tags": [],
                "inventoryId": "2446217519",
                "metaData": {
                    "buildVersion": "6.0",
                    "timezone": "{{timezone}}",
                    "encryptionStatus": "NOT_SUPPORTED",
                    "available": true,
                    "nosVersion": "6.0",
                    "nccVersion": "ncc-4.1.0",
                    "constrainedVm": "0",
                    "overprovisionedVm": "21",
                    "operationMode": "NORMAL",
                    "supportedInformationVerbosity": "BASIC_PLUS_CORE_DUMP",
                    "bullyVm": "0",
                    "gpuDriverVersion": "N/A",
                    "name": "Dev",
                    "clusterArchitecture": "X86_64",
                    "deadVm": "8",
                    "inefficientVm": "29",
                    "redundancyFactor": 2,
                    "domainAwarenessLevel": "NODE"
                "service": {
                    "name": "Nutanix Cluster",
                    "id": "cluster"
            "audit": {
                "id": "8050",
                "name": "Nutanix Clusters without DAR Encryption"
            "suppressedBy": {
                "id": null,
                "name": "Chris Rasmussen"
    "totalCount": 1

Let’s highlight a number of the key piece of information:

  • reason: When suppressing an issue in Flow Security Central, you’ll be asked to provide a reason for doing so. It is important for other users, when looking at the console, to have a clear understanding of why the issue was suppressed in the first place.
  • resource: Information about the cluster and in-depth details of the suppressed issue.
  • audit: The name of the audit policy.
  • suppressedBy: Details about the user that suppressed the issue. This is important for activity tracking.
  • totalCount: The number of suppressed issues. In a real-world situation, a high-level use case could be watching for an expected vs unexpected number of suppressed issues, potentially indicating an unapproved change has been made.

Potential Use Cases

Given the importance of automation in today’s I.T. environments, there are a number of potential use cases for automating these types of requests. Some very high level examples include:

  • Generating customer SLA reports
  • Ensuring security compliance via REST API (as opposed to using a GUI)
  • Applying compliance status in the event of an unexpected change

Related Resources

Here are the resource looked at today, along with additional resources for this interested in other areas of automation on All links will open in a new tab/window.

Wrapping Up is proud to add Flow Security Central to the list of documented REST API collections. Hopefully this article has provided some basic insight into how the FSC APIs can be consumed. Please see the Related Resources section above for additional information.

Thanks for reading and have a great day. 🙂