Secure access to data in Azure Cosmos DB

This article provides an overview of securing access to data stored in Microsoft Azure Cosmos DB.

Azure Cosmos DB uses two types of keys to authenticate users and provide access to its data and resources.

Key type Resources
Master keys Used for administrative resources: database accounts, databases, users, and permissions
Resource tokens Used for application resources: containers, documents, attachments, stored procedures, triggers, and UDFs

Master keys

Master keys provide access to all the administrative resources for the database account. Master keys:

  • Provide access to accounts, databases, users, and permissions.
  • Cannot be used to provide granular access to containers and documents.
  • Are created during the creation of an account.
  • Can be regenerated at any time.

Each account consists of two Master keys: a primary key and secondary key. The purpose of dual keys is so that you can regenerate, or roll keys, providing continuous access to your account and data.

In addition to the two master keys for the Cosmos DB account, there are two read-only keys. These read-only keys only allow read operations on the account. Read-only keys do not provide access to read permissions resources.

Primary, secondary, read only, and read-write master keys can be retrieved and regenerated using the Azure portal. For instructions, see View, copy, and regenerate access keys.

Access control (IAM) in the Azure portal - demonstrating NoSQL database security

Key rotation

The process of rotating your master key is simple.

  1. Navigate to the Azure portal to retrieve your secondary key.
  2. Replace your primary key with your secondary key in your application. Make sure that all the Cosmos DB clients across all the deployments are promptly restarted and will start using the updated key.
  3. Rotate the primary key in the Azure portal.
  4. Validate the new primary key works against all resource. Key rotation process can take any where from less than a minute to hours depending on the size of the Cosmos DB account.
  5. Replace the secondary key with the new primary key.

Master key rotation in the Azure portal - demonstrating NoSQL database security

Code sample to use a master key

The following code sample illustrates how to use a Cosmos DB account endpoint and master key to instantiate a DocumentClient and create a database:

//Read the Azure Cosmos DB endpointUrl and authorization keys from config.
//These values are available from the Azure portal on the Azure Cosmos DB account blade under "Keys".
//Keep these values in a safe and secure location. Together they provide Administrative access to your Azure Cosmos DB account.

private static readonly string endpointUrl = ConfigurationManager.AppSettings["EndPointUrl"];
private static readonly string authorizationKey = ConfigurationManager.AppSettings["AuthorizationKey"];

CosmosClient client = new CosmosClient(endpointUrl, authorizationKey);

The following code sample illustrates how to use the Azure Cosmos DB account endpoint and master key to instantiate a CosmosClient object:

HOST = config.settings["host"]
MASTER_KEY = config.settings["master_key"]

DATABASE_ID = config.settings["database_id"]
CONTAINER_ID = config.settings["container_id"]
PARTITION_KEY = PartitionKey(path="/username")

# User that you want to give access to
USERNAME, USERNAME_2 = "user", "user2"


def create_user_if_not_exists(db, username):
        user = db.create_user(body={"id": username})
    except exceptions.CosmosResourceExistsError:
        user = db.get_user_client(username)

    return user

def create_permission_if_not_exists(user, permission_definition):
        permission = user.create_permission(permission_definition)
    except exceptions.CosmosResourceExistsError:
        permission = user.get_permission(permission_definition["id"])

    return permission

def token_client_upsert(container, username, item_id):
                "id": item_id,
                "username": username,
                "msg": "This is a message for " + username,
    except exceptions.CosmosHttpResponseError:
        print("Error in upserting item with id '{0}'.".format(item_id))

def token_client_read_all(container):
        items = list(container.read_all_items())
        for i in items:
    except exceptions.CosmosResourceNotFoundError:
        print("Cannot read items--container '{0}' not found.".format(
    except exceptions.CosmosHttpResponseError:
        print("Error in reading items in container '{0}'.".format(

def token_client_read_item(container, username, item_id):
        item = container.read_item(item=item_id, partition_key=username)
    except exceptions.CosmosResourceNotFoundError:
        print("Cannot read--item with id '{0}' not found.".format(item_id))
    except exceptions.CosmosHttpResponseError:
        print("Error in reading item with id '{0}'.".format(item_id))

def token_client_delete(container, username, item_id):
        container.delete_item(item=item_id, partition_key=username)
    except exceptions.CosmosResourceNotFoundError:
        print("Cannot delete--item with id '{0}' not found.".format(item_id))
    except exceptions.CosmosHttpResponseError:
        print("Error in deleting item with id '{0}'.".format(item_id))

def token_client_query(container, username):
        for item in container.query_items(
            query="SELECT * FROM my_container c WHERE c.username=@username",
            parameters=[{"name": "@username", "value": username}],
            print(json.dumps(item, indent=True))
    except exceptions.CosmosHttpResponseError:
        print("Error in querying item(s)")

def run_sample():
    client = cosmos_client.CosmosClient(HOST, {"masterKey": MASTER_KEY})

Resource tokens

Resource tokens provide access to the application resources within a database. Resource tokens:

  • Provide access to specific containers, partition keys, documents, attachments, stored procedures, triggers, and UDFs.
  • Are created when a user is granted permissions to a specific resource.
  • Are recreated when a permission resource is acted upon on by POST, GET, or PUT call.
  • Use a hash resource token specifically constructed for the user, resource, and permission.
  • Are time bound with a customizable validity period. The default valid time span is one hour. Token lifetime, however, may be explicitly specified, up to a maximum of five hours.
  • Provide a safe alternative to giving out the master key.
  • Enable clients to read, write, and delete resources in the Cosmos DB account according to the permissions they've been granted.

You can use a resource token (by creating Cosmos DB users and permissions) when you want to provide access to resources in your Cosmos DB account to a client that cannot be trusted with the master key.

Cosmos DB resource tokens provide a safe alternative that enables clients to read, write, and delete resources in your Cosmos DB account according to the permissions you've granted, and without need for either a master or read only key.

Here is a typical design pattern whereby resource tokens may be requested, generated, and delivered to clients:

  1. A mid-tier service is set up to serve a mobile application to share user photos.

  2. The mid-tier service possesses the master key of the Cosmos DB account.

  3. The photo app is installed on end-user mobile devices.

  4. On login, the photo app establishes the identity of the user with the mid-tier service. This mechanism of identity establishment is purely up to the application.

  5. Once the identity is established, the mid-tier service requests permissions based on the identity.

  6. The mid-tier service sends a resource token back to the phone app.

  7. The phone app can continue to use the resource token to directly access Cosmos DB resources with the permissions defined by the resource token and for the interval allowed by the resource token.

  8. When the resource token expires, subsequent requests receive a 401 unauthorized exception. At this point, the phone app re-establishes the identity and requests a new resource token.

    Azure Cosmos DB resource tokens workflow

Resource token generation and management is handled by the native Cosmos DB client libraries; however, if you use REST you must construct the request/authentication headers. For more information on creating authentication headers for REST, see Access Control on Cosmos DB Resources or the source code for our .NET SDK or Node.js SDK.

For an example of a middle tier service used to generate or broker resource tokens, see the ResourceTokenBroker app.


Azure Cosmos DB users are associated with a Cosmos database. Each database can contain zero or more Cosmos DB users. The following code sample shows how to create a Cosmos DB user using the Azure Cosmos DB .NET SDK v3.

//Create a user.
Database database = benchmark.client.GetDatabase("SalesDatabase");

User user = await database.CreateUserAsync("User 1");


Each Cosmos DB user has a ReadAsync() method that can be used to retrieve the list of permissions associated with the user.


A permission resource is associated with a user and assigned at the container as well as partition key level. Each user may contain zero or more permissions. A permission resource provides access to a security token that the user needs when trying to access a specific container or data in a specific partition key. There are two available access levels that may be provided by a permission resource:

  • All: The user has full permission on the resource.
  • Read: The user can only read the contents of the resource but cannot perform write, update, or delete operations on the resource.


In order to run stored procedures the user must have the All permission on the container in which the stored procedure will be run.

Code sample to create permission

The following code sample shows how to create a permission resource, read the resource token of the permission resource, and associate the permissions with the user created above.

// Create a permission on a container and specific partition key value
Container container = client.GetContainer("SalesDatabase", "OrdersContainer");
    new PermissionProperties(
        id: "permissionUser1Orders",
        permissionMode: PermissionMode.All,
        container: benchmark.container,
        resourcePartitionKey: new PartitionKey("012345")));

Code sample to read permission for user

The following code snippet shows how to retrieve the permission associated with the user created above and instantiate a new CosmosClient on behalf of the user, scoped to a single partition key.

//Read a permission, create user client session.
PermissionProperties permissionProperties = await user.GetPermission("permissionUser1Orders")

CosmosClient client = new CosmosClient(accountEndpoint: "MyEndpoint", authKeyOrResourceToken: permissionProperties.Token);

Add users and assign roles

To add Azure Cosmos DB account reader access to your user account, have a subscription owner perform the following steps in the Azure portal.

  1. Open the Azure portal, and select your Azure Cosmos DB account.
  2. Click the Access control (IAM) tab, and then click + Add role assignment.
  3. In the Add role assignment pane, in the Role box, select Cosmos DB Account Reader Role.
  4. In the Assign access to box, select Azure AD user, group, or application.
  5. Select the user, group, or application in your directory to which you wish to grant access. You can search the directory by display name, email address, or object identifiers. The selected user, group, or application appears in the selected members list.
  6. Click Save.

The entity can now read Azure Cosmos DB resources.

Delete or export user data

Azure Cosmos DB enables you to search, select, modify and delete any personal data located in database or collections. Azure Cosmos DB provides APIs to find and delete personal data however, it’s your responsibility to use the APIs and define logic required to erase the personal data. Each multi-model API (SQL, MongoDB, Gremlin, Cassandra, Table) provides different language SDKs that contain methods to search and delete personal data. You can also enable the time to live (TTL) feature to delete data automatically after a specified period, without incurring any additional cost.


For information about viewing or deleting personal data, see Azure Data Subject Requests for the GDPR. For more information about GDPR, see the GDPR section of the Service Trust portal.

Next steps