You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
You can assign users and API keys to predefined roles, specifying the
265
+
actions they can perform within |service| organizations, projects, or
266
+
both. Use Identity Federation to manage access by linking your identity
267
+
provider groups to |service| roles through group-role mappings.
268
+
269
+
We recommend that you use a modern federated Identity Provider (IdP) that
270
+
provides SSO, OIDC, and SAML login such as Azure Entra ID, Okta, or Ping
271
+
as this makes the authorization process more secure and supports the
272
+
flexibility needed to programmatically assign :abbr:`IdP (Identity Provider)`
273
+
groups to |service| roles. You should restrict your company's domain from
274
+
preventing users from logging into |service| when they are not authorized
275
+
for access, which you can do by following the procedure in
276
+
`Manage Domain Mapping for Federated Authentication <https://www.mongodb.com/docs/atlas/security/manage-domain-mapping/>`__. From here, we recommend that you map your
277
+
:abbr:`IdP (Identity Provider)` groups to |service| roles as shown in
278
+
`Role Mapping Process <https://www.mongodb.com/docs/atlas/security/manage-role-mapping/#role-mapping-process>`__.
279
+
280
+
If you have followed the standard |service| hierarchy of a single billing
281
+
organization with a linked organization for each {+BU+} or department, then
282
+
you should restrict organization users to the operations or platform team admins.
283
+
In contrast, you should assign project roles to the development or product teams
284
+
responsible for building applications. Only programmatic access should be
285
+
allowed in upper environments. The following recommendations for the most
286
+
commonly used roles can serve as a general guideline:
287
+
288
+
* The ``Organization Owner`` role should be heavily restricted and not assigned
289
+
to a human, as it has the ability to change organization-wide settings and delete
290
+
configurations. This role should be assigned to a service account which you use
291
+
only to initially set up and configure the organization. Minimize configuration
292
+
changes after the initial creation.
293
+
294
+
* The ``Organization Member`` role should be for admins on the operations and
295
+
platform team that can view settings and configuration for the organization.
296
+
297
+
* The ``Organization Project Creator`` role should be a programmatic service
298
+
account used to create projects on behalf of new applications for development
299
+
and product teams.
300
+
301
+
* The ``Organization Billing Admin`` role should be a programmatic service
302
+
account used to pull invoices programmatically from the Billing API
303
+
and feed them into your FinOps tool. This same service account should have
304
+
access to all linked organizations for which it is responsible for reporting usage.
305
+
306
+
* The ``Project Owner`` role should be used for governance enforced by the
307
+
operations and provisioning team. Assign this role to a programmatic service
308
+
account, as it has the ability to create and delete {+clusters+}. For sandbox
309
+
environments, you may consider granting a user ``Project Owner`` access to
310
+
enable them to quickly provision {+clusters+} for testing code and use cases
311
+
without going through the orchestration deployment pipeline.
312
+
313
+
* In lower environments, use the ``Project Data Access Admin`` role to
314
+
grant access to the development team building the application so they can
315
+
access the query and performance metrics of the {+cluster+} during
316
+
development and testing. This access allows them to debug data issues
317
+
with the Data Explorer.
318
+
Don't allow this role in production environments. It has the
319
+
ability to view and edit data, including creating and dropping databases,
320
+
collections, and indexes on the {+cluster+}, which is useful for rapid
321
+
experimentation and development. If you are uncomfortable giving
322
+
development teams this level of access in the development environment, you
323
+
can grant them read-only access to the {+cluster+}\'s data and performance
324
+
statistics with the ``Project Data Access Read Only`` role.
325
+
326
+
To learn more, see :ref:`user-roles`.
327
+
328
+
Recommendations for Database
329
+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
330
+
331
+
Workforce and workload users can be assigned fine-grained database
332
+
roles, predefined or custom, with permissions tailored to specific
333
+
projects or individual {+clusters+}. In staging and production
334
+
environments, we recommend using Identity Federation to streamline
335
+
access management by linking your Identity Provider (IdP) to |service|
336
+
for a more modern and
337
+
streamlined authentication and authorization flow for data access.
338
+
339
+
Only allow workload authentication in production. You can leverage workforce
340
+
authentication during development and in lower environments. By configuring
341
+
'Group Membership' in your :abbr:`IdP (Identity Provider)`, you can map
342
+
groups to database users, simplifying access control within the
343
+
:abbr:`IdP (Identity Provider)`. However, for workload identities, we
344
+
recommend assigning roles directly using the 'users' claim instead of
345
+
'groups.' In development and test environments, you can default to the
346
+
predefined ``readWriteAny`` role to simplify the development and testing process. When moving the application to higher environments, you should build a custom
347
+
role to restrict the access that the application server has based on the
0 commit comments