Notes on "DynamoDB now supports cross-account access. But is that a good idea?"

Notes on DynamoDB now supports cross-account access. But is that a good idea?

DynamoDB announced support for resource-based policies a few days ago. It makes cross-account access to DynamoDB tables easier. You no longer need to assume an IAM role in the target table’s account.

I share the concern in the article: is this a good idea?

..., a microservice should own its data and shouldn’t share a database with another microservice.

...

When a service needs to access another service’s data, it should go through its API. It shouldn’t reach in and help itself to their data. It’s insecure and creates a hidden coupling between the two services.

I see this every time: why go through the extra loops of using an API when the data is available straight from the database? APIs add extra costs, require custom coding instead of using the AWS SDK, and, of course, less features. It's usually an uphill battle when the general consensus is to "get things done".

My view is that the quality of software can be defined by how many surprises its users and developers will have when using/developing the software, the fewer the better. And going straight to a database instead of an API adds surprises: change the data structure and now that other system is broken. How can you know if a change is breaking or not?

While I welcome the new feature as there are genuine use-cases for it, cross-account DynamoDB access is usually a bad idea.

The article lists a couple of good use-cases but there is one that I particularly like:

Another layer of access control

Resource-centric access control is powerful to protect sensitive resources. Adding a DENY with a NotPrincipal allows defining policies like "only this Lambda function can delete data from this table".

Without this, a misconfigured identity-based policy can inadvertently open access to more sensitive resources. A developer needs to investigate a bug and is granted read access to all tables gets access to all the stored session tokens, for example. Adding a resource-based policy to the most sensitive tables prevents this scenario. I wrote about it in this article.