Using cURL to edit and delete RESTful API Objects in a Palo Alto Networks Firewall

XML is a very hard language to understand when you are first working with it. For example when you refer to an element like:

<ship>Titanic</ship>

you refer to everything including the start tag and the end tag. The information inside the tags is text.

You need to keep this in mind when trying to reference things.

Another confusing thing is xpath and attributes. Take this XML example:

<rules>
  <entry name="rule1">
   <from>
       <member>
            Trust
       </member>
   </from>
  </entry>
  <entry name="rule2">
   <from>
       <member>
            UnTrust
       </member>
   </from>
  </entry>

<rules>

If you want to reference something say 'rule2' then what you want is the attribute value. You would use entry[@name='rule2'] entry is the element, name is the attribute and 'rule2' is the attribute value

If you want to reference the text value within an element then you would use element[text()='value'].

For example if you want to reference 'Trust' you can use member[text()='Trust']

This leads to why it could get a little confusing when trying to edit and delete specific values using the Palo Alto Networks API. Let's look at the following rule.

To delete a source-user member named 'acme\bob' in a group of source users
, use the below xpath:

xpath=/config/devices/entry[@name='<domain>']/vsys/entry[@name='<vsysname>']/rulebase/security/rules/entry[@name='<rulename>']/source-user/member[text()='acme\bob']


$curl -k "https://192.168.1.1/api/?type=config&action=delete&xpath=/config/devices/entry\[@name='localhost.localdomain'\]/vsys/entry\[@name='vsys1'\]/rulebase/security/rules/entry\[@name='deny-rule1'\]/source-user/member\[text()='acme\bob'\]&key=<API-KEY>"

<response status="success" code="20"><msg>command succeeded</msg>


If you want to edit a member value, then you need to reference the original member value with member\[text()='<value>'\] and then use the element parameter for the modified member text value: element=<xml code>

for example using curl

$ curl -k "https://192.168.1.1/api/?type=config&action=edit&xpath=/config/devices/entry\[@name='localhost.localdomain'\]/vsys/entry\[@name='vsys1'\]/rulebase/security/rules/entry\[@name='deny-rule1'\]/source-user/member\[text()='acme\bob'\]&element=<member>acme\calvin</member>&key=<API-KEY>"

<response status="success" code="20"><msg>command succeeded</msg></response>

Below are all xpath expressions you can use when accessing the Palo Alto Networks api.

Examples:

/source-user/member[position()<4]
Selects the first three member elements that are children of the source-user element

$ curl -k "https://192.168.1.1/api/?type=config&action=get&xpath=/\[@name='localhost.localdomain'\]/vsys/entry\[@name='vsys1'\]/rulebase/security/rules/entry\[@name='rule1'\]/source-user/member\[position()<4\]&key=<API-KEY>"
<response status="success" code="19"><result total-count="3" count="3">
  <member admin="admin" time="2015/10/21 13:42:11">acme\amy</member>
  <member admin="admin" time="2015/10/21 13:42:11">acme\bob</member>
  <member admin="admin" time="2015/10/21 13:42:11">acme\calvin</member>

/source-user/member[2] Selects the second member element that is the child of the source-user element


$ curl -k "https://192.168.1.1/api/?type=config&action=get&xpath=/\[@name='localhost.localdomain'\]/vsys/entry\[@name='vsys1'\]/rulebase/security/rules/entry\[@name='rule1'\]/source-user/member\[2\]&key=<API-KEY>" <response status="success" code="19"><result total-count="1" count="1">
  <member admin="admin" time="2015/10/21 13:42:11">acme\bob</member>

Using cURL to access the RESTful API of a Palo Alto Networks Firewall

There may be a situation where you would need to access the API of a Palo Alto Networks firewall. Some IT administrators may be more comfortable using cURL to access an API than a scripting language like PYTHON. Here's a few examples of how to perform some tasks using cURL.

The first thing you need to do is get an API key. How do you get an API Key? You query the firewall itself.

?type=keygen is the parameter to use.

curl -k "https://<firewall ip>/api/?type=keygen&user=<username>&password=<password>"

Make sure you wrap your url with Quotes. I tried this before and would get an error 400 response. 

You will get a response in xml. The value for key is the API key.

curl -k "https://192.168.1.1/api/?type=keygen&user=admin&password=admin"

<response status = 'success'>

<result>     

 <key>

   1234....

 </key>

 </result>

</response>

Then you can query the firewall using the API key instead of passing a username and password.

curl -k "https://<firewall ip>/api/?type=<api type>&<parameters>&key=<api-key>"

To get a list of api types and what commands to pass, you can use the REST API browser on the firewall. Just bring up a browser and authenticate against your firewall. After that you can add the path /api to the url.   https://<firewall ip>/api

Here you have the different api "types" you can query the firewall. Each of these types have some caveats as to the way you send your


For our first example, lets execute an operational command. From the cli the equivalent command would be "show system info".


If you drill down the Operational Commands to show system and info you will see the REST API URL at the bottom of the page. This is the url path you would copy to your curl command.

user@ubuntu-vm:~/API/curl$ curl -k "https://192.168.1.1/api/?

type=op&cmd=<show><system><info></info></system></show>&key=<API-KEY>"

<response status="success">

<result>

<system>

<hostname>NG-FW</hostname>

<ip-address>192.168.1.1</ip-address>

<netmask>255.255.255.0</netmask>

<default-gateway>192.168.1.254</default-gateway>

... TRUNCATED...

Notice that the command is in XML format. The firewall takes input and outputs in XML. 

This is important to note as you'll need to know the XPATH for most queries.

The following is to query the hostname with. You will need to add "action=get" as one of the parameters to read the hostname.

user@ubuntu-vm:~/API/curl$ curl -k "https://192.168.1.1/api/?type=config&action=get&xpath=/config/devices/entry\[@name='localhost.localdomain'\]/deviceconfig/system/hostname&key=<API-KEY>"

<response status="success" code="19"><result total-count="1" count="1">

  <hostname>NG-FW</hostname>

Notice that I had to put the literal '\[' for special characters like the square brackets. cURL would complain if I didn't have this.

curl: (3) [globbing] bad range specification in column 78

Now that we did a get. Let's try a set. When we do a set command, we need an extra parameter "element" that will contain the xml of the new content.

user@ubuntu-vm:~/API/curl$ curl -k "https://192.168.1.1/api/?type=config&action=set&xpath=/config/devices/entry\[@name='localhost.localdomain'\]/deviceconfig/system&element=<hostname>test</hostname>&key=<API-KEY>"

<response status="success" code="20"><msg>command succeeded</msg></response>

Doing a get command again shows us the hostname is changed.

user@ubuntu-vm:~/API/curl$curl -k "https://192.168.1.1/api/?type=config&action=get&xpath=/config/devices/entry\[@name='localhost.localdomain'\]/deviceconfig/system/hostname&key=<API-KEY>"

<response status="success" code="19"><result total-count="1" count="1">

  <hostname admin="admin" time="2015/10/14 11:08:11">test</hostname>

Next you need to commit the set command.

user@ubuntu-vm:~/API/curl$curl -k "https://192.168.1.1/api/?type=commit&cmd=<commit></commit>&key=<API-KEY>"

<response status="success" code="19"><result><msg><line>Commit job enqueued with jobid 699</line></msg><job>69

The response code will return a job id.

The last API type I'll cover are logs. Log retrieval is an asynchronous process so you need to query the particular log type first which will create a job id in the response and then query the FW again with the job id. Here’s an example using a threat log.

The first one is to generate the job id.

curl -k "https://<FW-IP>/api/?type=log&log-type=threat&key=<API-KEY>

The second will show you the results after the job task is finished.

curl -k "https://<FW-IP>/api/?type=log&action=get&jobid=<JOB-ID>&key=<API-KEY>

user@ubuntu-vm:~$ curl -k "https://192.168.1.1/api/?type=log&log-type=threat&key=<API-KEY>"

<response status="success" code="19"><result><msg><line>query job enqueued with jobid 3605</line></msg><job>3605</job></result></response>

user@ubuntu-vm:~$ curl -k "https://192.168.1.1/api/?type=log&action=get&jobid=3605&key=<API-KEY>"

<response status="success"><result>

  <job>

    <tenq>17:57:29</tenq>

    <tdeq>17:57:29</tdeq>

    <tlast>17:57:30</tlast>

    <status>FIN</status>

    <id>3605</id>

    <cached-logs>33</cached-logs>

  </job>

  <log>

   ... TRUNCATED ...

  </log>

  <meta>

    <devices>

      <entry name="localhost.localdomain">

        <hostname>localhost.localdomain</hostname>

        <vsys>

          <entry name="vsys1">

            <display-name>vsys1</display-name>

          </entry>

        </vsys>

      </entry>

    </devices>

  </meta>

Accessing a PAN firewall through an api with python

I found out that someone (Kevin Steves) made a python module to access Palo Alto Networks API. You can clone the repository from github.

git clone https://github.com/kevinsteves/pan-python.git

The module is very thorough and the documentation is pretty good. It was simple to test out and I was able to get it working in a few hours.

From what I can tell the module makes a REST call and exports the results into XML. This makes automation a lot easier as the data structure can be easily parsed.

My first script looks like this:

import pan.xapi

from cred import get_pan_credentials

credentials = get_pan_credentials()

print credentials

xapi = pan.xapi.PanXapi()

xapi.op(cmd='show system info', cmd_xml=True)

print xapi.xml_result()

----------

It makes a call to my credentials file

$ more cred.py

def get_pan_credentials():

 cred =  {}

 cred['api_username'] = "admin"

 cred['api_password'] = "admin"

 cred['hostname'] = "192.168.1.1"

 return cred

------------

The script in action.

$ python test1.py 

{'api_key': 'LUFRPT14MW5xOEo1R09KVlBZNnpnemh0VHRBOWl6TGM9bXcwM3JHUGVhRlNiY0dCR0srNERUQT09', 'hostname': '192.168.1.1', 'api_password': 'admin', 'api_username': 'admin'}

<system><hostname>PA-7050</hostname><ip-address>192.168.1.1</ip-address><netmask>255.255.255.0</netmask><default-gateway>192.168.1.254</default-gateway><ipv6-address>unknown</ipv6-address><ipv6-link-local-address>fe80::290:fbff:fe4d:175c/64</ipv6-link-local-address><ipv6-default-gateway /><mac-address>00:90:fb:4d:17:5c</mac-address><time>Mon Nov  3 23:28:08 2014</time>

<uptime>0 days, 11:39:35</uptime>

<devicename>PA-7050</devicename>

<family>7000</family><model>PA-7050</model><serial>015128030274</serial><sw-version>6.0.6</sw-version>

<global-protect-client-package-version>0.0.0</global-protect-client-package-version>

<app-version>466-2435</app-version>

<app-release-date>2014/10/28  20:28:09</app-release-date>

<av-version>1408-1880</av-version>

<av-release-date>2014/11/03  04:00:02</av-release-date>

<threat-version>466-2435</threat-version>

<threat-release-date>2014/10/28  20:28:09</threat-release-date>

<wildfire-version>0</wildfire-version>

<wildfire-release-date>unknown</wildfire-release-date>

<url-filtering-version>0000.00.00.000</url-filtering-version>

<global-protect-datafile-version>0</global-protect-datafile-version>

<global-protect-datafile-release-date>unknown</global-protect-datafile-release-date><logdb-version>6.0.6</logdb-version>

<platform-family>7000</platform-family>

<logger_mode>False</logger_mode>

<vpn-disable-mode>off</vpn-disable-mode>

<operational-mode>normal</operational-mode>

<multi-vsys>off</multi-vsys>

</system>

Not all APIs are created equally.

Automation is starting to become the new catch phrase in the networking Industry. It seems like 2014 is the year that marketing groups from different vendors have been touting APIs on their products. Skeptical networking engineers however have claimed that an API does not mean that their jobs are getting easier. In fact it’s been making their jobs a little harder.

Before a networking engineer could strictly focus on pure networking. But now, network engineers are increasingly required to know more and more on how to code or at least know how to read code.

Just because you have an API doesn’t mean all the devices can and will play nice with each other. 

We can see this by looking at three different platforms. 

OpenStack         Contrail        Junos

Now let’s look at their API for data retrieval/configuration

REST                  REST           Netconf

Ok now you have two platforms that use one type of API and a third platform that uses a different API.

Let's look at the resulting Data Structure response

JSON                JSON XML

Again we have two platforms that have the same Data Structure and a third with a different Data Structure.

You might say, ok, at least two of these platforms have the same API and with the same data structure things should be good for both of them right? Actually as they say, the devil is in the details.

I can illustrate this just by looking at a simple IPv4 subnet. 

On Openstack the data abstracted looks like this

{ "networks": [ { "contrail:subnet_ipam":  [  { "subnet_cidr": "12.1.1.0/24",  } ] } ] }

On Contrail it looks like this

{"virtual-network":{ "network_ipam_refs":[ { "attr": { "ipam_subnets": [ { "subnet": { "ip_prefix": "12.1.1.0", "ip_prefix_len": 24 }, } ] }, } ], } }

You can see that one platform combines the subnet with the mask while the other one separates it. For a DevOps engineers and Network Engineers this is annoying. It’s like having to learn different Network Operating systems. The goal of an API should be to allow a simplified abstraction layer.

APIs need to be standardized. Openflow is a good attempt at this. Openflow requires the underlay to have a common protocol in order to allow a controller to programmatically configure them. The networking industry has done a great job at standardizing protocols but a sorry job at creating a common API standard. Maybe the IETF needs to jump in on this. A standardized API could ultimately make our jobs that much more easier.

Exploring the REST API on contrail.

I noticed on github that there was a tutorial on how to access the REST API on Juniper Contrail.

https://juniper.github.io/contrail-vnc/api-doc/html/tutorial_with_rest.html#

The easiest way to access this is by using cURL. Contrail uses tcp port 8082 for accessing it's REST API.

The url http:/contrail-ip/virtual-networks prints out a list of configured virtual networks on Contrail.

$ curl -X GET -H "Content-Type: application/json; charset=UTF-8" http://172.16.1.4:8082/virtual-networks | python -mjson.tool

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current

                                 Dload  Upload   Total   Spent    Left  Speed

100  1229  100  1229    0     0   2129      0 --:--:-- --:--:-- --:--:--  2129

{

    "virtual-networks": [

        {

            "fq_name": [

                "default-domain",

                "default-project",

                "__link_local__"

            ],

            "href": "http://172.16.1.4:8082/virtual-network/4092df7b-997a-4ee7-a5cc-46d5db1187d4",

            "uuid": "4092df7b-997a-4ee7-a5cc-46d5db1187d4"

        },

        {

            "fq_name": [

                "default-domain",

                "default-project",

                "default-virtual-network"

            ],

            "href": "http://172.16.1.4:8082/virtual-network/34579f9a-064e-4048-96a7-a30355c54e44",

            "uuid": "34579f9a-064e-4048-96a7-a30355c54e44"

        },

        {

            "fq_name": [

                "default-domain",

                "default-project",

                "ip-fabric"

            ],

            "href": "http://172.16.100.104:8082/virtual-network/db7d1afe-bcaa-456b-b33a-9a36f6d176fe",

            "uuid": "db7d1afe-bcaa-456b-b33a-9a36f6d176fe"

        },

        {

            "fq_name": [

                "default-domain",

                "demo",

                "Network1"

            ],

            "href": "http://172.16.1.4:8082/virtual-network/380c0f4e-34b6-4901-98b2-61a8ed7afd7d",

            "uuid": "380c0f4e-34b6-4901-98b2-61a8ed7afd7d"

        },

        {

            "fq_name": [

                "default-domain",

                "demo",

                "Network2"

            ],

            "href": "http://172.16.100.104:8082/virtual-network/ffe03354-aaa2-4305-b615-654e14111134",

            "uuid": "ffe03354-aaa2-4305-b615-654e14111134"

        },

        {

            "fq_name": [

                "default-domain",

                "demo",

                "Network3"

            ],

            "href": "http://172.16.1.4:8082/virtual-network/93317422-eea4-4b77-88cb-5aaac3bb58b6",

            "uuid": "93317422-eea4-4b77-88cb-5aaac3bb58b6"

        }

    ]

}

However cURL, at least for me, isn’t capable of abstracting the data structures programatically. It's more like screen scraping. So I dug around the internet and noticed that python has a curl module.

http://pycurl.sourceforge.net/doc/quickstart.html#

Now I can use python to execute cURL to pull data from a REST API. 

There are a few parts to this script.

The first part is a function to issue the cURL command.

The second part is to abstract the route-target from a virtual network created in the Contrail controller.

This could then be used later on with another script to create a template configuration and program the underlay gateway router with a VRF.

In this script I cheated a little by grabbing a specific virtual-network’s url address from the previous curl command. Then parsed the data to grab the information I was looking for.

—————————————

import pycurl

import StringIO

import json

#Function to issue cURL command

def get_url(WEB):

  buf = StringIO.StringIO()

  c = pycurl.Curl()

  c.setopt(c.URL, WEB)

  c.setopt(c.WRITEFUNCTION, buf.write)

  c.perform()

  body = buf.getvalue()

  network = json.loads(body)

  buf.close()

  return network

#URL of virtual network on contrail

SITE = 'http://172.16.1.4:8082/virtual-network/380c0f4e-34b6-4901-98b2-61a8ed7afd7d'

objects = get_url(SITE)

#pretty print the json results

print json.dumps(objects, sort_keys=True, indent=4)

#This part is to grab the path of the Virtual Network name and RT from contrail

print "Name: ", objects['virtual-network']['name'], " RT: ", objects['virtual-network']['route_target_list']['route_target'][0]

Script in action:

——————

$ python contrail.py 

{

    "virtual-network": {

        "fq_name": [

            "default-domain", 

            "demo", 

            "Network1"

        ], 

        "href": "http://172.16.1.4:8082/virtual-network/380c0f4e-34b6-4901-98b2-61a8ed7afd7d", 

        "id_perms": {

            "created": "2014-09-19T19:19:11.650288", 

            "description": null, 

            "enable": true, 

            "last_modified": "2014-09-27T05:22:30.453524", 

            "permissions": {

                "group": "cloud-admin-group", 

                "group_access": 7, 

                "other_access": 7, 

                "owner": "cloud-admin", 

                "owner_access": 7

            }, 

            "uuid": {

                "uuid_lslong": 11002964217786203517, 

                "uuid_mslong": 4038619794410719489

            }

        }, 

        "instance_ip_back_refs": [

            {

                "attr": null, 

                "href": "http://172.16.1.4:8082/instance-ip/17b19dc0-b177-4df7-955b-57b8a87caf28", 

                "to": [

                    "17b19dc0-b177-4df7-955b-57b8a87caf28"

                ], 

                "uuid": "17b19dc0-b177-4df7-955b-57b8a87caf28"

            }, 

            {

                "attr": null, 

                "href": "http://172.16.1.4:8082/instance-ip/d525ddce-3542-4986-b8d1-56f3831d8678", 

                "to": [

                    "d525ddce-3542-4986-b8d1-56f3831d8678"

                ], 

                "uuid": "d525ddce-3542-4986-b8d1-56f3831d8678"

            }

        ], 

        "is_shared": false, 

        "name": "Network1", 

        "network_ipam_refs": [

            {

                "attr": {

                    "ipam_subnets": [

                        {

                            "default_gateway": "100.1.1.254", 

                            "subnet": {

                                "gw": "100.1.1.254", 

                                "ip_prefix": "100.1.1.0", 

                                "ip_prefix_len": 24

                            }

                        }

                    ]

                }, 

                "href": "http://172.16.1.4:8082/network-ipam/1f24fa35-b7bf-4d0f-8185-746f58e234c9", 

                "to": [

                    "default-domain", 

                    "demo", 

                    "Network1-ipam"

                ], 

                "uuid": "1f24fa35-b7bf-4d0f-8185-746f58e234c9"

            }

        ], 

        "network_policy_refs": [

            {

                "attr": {

                    "sequence": {

                        "major": 0, 

                        "minor": 0

                    }, 

                    "timer": null

                }, 

                "href": "http://172.16.1.4:8082/network-policy/0a1c1776-a323-4c00-959a-aada50b91be8", 

                "to": [

                    "default-domain", 

                    "demo", 

                    "net1<->net2"

                ], 

                "uuid": "0a1c1776-a323-4c00-959a-aada50b91be8"

            }

        ], 

        "parent_href": "http://172.16.1.4:8082/project/3af66afe-3284-40cc-8b04-85c69af512c7", 

        "parent_type": "project", 

        "parent_uuid": "3af66afe-3284-40cc-8b04-85c69af512c7", 

        "route_target_list": {

            "route_target": [

                "target:64512:100"

            ]

        }, 

        "router_external": false, 

        "routing_instances": [

            {

                "href": "http://172.16.1.4:8082/routing-instance/06165761-3b55-417d-acf0-0ad27a9010d0", 

                "to": [

                    "default-domain", 

                    "demo", 

                    "Network1", 

                    "Network1"

                ], 

                "uuid": "06165761-3b55-417d-acf0-0ad27a9010d0"

            }

        ], 

        "uuid": "380c0f4e-34b6-4901-98b2-61a8ed7afd7d", 

        "virtual_machine_interface_back_refs": [

            {

                "attr": null, 

                "href": "http://172.16.1.4:8082/virtual-machine-interface/2aefccdc-bf34-4d3b-bd37-41f716274883", 

                "to": [

                    "e432ad9a-8f6e-4f7c-813b-18ada76bfd64", 

                    "2aefccdc-bf34-4d3b-bd37-41f716274883"

                ], 

                "uuid": "2aefccdc-bf34-4d3b-bd37-41f716274883"

            }, 

            {

                "attr": null, 

                "href": "http://172.16.1.4:8082/virtual-machine-interface/f20bb145-49cd-43bf-a6e5-9d9c50794244", 

                "to": [

                    "2e775d6f-8043-41df-9295-d1b8d8f705a2", 

                    "f20bb145-49cd-43bf-a6e5-9d9c50794244"

                ], 

                "uuid": "f20bb145-49cd-43bf-a6e5-9d9c50794244"

            }

        ], 

        "virtual_network_properties": {

            "extend_to_external_routers": null, 

            "forwarding_mode": "l2_l3", 

            "network_id": 4, 

            "vxlan_network_identifier": null

        }

    }

}

Name:  Network1  RT:  target:64512:100

As you can see I was able to pull the "name" of the virtual network and the route-target of the virtual network. Later I can then create a script template to build the VRF on the Router Gateway like a MX.  That's one step closer to network automation.

Using CURL to access Openstack

So I'm exploring the API for Openstack to see how I can extract information from an Openstack platform.

I found the examples can be found here.  While the API is located here.

This could be useful as in the future I could script a networking device (Switch, Router, Firewall, etc) to automate and provision services whenever a new tenant is built.

The idea is to self provision itself. For example when a new tenant is created, a switch can access Openstack, find out what network name was configured, which vlan id assigned and a what ip subnet configured.

So the first step is to authenticate to the Openstack Server and retrieve a temporary token.

host1#curl -d '{"auth":{"passwordCredentials":{"username": "admin","password": "mypassword"},"tenantName": "admin"}}' -H "Content-Type: application/js
on" http://x.x.x.x:5000/v2.0/tokens | python -mjson.tool

What comes back is a json response that needs to be parsed.  I piped the python module "python -mjson.tool"  to parse the contents.

What I get in return looks similar to this:

{
    "access": {
        "metadata": {
            "is_admin": 0,
            "roles": [
                "3e2b3771096e4a95b39f3832c19679df"
            ]
        },
        "serviceCatalog": [
            {
                "endpoints": [
                    {

             ....
            }
        ],
 "token": {
            "expires": "2014-07-10T19:31:10Z",
            "id": "14213fjgiod2341vcrt46b9674f",
            "issued_at": "2014-07-09T19:31:10.700433",
            "tenant": {
                "description": "admin tenant",
                "enabled": true,
                "id": "3a10de8a82444118865a6398b336ee68",
                "name": "admin"
            }
        },
        "user": {
            "id": "be246bdf3e01493d8d75bf3938e1bffc",
            "name": "admin",
            "roles": [
                {
                    "name": "admin"
                }
            ],
            "roles_links": [],
            "username": "admin"
        }
    }
}

Now you can see that the token "expires" and this will mean that you will need to request tokens every so often for security purposes.

After this you'll need the token id so you can make further requests.

Next assign your token to a variable.

host1# MyToken=14213fjgiod2341vcrt46b9674f

host1# echo $MyToken
14213fjgiod2341vcrt46b9674f

Then you can use the token to request further information:
host1#curl -s  -H "X-Auth-Token: $MyToken"  http://x.x.x.x:9696/v2.0/networks | python -mjson.tool
{
    "networks": [
        {
            "admin_state_up": true,
            "id": "0b6ed891-a9ae-4c5a-a7f9-36e851bf1d48",
            "name": "Network1",
            "provider:network_type": "local",
            "provider:physical_network": null,
            "provider:segmentation_id": null,
            "router:external": false,
            "shared": false,
            "status": "ACTIVE",
            "subnets": [
                "d4bf516f-135c-4c7f-ba7e-363cb6c7d307"
            ],
            "tenant_id": "3a10de8a82444118865a6398b336ee68"
        }
}

With this information I can do a get on the subnet:

/v2.0/subnets/​{subnet_id}

 # curl -s  -H "X-Auth-Token: $MyToken"  http://x.x.x.x:9696/v2.0/subnets/d4bf516f-135c-4c7f-ba7e-363cb6c7d307 | python -mjson.tool
{
    "subnet": {
        "allocation_pools": [
            {
                "end": "20.20.0.20",
                "start": "20.20.0.10"
            }
        ],
        "cidr": "20.20.0.0/24",
        "dns_nameservers": [
            "198.6.1.1"
        ],
        "enable_dhcp": true,
        "gateway_ip": "20.20.0.1",
        "host_routes": [],
        "id": "d4bf516f-135c-4c7f-ba7e-363cb6c7d307",
        "ip_version": 4,
        "name": "Network1",
        "network_id": "0b6ed891-a9ae-4c5a-a7f9-36e851bf1d48",
        "tenant_id": "3a10de8a82444118865a6398b336ee68"
    }
}

So with this information I can basically extract the cidr and  gateway_ip to populate a gateway router.