Azure QnA Maker Security
Overview
QnA Maker is a cloud-based Natural Language Processing (NLP) service that allows you to create a natural conversational layer over your data. It is used to find the most appropriate answer for any input from your custom knowledge base (KB) of information.
In this article, we will discuss QnA Maker dependency resources and focus on authentication in both control plane and date plane.
Required Resources
Under QnA Maker umbrella, multiple Azure services are involved.
Each Azure resource created with QnA Maker has a specific purpose:
- QnA Maker resource
The QnA Maker resource provides access to the authoring and publishing APIs as well as ranker #2 - Cognitive Search resource
Store QnA pairs and ranker #1 - App Service, App Plan Service, Application Insights Service
The App service is used by your client application to access the published knowledge bases via the runtime endpoint.
(Notes: QnA Maker Managed (preview) version only requires to create QnA Maker resource and Cognitive Search resource in user’s subscription)
RBAC Roles
Azure Active Directory (AAD) is 100% backward compatible with key-based authentication for owners and contributors. Customers can use either key-based authentication or Azure RBAC-based authentication in their data plane requests.
Lab QnA Maker V1
In this lab, we explore QnA maker control plane authentication and QnA maker data plane authentication.
Grant control plane RBAC roles to testuser1.
# for QnA maker Resource
New-AzRoleAssignment -ObjectId 096a0df2–0a54–40dc-80d1–431a701b0380 -RoleDefinitionName “Cognitive Services Contributor” -ResourceGroupName “QnAgo”# for Azure Search
New-AzRoleAssignment -ObjectId 096a0df2-0a54-40dc-80d1-431a701b0380 -RoleDefinitionName "Search Service Contributor" -ResourceGroupName "QnAgo"# for application insight
New-AzRoleAssignment -ObjectId 096a0df2-0a54-40dc-80d1-431a701b0380 -RoleDefinitionName "Application Insights Component Contributor" -ResourceGroupName "QnAgo"# for App Service - also includes app insight
New-AzRoleAssignment -ObjectId 096a0df2-0a54-40dc-80d1-431a701b0380 -RoleDefinitionName "Website Contributor" -ResourceGroupName "QnAgo"# for App Service Plan
New-AzRoleAssignment -ObjectId 096a0df2-0a54-40dc-80d1-431a701b0380 -RoleDefinitionName "Web Plan Contributor" -ResourceGroupName "QnAgo"
Logon to the portal using the testuser1 credential, create QnA Maker resource from portal.
QnA Maker resource is created along with other required resources.
Now use testuser1 to create knowledge base from QnA maker site https://qnamaker.ai/, we know testuser1 does not have data plane RBAC roles.
Select our subscription and QnA maker resource, add two files to KB, then click “create your KB”, QnA pairs will be extracted form the files and stored in KB.
KB is created, because testuser1 has list key permission from control plane, testuser1 uses service key and has full permission in the QnA maker data plane.
Now let’s explore more about authentication of data plan rest API.
Can we use bearer token in publish API call?
(Notes: Cognitive Services API reference might be out of date, refer to following MS doc page instead,
)
We will do a post request to following URL,
https://QnAgo.cognitiveservices.azure.com/qnamaker/v4.0/knowledgebases/{kbId}
kbId can be found from QnA maker portal URLWe got 401 unauthorized, our access token does not have right audience.
Now let’s grant data plane editor role to testuser1 and remove control plane list key permission.
Remove-AzRoleAssignment -ObjectId “096a0df2–0a54–40dc-80d1–431a701b0380” -RoleDefinitionName “Search Service Contributor” -ResourceGroup “QnAgo”
New-AzRoleAssignment -ObjectId “096a0df2–0a54–40dc-80d1–431a701b0380” -RoleDefinitionName “Cognitive Services QnA Maker Editor” -ResourceGroup “QnAgo”From QnA maker portal, testuser1 is authenticated to publish KB. We get a new access token either through resource owner password grant or use a client_credential grant, to ensure the JWT has the right audience.
We call publish rest api again, but got following error.
{“error”: {“code”: “PermissionDenied”,“message”: “Principal does not have access to API/Operation.”}}Conclusion for Stable Version QnA Maker Authentication
Even though QnA maker document (https://docs.microsoft.com/en-us/azure/cognitive-services/qnamaker/concepts/role-based-access-control#access-is-provided-by-a-defined-role) mentioned bearer token for API access, it’s not actually supported.
Control plane is authenticated via RBAC, data plane can be authenticated via service key or RBAC when use QnA maker portal, data plane rest API currently does not support authorization bearer token, can only use service key.
I didn’t explore authentication for SDK option, but based on MS document, it all points to service key. (e.g https://docs.microsoft.com/en-us/azure/cognitive-services/qnamaker/quickstarts/quickstart-sdk?tabs=version-1%2Cv1&pivots=programming-language-python)
Some Azure Cognitive Services accept, and in some cases require, an authentication token. Currently, these services support authentication tokens:
- Text Translation API
- Speech Services: Speech-to-text REST API
- Speech Services: Text-to-speech REST API
Lab QnA Maker Managed
Two built in roles are required to create managed QnA maker, Cognitive Services Contributor and Search Service Contributor.
In future article, we will explore more about network pattern for managed QnA Maker.
Security Features Summary
- QnA Maker resource private endpoint
- Encryption in Transit TLS 1.2 or above
- Azure Search encryption at rest (Microsoft Managed Key or CMK)
- Protect QnA Maker App Service with IP restriction (Not applicable when use Managed QnA Maker)
PaaS service won’t be able to access App Service Private endpoint, so we use App Service IP restriction to protect App Service from public access. - QnA Maker Endpoint and Runtime API
Authentication via authoring and query runtime endpoint key
Authoring Key for KB management authentication, including create, edit and publish
Query Runtime Endpoint Key, including query KB and generate answer.
App Service IP Restriction Service Tag Support
Service tag is supported, even though still in preview with limited support.
The following list of service tags is supported in access restriction rules during the preview phase:
- ActionGroup
- AzureCloud
- AzureCognitiveSearch
- AzureConnectors
- AzureEventGrid
- AzureFrontDoor.Backend
- AzureMachineLearning
- AzureSignalR
- AzureTrafficManager
- LogicApps
- ServiceFabric
References
Azure resources — QnA Maker — Azure Cognitive Services | Microsoft Docs
