|
1 | 1 | ---
|
2 |
| -title: API key authentication |
| 2 | +title: Connect with API keys |
3 | 3 | titleSuffix: Azure Cognitive Search
|
4 |
| -description: An API key controls inbound access to the service endpoint. Admin keys grant write access. Query keys can be created for read-only access. |
| 4 | +description: Learn how to use an admin or query API key for inbound access to an Azure Cognitive Search service endpoint. |
5 | 5 |
|
6 | 6 | manager: nitinme
|
7 | 7 | author: HeidiSteen
|
8 | 8 | ms.author: heidist
|
9 | 9 | ms.service: cognitive-search
|
10 |
| -ms.topic: conceptual |
11 |
| -ms.date: 08/15/2022 |
| 10 | +ms.topic: how-to |
| 11 | +ms.date: 01/10/2023 |
12 | 12 | ---
|
13 | 13 |
|
14 |
| -# Use API keys for Azure Cognitive Search authentication |
| 14 | +# Connect to Cognitive Search using key authentication |
15 | 15 |
|
16 |
| -Cognitive Search offers key-based authentication as its primary authentication methodology. For inbound requests to a search service endpoint, such as requests that create or query an index, API keys are the only generally available authentication option you have. A few outbound request scenarios, particularly those involving indexers, can use Azure Active Directory identities and roles. |
| 16 | +Cognitive Search offers key-based authentication that you can use on connections to your search service. An API key is a unique string composed of 52 randomly generated numbers and letters. A request made to a search service endpoint will be accepted if both the request and the API key are valid. |
| 17 | + |
| 18 | +API keys are frequently used when making REST API calls to a search service. You can also use them in search solutions if Azure Active Directory isn't an option. |
17 | 19 |
|
18 | 20 | > [!NOTE]
|
19 |
| -> [Azure role-based access control (RBAC)](search-security-rbac.md) for inbound requests to a search endpoint is now in preview. You can use this preview capability to supplement or replace API keys on search index requests. |
| 21 | +> A quick note about "key" terminology in Cognitive Search. An "API key", which is described in this article, refers to a GUID used for authenticating a request. A "document key" refers to a unique string in your indexed content that's used to uniquely identify documents in a search index. API keys and document keys are unrelated. |
20 | 22 |
|
21 |
| -## Using API keys in search |
| 23 | +## What's an API key? |
22 | 24 |
|
23 |
| -API keys are generated when the service created. Passing a valid API key on the request is considered proof that the request is from an authorized client. There are two kinds of keys. *Admin keys* convey write permissions on the service and also grant rights to query system information. *Query keys* convey read permissions and can be used by apps to query a specific index. |
| 25 | +There are two kinds of keys used for authenticating a request: |
24 | 26 |
|
25 |
| -When connecting to a search service, all requests must include an API key that was generated specifically for your service. |
| 27 | +| Type | Permission level | Maximum | How created| |
| 28 | +|------|------------------|---------|---------| |
| 29 | +| Admin | Full access (read-write) for all content operations | 2 <sup>1</sup>| Two admin keys, referred to as *primary* and *secondary* keys in the portal, are generated when the service is created and can be individually regenerated on demand. | |
| 30 | +| Query | Read-only access, scoped to the documents collection of a search index | 50 | One query key is generated with the service. More can be created on demand by a search service administrator. | |
26 | 31 |
|
27 |
| -+ In [REST solutions](search-get-started-rest.md), the API key is typically specified in a request header |
| 32 | +<sup>1</sup> Having two allows you to roll over one key while using the second key for continued access to the service. |
28 | 33 |
|
29 |
| -+ In [.NET solutions](search-howto-dotnet-sdk.md), a key is often specified as a configuration setting and then passed as an [AzureKeyCredential](/dotnet/api/azure.azurekeycredential) |
| 34 | +Visually, there's no distinction between an admin key or query key. Both keys are strings composed of 52 randomly generated alpha-numeric characters. If you lose track of what type of key is specified in your application, you can [check the key values in the portal](#find-existing-keys). |
30 | 35 |
|
31 |
| -You can view and manage API keys in the [Azure portal](https://portal.azure.com), or through [PowerShell](/powershell/module/az.search), [Azure CLI](/cli/azure/search), or [REST API](/rest/api/searchmanagement/). |
| 36 | +## Use API keys on connections |
| 37 | + |
| 38 | +API keys are specified on client requests to a search service. Passing a valid API key on the request is considered proof that the request is from an authorized client. If you're creating, modifying, or deleting objects, you'll need an admin API key. Otherwise, query keys are typically distributed to client applications that issue queries. |
| 39 | + |
| 40 | +You can specify API keys in a request header for REST API calls, or in code that calls the azure.search.documents client libraries in the Azure SDKs. If you're using the Azure portal to perform tasks, your role assignment determines the level of access. |
| 41 | + |
| 42 | +Best practices for using hard-coded in source files include: |
| 43 | + |
| 44 | ++ During early development and proof-of-concept testing when security is looser, use sample or public data. |
| 45 | + |
| 46 | ++ After advancing into deeper development or production scenarios, switch to [Azure Active Directory and role-based access](search-security-rbac.md) to eliminate the need for having hard-coded keys. Or, if you want to continue using API keys, be sure to always monitor who has access to your API keys and regenerate API keys on a regular cadence. |
| 47 | + |
| 48 | +### [**REST**](#tab/rest-use) |
| 49 | + |
| 50 | ++ Admin keys are only specified in HTTP request headers. You can't place an admin API key in a URL. See [Connect to Azure Cognitive Search using REST APIs](search-get-started-rest.md#connect-to-azure-cognitive-search) for an example that specifies an admin API key on a REST call. |
| 51 | + |
| 52 | ++ Query keys are also specified in an HTTP request header for search, suggestion, or lookup operation that use POST. |
32 | 53 |
|
33 |
| -:::image type="content" source="media/search-manage/azure-search-view-keys.png" alt-text="Portal page, retrieve settings, keys section" border="false"::: |
| 54 | + Alternatively, you can pass a query key as a parameter on a URL if you're using GET: `GET /indexes/hotels/docs?search=*&$orderby=lastRenovationDate desc&api-version=2020-06-30&api-key=[query key]` |
34 | 55 |
|
35 |
| -## What is an API key? |
| 56 | +### [**Azure PowerShell**](#tab/azure-ps-use) |
36 | 57 |
|
37 |
| -An API key is a unique string composed of randomly generated numbers and letters that are passed on every request to the search service. The service will accept the request, if both the request itself and the key are valid. |
| 58 | +A script example showing API key usage can be found at [Quickstart: Create an Azure Cognitive Search index in PowerShell using REST APIs](search-get-started-powershell.md). |
38 | 59 |
|
39 |
| -Two types of keys are used to access your search service: admin (read-write) and query (read-only). |
| 60 | +### [**.NET**](#tab/dotnet-use) |
40 | 61 |
|
41 |
| -|Key|Description|Limits| |
42 |
| -|---------|-----------------|------------| |
43 |
| -|Admin|Grants full rights to all operations, including the ability to manage the service, create and delete indexes, indexers, and data sources.<br /><br /> Two admin keys, referred to as *primary* and *secondary* keys in the portal, are generated when the service is created and can be individually regenerated on demand. Having two keys allows you to roll over one key while using the second key for continued access to the service.<br /><br /> Admin keys are only specified in HTTP request headers. You cannot place an admin API key in a URL.|Maximum of 2 per service| |
44 |
| -|Query|Grants read-only access to indexes and documents, and are typically distributed to client applications that issue search requests.<br /><br /> Query keys are created on demand.<br /><br /> Query keys can be specified in an HTTP request header for search, suggestion, or lookup operation. Alternatively, you can pass a query key as a parameter on a URL. Depending on how your client application formulates the request, it might be easier to pass the key as a query parameter:<br /><br /> `GET /indexes/hotels/docs?search=*&$orderby=lastRenovationDate desc&api-version=2020-06-30&api-key=[query key]`|50 per service| |
| 62 | +In search solutions, a key is often specified as a configuration setting and then passed as an [AzureKeyCredential](/dotnet/api/azure.azurekeycredential). See [How to use Azure.Search.Documents in a C# .NET Application](search-howto-dotnet-sdk.md) for an example. |
45 | 63 |
|
46 |
| - Visually, there is no distinction between an admin key or query key. Both keys are strings composed of 32 randomly generated alpha-numeric characters. If you lose track of what type of key is specified in your application, you can [check the key values in the portal](https://portal.azure.com). |
| 64 | +--- |
47 | 65 |
|
48 | 66 | > [!NOTE]
|
49 |
| -> It's considered a poor security practice to pass sensitive data such as an `api-key` in the request URI. For this reason, Azure Cognitive Search only accepts a query key as an `api-key` in the query string, and you should avoid doing so unless the contents of your index should be publicly available. As a general rule, we recommend passing your `api-key` as a request header. |
| 67 | +> It's considered a poor security practice to pass sensitive data such as an `api-key` in the request URI. For this reason, Azure Cognitive Search only accepts a query key as an `api-key` in the query string. As a general rule, we recommend passing your `api-key` as a request header. |
50 | 68 |
|
51 | 69 | ## Find existing keys
|
52 | 70 |
|
53 |
| -You can obtain access keys in the portal or through [PowerShell](/powershell/module/az.search), [Azure CLI](/cli/azure/search), or [REST API](/rest/api/searchmanagement/). |
| 71 | +You can view and manage API keys in the [Azure portal](https://portal.azure.com), or through [PowerShell](/powershell/module/az.search), [Azure CLI](/cli/azure/search), or [REST API](/rest/api/searchmanagement/). |
| 72 | + |
| 73 | +### [**Azure portal**](#tab/portal-find) |
| 74 | + |
| 75 | +1. Sign in to the [Azure portal](https://portal.azure.com) and [find your search service](https://portal.azure.com/#blade/HubsExtension/BrowseResourceBlade/resourceType/Microsoft.Search%2FsearchServices). |
| 76 | + |
| 77 | +1. Under **Settings**, select **Keys** to view admin and query keys. |
54 | 78 |
|
55 |
| -1. Sign in to the [Azure portal](https://portal.azure.com). |
56 |
| -1. List the [search services](https://portal.azure.com/#blade/HubsExtension/BrowseResourceBlade/resourceType/Microsoft.Search%2FsearchServices) for your subscription. |
57 |
| -1. Select the service and on the Overview page, click **Settings** >**Keys** to view admin and query keys. |
| 79 | +:::image type="content" source="media/search-manage/azure-search-view-keys.png" alt-text="Screenshot of a portal page showing API keys." border="true"::: |
58 | 80 |
|
59 |
| - :::image type="content" source="media/search-security-overview/settings-keys.png" alt-text="Portal page, view settings, keys section" border="false"::: |
| 81 | +### [**REST**](#tab/rest-find) |
| 82 | + |
| 83 | +Use [ListAdminKeys](/rest/api/searchmanagement/2020-08-01/admin-keys) or [ListQueryKeys](/rest/api/searchmanagement/2020-08-01/query-keys/list-by-search-service) in the Management REST API to return API keys. |
| 84 | + |
| 85 | +You must have a [valid role assignment](#permissions-to-view-or-manage-api-keys) to return or update API keys. See [Manage your Azure Cognitive Search service with REST APIs](search-manage-rest.md) for guidance on meeting role requirements using the REST APIs. |
| 86 | + |
| 87 | +```rest |
| 88 | +POST https://management.azure.com/subscriptions/{{subscriptionId}}/resourceGroups/{{resource-group}}/providers//Microsoft.Search/searchServices/{{search-service-name}}/listAdminKeys?api-version=2021-04-01-preview |
| 89 | +``` |
| 90 | + |
| 91 | +--- |
60 | 92 |
|
61 | 93 | ## Create query keys
|
62 | 94 |
|
63 | 95 | Query keys are used for read-only access to documents within an index for operations targeting a documents collection. Search, filter, and suggestion queries are all operations that take a query key. Any read-only operation that returns system data or object definitions, such as an index definition or indexer status, requires an admin key.
|
64 | 96 |
|
65 | 97 | Restricting access and operations in client apps is essential to safeguarding the search assets on your service. Always use a query key rather than an admin key for any query originating from a client app.
|
66 | 98 |
|
67 |
| -1. Sign in to the [Azure portal](https://portal.azure.com). |
68 |
| -2. List the [search services](https://portal.azure.com/#blade/HubsExtension/BrowseResourceBlade/resourceType/Microsoft.Search%2FsearchServices) for your subscription. |
69 |
| -3. Select the service and on the Overview page, click **Settings** >**Keys**. |
70 |
| -4. Click **Manage query keys**. |
71 |
| -5. Use the query key already generated for your service, or create up to 50 new query keys. The default query key is not named, but additional query keys can be named for manageability. |
| 99 | +### [**Azure portal**](#tab/portal-query) |
72 | 100 |
|
73 |
| - :::image type="content" source="media/search-security-overview/create-query-key.png" alt-text="Create or use a query key" border="false"::: |
| 101 | +1. Sign in to the [Azure portal](https://portal.azure.com) and [find your search service](https://portal.azure.com/#blade/HubsExtension/BrowseResourceBlade/resourceType/Microsoft.Search%2FsearchServices). |
74 | 102 |
|
75 |
| -> [!Note] |
76 |
| -> A code example showing query key usage can be found in [DotNetHowTo](https://github.com/Azure-Samples/search-dotnet-getting-started/tree/master/DotNetHowTo). |
| 103 | +1. Under **Settings**, select **Keys** to view API keys. |
| 104 | + |
| 105 | +1. Under **Manage query keys**, use the query key already generated for your service, or create new query keys. The default query key isn't named, but other generated query keys can be named for manageability. |
| 106 | + |
| 107 | + :::image type="content" source="media/search-security-overview/create-query-key.png" alt-text="Screenshot of the query key management options." border="true"::: |
| 108 | + |
| 109 | +### [**Azure CLI**](#tab/azure-cli-query) |
| 110 | + |
| 111 | +A script example showing query key usage can be found at [Create or delete query keys](search-manage-azure-cli.md#create-or-delete-query-keys). |
| 112 | + |
| 113 | +### [**.NET**](#tab/dotnet-query) |
| 114 | + |
| 115 | +A code example showing query key usage can be found in [DotNetHowTo](https://github.com/Azure-Samples/search-dotnet-getting-started/tree/master/DotNetHowTo). |
| 116 | + |
| 117 | +--- |
77 | 118 |
|
78 | 119 | <a name="regenerate-admin-keys"></a>
|
79 | 120 |
|
80 | 121 | ## Regenerate admin keys
|
81 | 122 |
|
82 |
| -Two admin keys are created for each service so that you can rotate a primary key, using the secondary key for business continuity. |
| 123 | +Two admin keys are created for each service so that you can rotate a primary key while using the secondary key for business continuity. |
| 124 | + |
| 125 | +1. In the **Settings** > **Keys** page, copy the secondary key. |
| 126 | + |
| 127 | +1. For all applications, update the API key settings to use the secondary key. |
83 | 128 |
|
84 |
| -1. In the **Settings** >**Keys** page, copy the secondary key. |
85 |
| -2. For all applications, update the API key settings to use the secondary key. |
86 |
| -3. Regenerate the primary key. |
87 |
| -4. Update all applications to use the new primary key. |
| 129 | +1. Regenerate the primary key. |
88 | 130 |
|
89 |
| -If you inadvertently regenerate both keys at the same time, all client requests using those keys will fail with HTTP 403 Forbidden. However, content is not deleted and you are not locked out permanently. |
| 131 | +1. Update all applications to use the new primary key. |
90 | 132 |
|
91 |
| -You can still access the service through the portal or programmatically. Management functions are operative through a subscription ID not a service API key, and thus still available even if your API keys are not. |
| 133 | +If you inadvertently regenerate both keys at the same time, all client requests using those keys will fail with HTTP 403 Forbidden. However, content isn't deleted and you aren't locked out permanently. |
92 | 134 |
|
93 |
| -After you create new keys via portal or management layer, access is restored to your content (indexes, indexers, data sources, synonym maps) once you have the new keys and provide those keys on requests. |
| 135 | +You can still access the service through the portal or programmatically. Management functions are operative through a subscription ID not a service API key, and are thus still available even if your API keys aren't. |
94 | 136 |
|
95 |
| -## Secure API keys |
| 137 | +After you create new keys via portal or management layer, access is restored to your content (indexes, indexers, data sources, synonym maps) once you provide those keys on requests. |
96 | 138 |
|
97 |
| -[Role assignments](search-security-rbac.md) determine who can read and manage keys. Members of the following roles can view and regenerate keys: Owner, Contributor, [Search Service Contributors](../role-based-access-control/built-in-roles.md#search-service-contributor). The Reader role does not have access to API keys. |
| 139 | +## Permissions to view or manage API keys |
98 | 140 |
|
99 |
| -Subscription administrators can view and regenerate all API keys. As a precaution, review role assignments to understand who has access to the admin keys. |
| 141 | +Permissions for viewing and managing API keys is conveyed through [role assignments](search-security-rbac.md). Members of the following roles can view and regenerate keys: |
| 142 | + |
| 143 | ++ Administrator and co-administrator (classic) |
| 144 | ++ Owner |
| 145 | ++ Contributor |
| 146 | ++ [Search Service Contributors](../role-based-access-control/built-in-roles.md#search-service-contributor) |
| 147 | + |
| 148 | +The following roles don't have access to API keys: |
| 149 | + |
| 150 | ++ Reader |
| 151 | ++ Search Index Data Contributor |
| 152 | ++ Search Index Data Reader |
| 153 | + |
| 154 | +## Secure API key access |
| 155 | + |
| 156 | +Use role assignments to restrict access to API keys. |
| 157 | + |
| 158 | +Note that it's not possible to use [customer-managed key encryption](search-security-manage-encryption-keys.md) to encrypt API keys. Only sensitive data within the search service itself (for example, index content or connection strings in data source object definitions) can be CMK-encrypted. |
100 | 159 |
|
101 | 160 | 1. Navigate to your search service page in Azure portal.
|
| 161 | + |
102 | 162 | 1. On the left navigation pane, select **Access control (IAM)**, and then select the **Role assignments** tab.
|
103 |
| -1. Set **Scope** to **This resource** to view role assignments for your service. |
| 163 | + |
| 164 | +1. In the **Role** filter, select the roles that have permission to view or manage keys (Owner, Contributor, Search Service Contributor). The resulting security principals assigned to those roles have key permissions on your search service. |
| 165 | + |
| 166 | +1. As a precaution, also check the **Classic administrators** tab for administrators and co-administrators. |
104 | 167 |
|
105 | 168 | ## See also
|
106 | 169 |
|
|
0 commit comments