How does eG Enterprise monitor MongoDB Cluster?

eG Enterprise uses a single eG external agent to monitor the target MongoDB Cluster. The external agent can be deployed on any remote host in the environment.

The eG agent connects to a database on the MongoDB cluster and runs built-in MongoDB API commands to pull the metrics of interest from across databases. To enable this connection, each test that the eG agent runs on the MongoDB cluster server should be configured with the name of a MongoDB database.

In highly secure environments, access control may be enabled on the target MongoDB deployments. Such deployments enforces authentication, which requires users to identify themselves while accessing the MongoDB. eG Enterprise can monitor the MongoDB databases that are access control enabled too. For this administrators need to do the following:

• create a custom role

• assign a user to that role

• Finally, enable access control i.e., authenticate the user.

How to monitor access control enabled MongoDB database?

To monitor the access control enabled MongoDB database, it is essential to create a custom role in the admin database of the MongoDB instance and a user.

• To create a custom role for e.g., egmonrole, issue the following command on the MongoDB instance:

  db.createRole({role: "egmonRole",privileges: [{ resource: { anyResource: true}, actions: [ "serverStatus" ,"dbStats","top", "listDatabases", "getCmdLineOpts", "collStats", "hostInfo", "listCollections", "find", "replSetGetConfig", "replSetGetStatus"] }],roles: [] })

• Once the role is created, you can create a user for e.g., eguser and assign the newly created role i.e., egmonrole to that user by issuing the following command:

  db.createUser({ user: "eguser", pwd: "egurkha", roles: [ "egmonRole" ]} )

• Then, re-start the MongoDB instance with the --auth command line option or, if using a configuration file, the security.authorization setting. If you are using the CLI option, issue the following command:

  mongod --auth --port 27017 --dbpath /data/db1

Once you have created the user, you need to specify the credentials of the user while configuring the tests for the target MongoDB instance being monitored.

Pre-requisites for monitoring MongoDB Cluster Database Server

MongoDB supports TLS/SSL (Transport Layer Security/Secure Sockets Layer) to encrypt all of MongoDB's network traffic. TLS/SSL ensures that MongoDB network traffic is only readable by the intended client. To use TLS/SSL with MongoDB , you must have the TLS/SSL certificates as PEM files, which are concatenated certificate containers. MongoDB can use any valid TLS/SSL certificate issued by a certificate authority or a self-signed certificate.

In addition to the above, you need to fulfill a few more critical pre-requisites, before you can begin monitoring MongoDB Cluster. These requirements vary according to the type/mode of authentication that is enabled for the MongoDB Cluster.

MongoDB Community supports a number of authentication mechanisms that clients can use to verify their identity:

• SCRAM (SCRAM-SHA-1 , SCRAM-SHA-256)- is the default authentication mechanism for MongoDB. When a user authenticates themselves, MongoDB uses SCRAM to verify the supplied user credentials against the user's name, password and authentication database associated with that user. To authenticate clients using this method, create a "user" in a specific database (say admin database) and that database becomes the authentication database for the user. A user's name and authentication database serve as a unique identifier for that user and hence, is used as the database to authenticate against. Although the user needs to authenticate to this database, the user can have roles in other databases. The user's authentication database doesn't limit the user's privileges.

  To monitor a SSL-enabled MongoDB Cluster server, the eG agent requires Client certificate and Server certificate to execute MongoDB cluster commands directly on prompt, and also requires CA.crt, Client.p12 file and password to collect metrics from the server.

• x.509 Certificate Authentication-MongoDB supports x.509 certificate authentication for client authentication and internal authentication of the members of replica sets and sharded clusters. x.509 certificate authentication requires a secure TLS/SSL connection.To use MongoDB with x.509, you must use valid certificates generated and signed by a certificate authority. The client x.509 certificates must meet the client certificate requirements. MongoDB considers X.509 certificates to be an external source. Therefore, users authenticate against the $external database, not the admin database.

  To authenticate with a client certificate, you must first add the value of the subject from the client certificate as a MongoDB user to the $external database. The $external database is the Authentication Databasefor the user. Each unique x.509 client certificate corresponds to a single MongoDB user. You cannot use a single client certificate to authenticate more than one MongoDB user.

  How to add x.509 Certificate subject as a User to the $external database?

  1. Access the target MongoDB cluster node.

     

     Figure 1 : Access target MongoDB node

  2. Then, retrieve the RFC2253 formatted subject from the client certificate with the following command:

     openssl x509 -in test-client.pem -inform PEM -subject -nameopt RFC2253

     where , test-client.pem denotes the client certification file name.

  3. The command returns the subject string as well as certificate. The subject string must be in the following format, that is compatible with RFC2253 standard:subject= CN=myName,OU=myOrgUnit,O=myOrg,L=myLocality,ST=myState,C=myCountry.

     

     Figure 2 : The certificate showing the subject string

  4. Now, switch the primary database to $external database.

     

     Figure 3 : Switching to $external database

  5. Add the RFC2253 compliant value of the subject as a user. Omit spaces as needed. For example, the following adds a user and grants the user readWrite role in the test database and the userAdminAnyDatabase role:

     db.getSiblingDB("$external").runCommand(

     {

     createUser: "CN=myName,OU=myOrgUnit,O=myOrg,L=myLocality,ST=myState,C=myCountry",

     roles: [

     { role: "readWrite", db: "test" },

     { role: "userAdminAnyDatabase", db: "admin" }

     { role: "root", db: "admin" }

     ],

     writeConcern: { w: "majority" , wtimeout: 5000 }

     }

     )

  6. Finally, check the created user information. The user must be same as the subject in the certification file, as shown in Figure 4.

     

     Figure 4 : The details of the user on the $external database

How to import a Certificate that is in the PEM Format?

If the certificate you downloaded is in the PEM format and includes only a certificate file and a private key file, then follow the steps below to import that certificate into .p12 format file .

1. Open a command prompt and navigate to the directory that contains the test-client.pem file.

2. Execute the following OpenSSL command to create a PKCS12 (.p12) file:

   openssl pkcs12 -export -out test-client.p12 -in test-client.pem

   The text in Bold in the above command line indicates those inputs that can change according to the requirements of your environment. These inputs have been described below:

   -in : the name of the certificate that is included in the PEM container

   -inkey: the name of the private key file the PEM container consists of

   -out : Specify the name of the keystore file to which the certificate and private key are to be exported. The keystore file can have any name of your choice.

3. After you enter the command, you'll be prompted to enter an Export Password. This password must be specified in the Client Cert Password Parameter.

4. A file called test-client.p12 is created in this directory. This is your .p12 file.

Obtaining AWS Access Key

The access key of a user with a valid AWS account. Provide the access key in the AWS ACCESS KEY text box which will enable the eG agent to collect the required metrics from the AWS EBS by communicating with the AWS API. To obtain the access key, do the following:

• Sign up for a new AWS account from the http://aws.amazon.com/ page.

• Provide the details of the user for whom you wish to create the AWS account.

• Based on the AWS Regions, you will be requested to choose the pricing for an instance to be deployed in the AWS EBS.

• Once the payment is made, the user will automatically be signed in to the AWS account.

• From the newly created AWS account, you can request for an “access key”. You will be provided with an “access key” and a corresponding “secret key”.

After specifying the access key, confirm it by retyping it in the CONFIRM PASSWORD text box.

Obtaining AWS Secret Key

Provide the secret key corresponding to the access key that you had obtained through your AWS account. To obtain the secret key, do the following:

• Sign up for a new AWS account from the http://aws.amazon.com/ page.

• Provide the details of the user for whom you wish to create the AWS account.

• Based on the AWS Regions, you will be requested to choose the pricing for an instance to be deployed in the AWS EBS.

• Once the payment is made, the user will automatically be signed in to the AWS account.

• From the newly created AWS account, you can request for an “access key”. You will be provided with an “access key” and a corresponding “secret key”.

After specifying the secret key, confirm it by retyping it in the CONFIRM PASSWORD text box.