Hi,
Thanks for reaching out to Microsoft Q&A.
There are two mechanisms for restricting access to the public endpoint:
- Inbound rules listing the IP addresses, ranges, or subnets from which requests are admitted
- Exceptions to network rules, where requests are admitted with no checks, as long as the request originates from a trusted service
Network rules aren't required, but it's a security best practice to add them if you use Azure AI Search for surfacing private or internal corporate content.
Network rules are scoped to data plane operations against the search service's public endpoint. Data plane operations include creating or querying indexes, and all other actions described by the Search REST APIs. Control plane operations target service administration. Those operations specify resource provider endpoints, which are subject to the network protections supported by Azure Resource Manager.
Limitations
There are a few drawbacks to locking down the public endpoint.
- It takes time to fully identify IP ranges and set up firewalls, and if you're in early stages of proof-of-concept testing and investigation and using sample data, you might want to defer network access controls until you actually need them.
- Some workflows require access to a public endpoint. Specifically, the import wizards in the Azure portal connect to built-in (hosted) sample data and embedding models over the public endpoint. You can switch to code or script to complete the same tasks when firewall rules in place, but if you want to run the wizards, the public endpoint must be available. For more information, see Secure connections in the import wizards.There are two mechanisms for restricting access to the public endpoint:
- Inbound rules listing the IP addresses, ranges, or subnets from which requests are admitted
- Exceptions to network rules, where requests are admitted with no checks, as long as the request originates from a trusted service
- It takes time to fully identify IP ranges and set up firewalls, and if you're in early stages of proof-of-concept testing and investigation and using sample data, you might want to defer network access controls until you actually need them.
- Some workflows require access to a public endpoint. Specifically, the import wizards in the Azure portal connect to built-in (hosted) sample data and embedding models over the public endpoint. You can switch to code or script to complete the same tasks when firewall rules in place, but if you want to run the wizards, the public endpoint must be available. For more information, see Secure connections in the import wizards.
Please follow this document for step by step guidance: https://learn.microsoft.com/en-us/azure/search/service-configure-firewall
Please do not forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.