In the previous blog post I presented an overview of the DNS and IPAM automation possible even when using only the native AWS provisioning tools such as the web console and CloudFormation. This next post in the series covers the setup and configuration of an Infoblox Cloud Platform Appliance in an AWS VPC to enable this.
The Infoblox Cloud Platform Appliance (CP) was designed to allow cloud platform automation via the Infoblox API without having to backhaul all API traffic to the Grid Master appliance. This is done in two ways: by allowing Infoblox objects such as networks, views, zones, etc. to be delegated to remote CP appliances local to the cloud stacks being serviced, and by automatically proxying requests to the appropriate CP appliance or the Grid Master when they cannot be served locally. This is the key to enabling AWS Lambda to interface with Infoblox. AWS Lambda can only send network traffic inside selected VPCs. By placing an Infoblox CP appliance inside a VPC, Lambda can then interface with the CP appliance’s local API enabling all of the functionality I’ll cover in this series.
This post assumes you already have an AWS VPC configured with at least one subnet. It also assumes connectivity between the VPC and an existing Infoblox Grid Master. The Grid Master can be in AWS or it can be on another platform. In this case my Grid Master is also in the AWS VPC. This is because there is one set of API calls (vDiscovery management) that I want to demonstrate that cannot be proxied via a CP appliance, they must go directly to the Grid Master, and Lambda is limited to communicating within its attached VPCs.
I’m not going to step through the installation process for an Infoblox appliance in Amazon EC2, the detailed steps are available in the vNIOS for AWS Installation Guide in the Tech Docs section of the Infoblox Support site.
Start by deploying an Infoblox Cloud Platform appliance into your AWS VPC. In this example I am using the CP-2200 appliance.
Connect to the newly deployed appliance via SSH and set temporary or permanent licenses on the appliance and join it to your existing Grid. Start the Cloud API on the new Cloud Platform Appliance. Open the Grid -> Grid Manager -> Services tab. Click the Cloud-API service in the top navigation bar. Select the new CP appliance from the list then click Start in the Toolbar. The Cloud API service will start up on the CP member.
Now you will need a user account to use for the API access to the Infoblox Grid. There is a default group called “cloud-api-only” that is configured to only have Cloud API access and nothing else (i.e. no GUI access). This group has no object permissions by default. You can configure object permissions for the group but for the sake of this example I will enable the Superusers role for this group. This removes the restriction against GUI login so don’t do that in a production environment. Now add a user account and add it to the cloud-api-only group. I called this account “clouduser.”
Let’s test the new Cloud API user account by issuing a couple of REST API calls. I’ll be using the 172.21.0.0/24 subnet (already defined in AWS) and the lambda.test DNS zone for these examples. I’ll create the DNS zone through the Cloud API, then create a vDiscovery job for my AWS account/region to make sure all of the used addresses in the subnet are automatically merged into the IPAM database. There are a couple of things to note about these API calls. The DNS zone creation will be done against the CP appliance through the Cloud API. The Tenant ID, CMP Type, and Cloud API Owned extensible attributes indicate to NIOS that these are Cloud API calls. The vDiscovery job API calls need to be made against the Grid Master WAPI, the CP appliance cannot take these requests.
Create the DNS zone and assign two name servers:
curl -k1 -u clouduser:infoblox -H "Content-Type: application/json" -X POST https://172.21.0.30/wapi/v2.3.1/zone_auth -d '{"fqdn":"lambda.test","grid_primary": [{"name": "lambdagm.localdomain", "stealth": false}],"grid_secondaries": [{"name": "lambdacp.localdomain"}],"extattrs":{"Tenant ID":{"value":"LambdaTenant"}, "CMP Type":{"value":"AWS"} ,"Cloud API Owned":{"value":"True"}}}'
Create the vDiscovery task:
curl -k1 -u clouduser:infoblox -H "Content-Type: application/json" -X POST https://172.21.0.20/wapi/v2.3.1/vdiscoverytask -d '{"name": "ec2.eu-west-1", "driver_type": "AWS", "fqdn_or_ip": "ec2.eu-west-1.amazonaws.com", "username": "********", "password": "********", "member": "lambdacp.localdomain", "port": 443, "protocol": "HTTPS", "auto_consolidate_cloud_ea": true, "auto_consolidate_managed_tenant": true, "auto_consolidate_managed_vm": true, "merge_data": true, "private_network_view": "default", "private_network_view_mapping_policy": "DIRECT", "public_network_view": "default", "public_network_view_mapping_policy": "DIRECT", "update_metadata": true, "scheduled_run": {"_struct":"setting:schedule","frequency": "HOURLY", "repeat": "RECUR", "minutes_past_hour": 1, "disable": true}}'
Run the vDiscovery task manually:
curl -k1 -u clouduser:infoblox -H "Content-Type: application/json" -X POST https://10.60.27.10/wapi/v2.3.1/vdiscoverytask/ZG5zLmNkaXNjb3ZlcnlfdGFzayRlYzIuZXUtd2VzdC0x:ec2.eu-west-1?_function=vdiscovery_control -d '{"action":"START"}'
After running the vDiscovery you should see all of the networks discovered from AWS in the Data Management -> IPAM tab in Infoblox Grid Manager. This should include your VPCs as network containers and any subnets within those VPCs as leaf networks. I’ll use these later for IPAM functions. vDiscovery saved having to create these networks manually and will ensure any IP addresses currently in use won’t be reused.
Everything is now configured and ready to use with AWS Lambda.