Working with one of your customers this week who is implementing Azure API Management alongside their web applications. We are funnelling all the request logs into an Application Insights services to manage visibility of the end-to-end transaction data. We noticed that all the client GET requests had ‘0.0.0.0’ in Client IP Address.
| Request Properties | Value |
|---|---|
| Client IP address | 0.0.0.0 |
I since learned that Microsoft obfuscate this data from Azure Monitor as it’s ingested into Applications Insights for what I call a ‘privacy policy‘. As this was a corporate application anonymity wasn’t needed and the development team wanted to understand when a request was made from their application either from inside corporate network or an unknown internet address.
A good habit to get into is first do a quick review of the latest API version for ‘Microsoft.Insights/components’ which does show a boolean value for DisableIpMasking.
{
"name": "string",
"type": "Microsoft.Insights/components",
"apiVersion": "2020-02-02-preview",
"location": "string",
"tags": {},
"kind": "string",
"properties": {
"Application_Type": "string",
"Flow_Type": "Bluefield",
"Request_Source": "rest",
"HockeyAppId": "string",
"SamplingPercentage": "number",
"DisableIpMasking": "boolean",
"ImmediatePurgeDataOn30Days": "boolean",
"WorkspaceResourceId": "string",
"publicNetworkAccessForIngestion": "string",
"publicNetworkAccessForQuery": "string"
}
}
Reviewing the property values for ApplicationInsightsComponentProperties object DisableIpMasking gave the following short but sweet answer.
| Name | Type | Requried | Value |
|---|---|---|---|
| DisableIpMasking | boolean | No | Disable IP masking. |
Yeah I reckon that is worth a shot!
Update ApplicationInsightsComponentProperties value DisableIpMasking
As this value only seems to be exposed through the API we have to either push a new incremental ARM template through the sausage maker or perform a API request directly. An API request seems like the quicker request method, but doing this in a script with authentication and correct structure takes time. I have a nice trick when wanting to update or add a value to an object when either of those feel like overkill.
- Navigate to the Azure Resource Explorer
- Find the Application Insights Resource Group
- Select Providers > Microsoft.Insights
- Select Components > ‘Application Insights Name‘
You will be shown the JSON definition of your Application Insights Object. You can tell this by the line:
"type": "microsoft.insights/components"
To know your in the right place, under properties there will be many values, we should see Application_Type, InstrumentationKey, ConnectionString, Retention, but what will be missing is DisableIpMasking. So it’s as simple as adding it.
- Up the top of the page toggle the blue switch to ‘Read/Write’ from ‘Read Only’.
- Select ‘Edit‘.
- Remember to add a ‘,’ to the previous last line (in my case “HockeyAppToken“) before adding your new property.
The final step is to use the PUT button to update the object. Which intern has authenticated you to the API using your existing login token, constructed the JSON object and is sending a ‘POST’ method to the API endpoint for ‘management.azure.com/subscriptions/<subscriptionId>/resourceGroups/<rgName>/providers/microsoft.insights/components/<resourceName>?api-version=2015-05-01‘. Much simpler than doing a Powershell or Bash script, what a clever little tool it is.
The result will be that new request in Application Insights will have the source NAT IP address. Unfortunately all previous requests will remain scrubbed with ‘0.0.0.0’.
Closing thoughts
This is a great way to tweak services while attempting to understand whether it’s the correct knob to turn in the Azure service. But while it’s quick, it isn’t documented. If you have a repository of deployment ARM templates make sure you go back and amend the deployment JSON. The day will come when it gets re-deployed and it wont come out the sausage maker the same. The finger will get pointed back at that Azure administrator who doesn’t follow good DevOps practices.
