How can CosmosDB's architecture and design make it possible to have a read-write key that works on all customers' databases? Yikes!
...but due to a poor deployment strategy, the instances were not sandboxed from each other.
(and yes, you would be correct in thinking that was a catastrophic failure; it's like having a folder with a directory per customer and a master access key in each folder, and WOOOPS, didn't realize people might look at ../Amazon/master_key.txt
It's pretty hard to brush this one off; it's a colossal screw up)
I’ve seen some azure documentation that stresses you should never ever use your primary keys in a deployed service. Yet they do it willy nilly.
You see the former with a lot of “online Python interpreter” sites.
1. My service's users would have to grant my service permission to read all access keys for the queue
2. My service would look through the access keys and try to find one matching some conditions (specific provided name and read-only)
3. If it couldn't find a limited one (which it would not in pretty much every real case due to the defaults) it would grab any read/write key and use that
(Later, we used Managed Identity when that became available, which avoids the song-and-dance but also has performance issues with very large scale sets. Out of the frying pan...)
I'm wondering if Jupyter had similar ability to read the primary r/w key for every database that had it enabled.
There's a vulnerability in some jupyter notebook implementation allowing them access to unrelated notebooks which hold read/write keys to database they're connected to.