We rely on MongoDB for many of our data storage needs, and this is done through their developer data platform known as Atlas. If you want to learn more about this technology, feel free to read more here.

Ownership

Our MongoDB organization should be managed by the Head of Engineering. The ownership entails making sure we are keeping and accessing data in an efficient manner while making sure only the right people and sources are accessing our data.

Access

Data within our organization’s instance needs to be accessed by many people throughout it’s lifecycle. This access may come from a developer working on a new API endpoint, or by the lead of the API team needing the set up new silo. It is crucial that only API developers have access to Atlas directly as the rest of the developers should be access developer data through the Nebula API.

Atlas has 6 roles to manage permissions at the organizational level:

• Organization Owner

• Organization Project Creator

• Organization Billing Admin

• Organization Billing Viewer

• Organization Read Only

• Organization Member

Atlas also has 8 roles to manage permissions at the project level:

• Project Owner

• Project Cluster Manager

• Project Data Access Admin

• Project Data Access Read/Write

• Project Data Access Read Only

• Project Search Index Editor

• Project Read Only

• Project Stream Processing Owner

These two sets of roles can be used to ensure that everybody has access to only the resources they need to be using, and the current application of the roles can be seen in this table:

Transfer

The transfer process for each leadership position is going to look a bit different

Head of Engineering

• Transfer ownership of the Mongo Atlas organization

• Explain how we use it to achieve our data storage needs

• Explain the permissions system so that it can continued to be managed going forward

The Head of Engineering (HoE) should be signing into Mongo using the HoE email (head-of-engineering@utdnebula.com) provided through the HoE Google Group. The new HoE can gain access to this email once they are *******added to the HoE group, and then they can sign into Mongo here. This will require transferring the password and 2FA, but after doing so the account transfer is complete. During this process the existing HoE can use the time to dive into why we use Mongo and how to manage the permissions for this application.

Treasurer

• Transfer the billing account for the Mongo Atlas organization

• Explain how billing works for Mongo

The Treasurer should be signing into Mongo using the Treasurer email (treasurer@utdnebula.com) provided through the Treasurer Google Group. The new Treasurer can gain access to this email once they are *******added to the Treasurer group, and then they can sign into Mongo here. This will require transferring the password and 2FA, but after doing so the account transfer is complete. During this process the existing Treasurer can explain how all Mongo billing is done through ***Google Cloud Marketplace.

Lead of API

• Transfer the Lead of API account for the Mongo Atlas organization

• Explain all the data collections

• Remove all old access keys & explain how to set up new ones

The Lead of API should be signing into Mongo using the Lead of API email (lead-of-api@utdnebula.com) provided through the Lead of API Google Group. The new Lead of API can gain access to this email once they are *******added to the Lead of API group, and then they can sign into Mongo here. This will require transferring the password and 2FA, but after doing so the account transfer is complete. This transfer process is extremely important as the Lead of API is currently the manager of all data within our Mongo Atlas organization, so it is important the new lead becomes very familiar with it.