Traditionally, database users have always been created on a project level in Atlas. This provided a centralized interface for database user management as user privileges were scoped to all clusters in your Atlas project. Customers could manage and revoke user permissions confidently, without fear that the updated permissions would be applied to one cluster but not another.
However, this abstraction created limitations for use cases that required creating database users scoped to specific clusters or Data Lakes. After much anticipation, we now offer the flexibility to refine database access on a more granular level.
Restrict privileges for different environments of the same application
One reason for scoping database users to the resource level is to restrict privileges by environment. For example, you may have a dev cluster, a test/qa cluster, and a prod cluster in the same project, but you don’t want all users to have equal access to all three.
Isolate teams working on different microservices in the same project
Another scenario is to be able to split up users so that certain developers only have access to specific clusters within a project. This is especially useful for customers who have networking restrictions that require them to only use one or two Atlas projects, and therefore co-locate multiple microservices or applications within the same project. With database users per cluster, those customers can now scope team A to only accessing cluster A, and team B to cluster B.
Grant other users to access Atlas Data Lakes for analytics
Finally, this capability also allows admins to restrict a user’s privileges to only Atlas Data Lakes within the project. This is helpful for analysts, data engineers, and other employees who need access to those Data Lakes and not live operational data in a production cluster, for example.
Finer-grained authorization for database users
Today, Atlas customers can already use built-in roles or custom roles to grant privileges to database users. With this update, admins get additional flexibility in the database user authorization model while keeping the authentication model exactly the same––we made sure to maintain all of the great features that database users already have.
Customers can continue to pick from any of the four authentication mechanisms (SCRAM, X.509, LDAP, AWS IAM) supported by Atlas, and choose to create temporary database users that automatically expire within a user-configurable 7-day period, which can be used in conjunction with database auditing to audit any activity performed by a user with elevated privileges.
Database user settings can be modified at any point, so existing users can now be scoped to the cluster or Data Lake-level. Database users with the default authorization settings will continue to have the same access to all resources within an Atlas project.
If you have feedback, please add or upvote requests to our feedback portal.