The last videos off the week gave an overview of MongoDB’s native authentication and authorization. The evolution and several important changes of authentication and authorization, or auth for short reference, were mentioned. Native auth was never a strong point of the system, but kept evolving through 2.4 and 2.6. There’s still some ugly parts to it, but once you understand how it works it’s not so bad.
In my opinion any software trying to implement native auth from the ground up is going to fall short the first couple of tries. At the moment, the way native auth works inside MongoDB it is still falling short. It is however possible to create custom ACL to the level of collections.
For me the most important hurdle is understanding how to authenticate in 2.6 on a database level. All credentials are now stored in the admin database, but to create a user who can authenticate against database XYZ you need to create him/her while XYZ is your current database. That user can only authenticate against XYZ, but still have privileges on other databases.
Not specifying the correct database to authenticate against will fail the attempt, which might be confusing at certain times of the day/night. Personally I expect to authenticate against the server/replica set/cluster, not a particular database. The receiving end should abstract authentication.
At the moment I’m less concerned about auth, so I didn’t delve deeper than what the videos provided.
There were eight final exam assignments, two of them were optional and didn’t count for the grade. I failed to give the correct answer on one question, which made me pass the course with just 92% percent instead of 100%. In hindsight I could have seen the problem and answered the question correct, but sometimes you miss the smallest of log messages when the amount of log statements is huge.
I went through the answers of the exam questions so I could to validate my approaches to the assignments and I learned some new things as well.
I realized that I should have studied more on how to avoid downtime during maintenance. In particular on which database commands can be used to force reconfiguration or lock writes without shutting down one or more MongoDB processes.
The approach in the answer usually didn’t cause significant downtime, but it was unavoidable to keep all functionality of the cluster or replica set all the time. Production systems often have stricter availability requirements and contain more data then could reasonably be used during the assignments. So aside from the simplest way to complete the assignment there were some footnotes on the difference in approach should it have been a production environment.
During the course there were certain moments where I cursed either myself or the system. Sometimes it’s not easy to follow a particular mindset other than your own expectations. It was good to know where to expect the problems and have at least some basic knowledge to solve those problems when they arise. If all else fails, you still need to call in for official support.
At other times I was pleasantly surprised by the progress that has been made. It seems easier to get started with MongoDB, both in programming and administration. There’s still that glass ceiling you might break and the shards will be falling down, but it’s higher now.