Latest news about Bitcoin and all cryptocurrencies. Your daily crypto news habit.
The MongoDB database administrators in a large enterprise may need to configure MongoDB to support Kerberos Authentication. The configuration of MongoDB with Kerberos authentication is very simple, provided you have some Kerberos knowledge. The MongoDB documentation article, Configure MongoDB with Kerberos Authentication on Linux, is pretty extensive on this topic. However, the article statesââââSetting up and configuring a Kerberos deployment is beyond the scope of this documentâ, resulting in some of the starters/enthusiasts with limited knowledge in Kerberos not proceed any further. This article is geared more towards bridging that gap and to help you understand
- How Kerberos Works
- How to set up Kerberos and MongoDB in your lab
- Finally, How to integrate MongoDB with Kerberos authentication
This is one of the many articles in multi-part series, Mastering MongoDBâââOne tip a day, solely created for you to master MongoDB by learning âone tip a dayâ. In a few series of articles, I would like to give various tips to tighten the security on MongoDB. In this article, I would discuss âHow to Integrate MongoDB with Kerberos Authenticationâ.
MasteringâââMongoDB with Kerberos Authentication
What is a Kerberos
Kerberos is a computer network authentication protocol. It is designed to provide strong authentication for client/server applications by using secret-key cryptography. It works on the basis of tickets to allow nodes communicating over a non-secure network, to prove their identity to one another in a secure manner. The Kerberos protocol messages are protected against eavesdropping and replay attacks. The protocol was named after the character Kerberos (or Cerberus) from Greek mythology, the ferocious three-headed guard dog of Hades.
How does Kerberos work
Instead of asking the client to enter username/password credentials for every service they access, the Kerberos allows single sign-on by using the tickets. These proof of identity tickets are issued by a trusted 3rd party (Key Distribution Center) and are typically encrypted with a secret/symmetric key. This section discusses how various resources within the Kerberos Realm interacts with each other during the authentication process.
Key Distribution Center
In order to administer the access to a resource via Kerberos, all of the components, services, and users must be in the Kerberos Realm. The Kerberos Distribution Center (KDC) is at the core of the Kerberos Realm and has following key server components
- Database ServerâââStores secret keys of registered users and Services
- Authentication ServerâââProvides a ticket to access Ticket-Granting Server
- Ticket-Granting ServerâââProvides a ticket to access the service of interest
The KDCâs database stores all of the secret keys for user machines and services. The secret keys are in-turn a hash value of the password plus a salt. The database itself is further encrypted with a master key to prevent anyone stealing keys from the databaseâs file system.
The flow of events during the authentication process
Letâs say you want to access the MongoDB Service using Kerberos authentication. During the authentication process, the following resources process/exchange information with a defined objective
- Client. Objective: Login using kinit
- Client and Authentication Service. Objective: Get Ticket-Granting-Ticket
- Client and Ticket-Granting Service. Objective: Get Service Ticket
- Client and MongoDB Service. Objective: Get access to MongoDBÂ Service
The sequence of events occurring during Kerberos authentication process
The above diagram shows various resources/components involved in the Kerberos authentication process and illustrates how they interact with each other. Letâs try to understand the internal details of each step.
Please pay special attention to the color of the lock icon, an encrypted message. It can only be decrypted by the resource having the same colored secret key.Login using kinit
The User (AKA Client/Principal) must introduce themselves to the Authentication Server by logging into the computer, or by running the command kinit <username>
Communication between the User and the Authentication Server
Every User must have a Ticket-Granting Ticket (TGT) issued by Authentication Server before accessing any Service. The TGT is a ticket that allows the user to get Tickets for accessing services of their interest.
The Userâs objective is to get a Ticket-Granting Ticket by sending a request to Authentication Server. The request message contains
- Username: Username / Client IDService Requested: Ticket-Granting ServiceNetwork Address: Clientâs IP AddressExpiration: Lifetime of TGTTimestamp: When the request message was created
The Authentication Server processes the request and checks if Timestamp in the message is within 5 min, checks if the User and requested Service are in KDC. It finally issues a Ticket-Granting Ticket, generates and shares Ticket-Granting Session Key with the User.
The Authentication Server responds to the Userâs request with two messages. The Response #1 is encrypted with Client Secret Key (Cyan color key) and the message has below contents â
- Service: Ticket-Granting ServiceTimestamp: When it was createdValidity: Lifetime of TGTTGS Session Key (Magenta color key )
The Response #2 is Ticket Granting Ticket, TGT, which is encrypted with TGS Secret Key (Yellow color key). It can only be decrypted by KDC. The message has below contents â
- Username: Your Name / IDService: Ticket-Granting ServiceTimestamp: When it was createdNetwork Address: IP AddressValidity: Lifetime of TGTTGS Session Key
The Client processes Authentication Service response and decrypts Response #1 using the User's Secret Key (Cyan color key). Upon successful decryption, both the User and the KDC has TGS Session Key (Magenta color key ). The TGS Session Key is used for encrypting the communication between the Client and the Ticket Granting Server. The Client cannot decrypt the Response #2, TGT, as it does not have TGS Secret Key but it would be stored within clientâs credential cache.
Communication between the User and the Ticket-Granting Server
With the Ticket-Granting Ticket in hand, the client can request Ticket-Granting Server for a ticket to access the MongoDB Service. Upon validating the TGT, the Ticket Granting Server will issue a Service Ticket, STKT, to request access for MongoDBÂ Server.
The Userâs objective is to get a Service Ticket by sending a request to Ticket Granting Server. The Request #1 message has below contents â
- Validity: Lifetime of TGTService Requested: MongoDB ServiceTicket-Granting Ticket (only KDC can decrypt)
The Request #2 is encrypted with TGS Secret Key (Magenta color key) and the message has below contents â
- Username: Your Name / IDTimestamp: When it was created
The Ticket-Granting Server processes the request, checks if Timestamp in the message is within 5 min, checks if the service MongoDB Service is registered with KDC. It finally issues a Service Ticket, generates and shares MongoDB Service Session Key (Royal Blue color key) with the User.
The Ticket Granting Server responds to the Userâs request with two messages. The Response #1 is encrypted with TGS Session Key (Magenta color key) and the message has below contents â
- Service Requested: MongoDB ServiceTimestamp: When it was createdValidity: Lifetime of TGTService Session Key (Royal Blue key )
The Response #2 is encrypted with MongoDB Secret Key (Green color key) and can be decrypted only by MongoDB Server. The message has below message contents â
- Username: Your Name / IDService: MongoDB ServiceTimestamp: When it was createdNetwork Address: IP AddressValidity: Lifetime of STKTMongoDB Service Session Key
The MongoDB Service Session Key is used for encrypting the communication between the User and the MongoDB server. The Client cannot decrypt the Response #2, STKT, as it does not have MongoDB Secret Key but it would be stored within the clientâs credential cache.
Communication between the User and the MongoDBÂ Service
With the Service Ticket in hand, the client can send a login request to MongoDB Server. The MongoDB Server will validate the Service Ticket and sets the authorized roles and privileges for the User's login session.
The Userâs objective is to get access to MongoDB Service by sending a login request to MongoDB Server. The Request #1 is encrypted with MongoDB Session Key (Royal Blue color key) and the message has below contents â
- Username: Your Name / IDTimestamp: When it was created
The Request #2 is the Service Ticket itself which can be decrypted only by MongoDB Server using itâs Secret Key (Green color key). The message has below contents â
- Username: Your Name / IDService: MongoDB ServiceTimestamp: When it was createdNetwork Address: IP AddressValidity: Lifetime of STKTMongoDB Service Session Key
The MongoDB Server processes the request, checks if Timestamp in the message is within 5 min, checks if the User is registered with the database. It finally sets the roles and privileges for the User.
The MongoDB Server responds to the Userâs request with a message. The Response #1 is encrypted with MongoDB Session Key (Royal Blue color key) and the message has below contents â
- Username: Your Name / IDService: MongoDBÂ Service
The Client processes MongoDB Service response and decrypts Response #1 using the MongoDB Session Key (Royal Blue color key). Upon successful decryption, and validation, the Client would communicate directly with the MongoDB Server for further database requests.
I know itâs a lot of information to digest especially if you have no knowledge of Kerberos. For further reading on Kerberos, I strongly recommend you to read Lynn Rootâs article Explain like Iâm 5: Kerberos and/or watch the YouTube video KerberosâââCompTIA Security by Professor Messer.
Hands-On lab exercises
Now that you understood the theory and information flow during Kerberos authentication, let's work on setting up a lab environment. This lab exercise helps you understand how to set up Kerberos, MongoDB and configure a client to use them on a CentOSÂ 7.5.
Setup environment
First, you would need an environment to play around. In this example, I have created 3 AWS EC2 instances, one for each serverâââKDC, MongoDB Server and User machine. If you are short on resources, you could potentially install them all on the same lab server.
Please make sure to configure your firewall/security groups to allow incoming traffic on ports 88, 749, 27017 for respective services.
Installing & Configuring KDCÂ Server
Login to the KDC server to install/configure the Kerberos Server.
For your convenience, I am illustrating how the file contents would look like after running the above commands.
Next, you need to create a Kerberos database for the Realm and create the Principal entries for the Users, Services etc
Setup the MongoDBÂ Server
Login to the MongoDB server to install/configure the MongoDB Server, mdb01.mdbkrb5.net
Next, you would need to install the MongoDB Enterprise server, create the MongoDB keyfile, configure the /etc/mongod.conf file, etc
Create a keytab file to store Kerberos service principals and encrypted keys
Set the folders permissions to only allow the user mongod to read them.
Finally, letâs create the following in MongoDBÂ server
- superuser with root privileges
- alex Principal with root role on admin database
- bob Principal with readWrite role on social database
Install MongoDB client on the client01.mdbkrb5.net
Login to the MongoDB client server to install the Kerberos and MongoDBÂ clients.
First, install the MongoDB shell and Enterprise dependencies using Yum.
Login to the Kerberos as bob and then log in to the MongoDB Server to test the readWrite permissions on the social database.
If you run the same tests for the user, alex, then you would be able to query both social and admin databases because of his root role.
Summary
As stated at the beginning of the articleââââConfiguring MongoDB with Kerberos Authentication is very simple!â. However, without proper Kerberos knowledge, your hands are pretty much tied-down to do a simple POC.
Hopefully, this article has simplified the understanding of Kerberos events, and shed some light on âHow to integrate MongoDB with Kerberos Authenticationâ.
The MongoDB Enterprise provides integration with Kerberos as well as LDAP authentication mechanisms. Although the MongoDB is using Kerberos Authentication, the user management still requires the User privileges to be created in the MongoDB. If your organization has 100s of users requiring access to MongoDB then you may to explore the use of LDAP for both authentication and authorization. But thatâs a topic for another day. Hopefully, you learned something new today as you scale the path to âMastering MongoDBâââOne tip a dayâ.
Previously published articles
- Tip # 005: Getting started with MongoDB Enterprise OperatorNow you could deploy MongoDB in Kubernetes under a minute
- Tip # 004: Faster electionsMeasures to reduce the election time during the rolling maintenance
- Tip # 003: TransactionsA long awaited and most requested feature for many, has finally arrived
- Tip # 002: createRoleAhhh âŠ! Someone just dropped a collection
- Tip # 001: currentOpKnow the operations currently executing on MongoDB server inside out
Configure MongoDB with Kerberos Authentication was originally published in Hacker Noon on Medium, where people are continuing the conversation by highlighting and responding to this story.
Disclaimer
The views and opinions expressed in this article are solely those of the authors and do not reflect the views of Bitcoin Insider. Every investment and trading move involves risk - this is especially true for cryptocurrencies given their volatility. We strongly advise our readers to conduct their own research when making a decision.