in my Azure Cosmos DB account, I can add multiple databases (containing multiple collections).
However, I only seem to find account-level connection strings (secrets), that are valid for each database. Differing only in the database name section.
I find this odd. Is this expected? If I want more granular control do I need to create separate accounts for each database?
PS: I'm using the Mongo API if it's somehow relevant.
Cheers
The account-level connection strings you mentioned in the question is master key.Based on this document, Azure Cosmos DB uses two types of keys to authenticate users and provide access to its data and resources.
Master keys cannot be used to provide granular access to containers and documents.
If you want more granular control,please get an idea of Resource Tokens which provides access to specific containers, partition keys, documents, attachments, stored procedures, triggers, and UDFs.More details,please refer to this link.
Related
in the project i am working on, we have a database per tenant and each tenant consists of at least 1 department. One of the requirements we have is that when an admin user deletes a department using a custom frontend we've provided, the system should first archive the data of that department on a blob storage before the data is deleted. The same we have for the tenant, we need to archive the data before the database of that tenant is removed from the account.
Now, my question: is there any best practice to do this? We are planning to retrieve all the data from all collections, using a mongo query, based on the department id (which is also the partition key) and then send it to a blob storage. The challenge we have is the execution of the query to retrieve all the data because it can be a huge amount and the RUs required for that action may affect the performance of the system because other users may be using the system while we remove the data.
I looked at mongodump and mongoexport but these are applications so we cannot execute it from our code?
Any ideas? Thanks a lot.
I think one way to solve this is by using ChangeFeed, as it reallyhelps and simplifies writing a carbon copy somewhere else.
However, as of now the change feed processor won't notify you for deleted documents so you can't listen for them, this feature is planned as of now.
Your best bet is to write some custom application that does archiving using Query language support
Is it possible to review the history of changes to the setting of an Azure Cosmos database. I believe I am colliding with another them who is using the same Cosmos database. I would like to review all the setting that have changed since the database was created. Is that possible?
You can audit control plane operations for any Cosmos DB resource once it has been created. However, the account must be configured such that all control plane operations are done against the Cosmos DB resource provider and not through one of the data plane SDKs. See the link for details on this.
However, ARM does not support providing information on when a resource was created. This is a limitation of ARM, not Cosmos DB.
If you just wanna watch who did operations on your cosmos database, I think 'Activity Log' tab could help you. It records some message like screenshot below.
But I found that I can't get the details of the operations such as changing RU. By the way, I didn't find any documents saying how to review operations in cosmosdb. Or maybe you can provide more details about what information you wanna get from cosmosdb?
I have an AppSync app defined using a master CloudFormation stack and more than a dozen nested stacks. Each nested stack defines a DynamoDB table, an AppSync DataSource for that table, and an IAM role for that DataSource to access that table. The DataSource depends on the role, which depends on the table.
I would like to consolidate these IAM roles, for three reasons:
The role definitions are very repetitive and boilerplate-y.
There are many copies of this app, and it adds up to a lot of IAM roles — enough that we're running close to the soft limits.
Some resolvers use DynamoDB batch operations to access multiple tables, so at least some of the IAM roles must grant access to multiple tables anyway.
I do not want to give the role blanket access to all DynamoDB tables in the account.
The simplest way to grant one role access to every required table would be to list them manually in the policy document. This has the obvious downside of requiring that the policy be manually kept in sync when new tables are added. However, there is also a dependency problem: the DataSource in a nested stack depends on a role in the master stack, which depends on tables in the nested stacks.
I would have liked to use tags: grant for all DynamoDB tables that have a certain tag, then set that tag for each table. This way, the IAM role would not need to be edited when a new table was added. But apparently DynamoDB does not support tag-based conditions.
Is there an easy way to grant a single IAM role access to many DynamoDB tables without granting access to all of DynamoDB and without individually listing the tables in the role?
If you can name your tables in a way that gives them the same prefix you can use wildcards in the resource.
arn:aws:dynamodb:<Region>:<Account>:table/MyPrefix-*
That will work on all tables that start with MyPrefix-
If you are using generated names you can probably use the AWS::StackName value in place of MyPrefix but be aware that with nested stacks that value may get shortened.
We have several app service APIs which will read from same Cosmos DB. We want each API use different connection string for security reason. But from Azure portal, seems we can only have 2 master connection strings and 2 read-only connection strings.
Can I generate more read-only connection strings?
That is not directly supported, but there are other ways to achieve what you're looking for.
Essentially, you are now using the 'Master Keys' approach to define your connection string. You are building it by specifying the account and one of the 2 master keys to access your data.
The only other approach available is the 'Resource Token' approach. In this architecture you'd have a middleware tier that is configured with a secure connection to your Cosmos account using one of the master keys, and all the applications (that need to be individually secured) call on to this layer for an access token.
In this approach you will have to manage authentication of your clients to your middleware so it's definitely more involved, but ultimately more secure, especially if your APIs are deployed outside of your environment.
See the official docs page for all the details about Resource Tokens.
Our application uses Cosmos DB to store data. The DB is partitioned based on User ID and all backend services work fine using the User ID.
However, we have a UI where only admins have access and they are different from the users stored in DB. They fetch data from DB based on time. That is, get reports from DB for last 3 days (doesn't matter what user ID). In this case, the query needs to fan out to all partitions. Moreover, stored procedures are scoped per partition and cannot be used in this scenario. Even though we are able to fetch data through query, it's a huge performance hit.
Can anybody please advise if there is a way in Cosmos DB to workaround this?