Configure an IP firewall for Azure Cognitive Search
Azure Cognitive Search supports IP rules for inbound access through a firewall, similar to the IP rules you'll find in an Azure virtual network security group. By applying IP rules, you can restrict search service access to an approved set of machines and cloud services. Access to data stored in your search service from the approved sets of machines and services will still require the caller to present a valid authorization token.
You can set IP rules in the Azure portal, as described in this article, or use the Management REST API, Azure PowerShell, or Azure CLI.
To access a search service protected by an IP firewall through the portal, allow access from a specific client and the portal IP address.
- A search service at the Basic tier or higher
Set IP ranges in Azure portal
Sign in to Azure portal and go to your Azure Cognitive Search service page.
Select Networking on the left navigation pane.
Set Public Network Access to Selected Networks. If your connectivity is set to Disabled, you can only access your search service via a private endpoint.
The Azure portal provides the ability to specify IP addresses and IP address ranges in the CIDR format. An example of CIDR notation is 126.96.36.199/24, which represents the IPs that range from 188.8.131.52 to 184.108.40.206.
Select Add your client IP address under Firewall to create an inbound rule for the IP address of your system.
Add other client IP addresses for other machines, devices, and services that will send requests to a search service.
After you enable the IP access control policy for your Azure Cognitive Search service, all requests to the data plane from machines outside the allowed list of IP address ranges are rejected.
When requests originate from IP addresses that aren't in the allowed list, a generic 403 Forbidden response is returned with no other details.
Allow access from the Azure portal IP address
When IP rules are configured, some features of the Azure portal are disabled. You'll be able to view and manage service level information, but portal access to indexes, indexers, and other top-level resources is restricted. You can restore portal access to the full range of search service operations by allowing access from the portal IP address and your client IP address.
To get the portal's IP address, perform
stamp2.ext.search.windows.net, which is the domain of the traffic manager. For nslookup, the IP address is visible in the "Non-authoritative answer" portion of the response.
In the following example, the IP address that you should copy is "220.127.116.11".
$ nslookup stamp2.ext.search.windows.net Server: ZenWiFi_ET8-0410 Address: 192.168.50.1 Non-authoritative answer: Name: azsyrie.northcentralus.cloudapp.azure.com Address: 18.104.22.168 Aliases: stamp2.ext.search.windows.net azs-ux-prod.trafficmanager.net azspncuux.management.search.windows.net
Services in different regions connect to different traffic managers. Regardless of the domain name, the IP address returned from the ping is the correct one to use when defining an inbound firewall rule for the Azure portal in your region.
For ping, the request will time out, but the IP address will be visible in the response. For example, in the message "Pinging azsyrie.northcentralus.cloudapp.azure.com [22.214.171.124]", the IP address is "126.96.36.199".
Providing IP addresses for clients ensures that the request isn't rejected outright, but for successful access to content and operations, authorization is also necessary. Use one of the following methodologies to authenticate your request:
- Key-based authentication, where an admin or query API key is provided on the request
- Role-based authorization, where the caller is a member of a security role on a search service, and the registered app presents an OAuth token from Azure Active Directory.
If your client application is a static Web app on Azure, learn how to determine its IP range for inclusion in a search service IP firewall rule.
Submit and view feedback for