I'm using MongoDB 3.2.6 and I want to use Keyfile Access Control for MongoDB replication.
What I read in this link:
https://docs.mongodb.com/manual/tutorial/enforce-keyfile-access-control-in-existing-replica-set/
Enforcing access control on a replica set requires configuring Security between members of the replica set using Internal
Authentication
Unfortunately I can not find in the link below how I enable Internal Authentication:
https://docs.mongodb.com/manual/core/security-internal-authentication/
Should I configure auth = true in the mongo configuration file (and configure users)?
How I enable Internal Authentication?
The opposite question:
If I will enable configure auth = true in the mongo configuration then I have to use Keyfile Access Control for the MongoDB replication (otherwise the MongoDB replication will not work).
Correct?
There is not a separate option to enable internal authentication. Basically, internal authentication and client authentication need to be either both enabled or both disabled.
Note, that specifying the keyFile will implicitly enable authentication (e.g. setting auth=true is redundant/implied and not required). But setting both keyFile and auth is probably a good idea to avoid confusion.
When authentication is enabled and you are running a replica set or sharded cluster, then you must utilize one of the internal authentication mechanisms to allow the members to authenticate and communicate with each other. Meaning you will need to either use a keyFile or x.509 authentication in order for replication/sharding to work.
Related
After reviewing several MongoDB official documents (see list at the bottom) I understand that MongoDB security in communications (as in community version 4.2) works as follows:
For internal communication authentication (i.e. between the members of a replica set or between mongos and the replica sets which implement the different shards) there are two mechanisms available:
shared keyfile (--keyFile)
x.509 certificates
For internal communication encryption, SSL/TLS is the only possibility. In other words, shared keyfile (--keyFile) provides only authentication, but if you want encryption you need to use SSL/TLS alternative. Using SSL/TLS requires to use x.509 certificates also (so, we can say that encryption also provides authentication)
For client to MongoDB communications (either standalone, replica set or mongos in a shard cluster):
there isn't keyfile option
the only way to secure communication (which provides both authentication and encryption) is SSL/TLS with x.509 certificates
I'd like just to confirm my understanding, as the documentation I have browsed is a little "disperse" and I'm not sure if I have got the point. Any feedback, comment, extra info or documentation pointers is really welcome!
PD: the statement which I'm most unsure is this one: "shared keyfile (--keyFile) provides only authentication, but if you want encryption you need to use SSL/TLS alternative"
References checked:
https://docs.mongodb.com/manual/tutorial/configure-ssl
https://docs.mongodb.com/manual/tutorial/configure-ssl-clients/
https://docs.mongodb.com/manual/core/security-internal-authentication
For client to MongoDB communications (either standalone, replica set or mongos in a shard cluster) there are several authentication methods:
No authentication
Internal authentication with username/password
Kerberos Authentication
LDAP Proxy Authentication
LDAP Authentication
Note, you can always connect to MongoDB database, even without an account. However, you are not permitted to execute any command unless you are authenticated.
In the beginning of the year, lots of MongoDB databases were hacked. This also included my database. Yesterday I noticed my brand new database with authorization enabled was hacked as well. The username and password is very secure (16+ characters password with random characters and symbols).
I've now decided to fully secure it, but I honestly don't know where to proceed. I already have:
security:
authorization: enabled
and that should be enough (after sudo service mongod restart). I only have 1 database and no admin user, but anonymous access from a remote connection is still allowed. I keep reading many places, that I should run mongod like mongod --auth, but that it's the same as enabling authorization as I've done above.
At this point I'm struggling to disable anonymous authentication on the server. What did I miss? Why can I authenticate without an account?
To enable security you'll want to follow the Security Checklist on the MongoDB Website.
Here you are provided with role based authorization and authentication instructions. It's also advised you disable listening to all ethernet interfaces and bind your MongoDB ports to the interfaces you'd like exposed.
For a guide to network hardening, you will want to review these instructions, but the most important aspect is to avoid unwanted network exposure. Consider using a firewall or security groups (if in cloud).
We have a recently sharded mongodb cluster. Before sharding, for read-only access, all users used to connect to one of the secondaries. We need a similar read-only access now when users connect to 'mongos' (after sharding). One option is to enable authentication and add user user roles. But that will mean changing java code on some app module which connect to the mongos using the java connector.
Is there a way to obtain read-only access without enabling authentication ?
You can only create read-only roles by enabling authentication. If you do not want to enable authentication, your human users have to specify their read preference explicitly when connecting. As they may forget this, I would advise you enable authentication. It will allow you more granular access in the future and will allow users to continue the data when the secondary servers are down (e.g. maintenance).
I have a mongo replica set with 3 members and they are using keyFile authorisation. I am using Mongoose and from their docs could not find a way to authenticate via a keyFile.
Does Mongoose support it ? if so, how do I specify a keyFile while authenticating ?
You do not authenticate your client via a keyFile. You can setup SSL and use x509 to authenticate. However, a keyFile is for authentication between replication set members. For authentication you must create a user and require authentication in your mongodb config. The user is local to that database in which it is created. x509 requires some extra steps to correlate the key/cert to a given user.
If you have no need for SSL, I'd recommend just creating an admin user for the entire database, then creating a user for the database you're trying to access in your app.
We have a mondogDB deployment currently in our test environment. We have a 7 member Replica Set and no Arbiter.
We want to configure the data replication between the replica set members secure.
We don't want to configure SSL for the clients to our MongoDB cluster as the communication from the client to this MongoDB cluster is via Stunnel. So the client doesn't need to use SSL to connect.
Just curious to see if this possible i.e configure only the data being replicated between replica set members Secure but not the actual communication from the Client to this MongoDB cluster
_THanks much
I've not tried this personally but I do believe you can do this. In addition to compiling mongodb with ssl, or purchasing one of the MongoDb subscriptions that support SSL you will need to run with the following option:
--sslMode
set to preferSSL. This will use SSL for inter-server communications but allow both SSL and non-SSL for other connections:
http://docs.mongodb.org/manual/reference/program/mongod/
That of course is all in addition to the other configuration settings required for running with SSL:
http://docs.mongodb.org/manual/tutorial/configure-ssl/
Note that this is new for version 2.6. I don't have a version of mongodb compiled with ssl support so it's not been tested by me.
#DurgaDeep in MongoDB v2.6 you can run the MongoDB instance in mixed mode SSL while also specifying the x509 certificates for the cluster members to authenticate each other. Please note that SSL is not part of the default community build and you may need to build the binary on your own if you are using community build. x509 certificates is only available on subscription builds so that will not work for you if you are using a community build.
The easiest option to achieve what you want to do irrespective of the MongoDB version would be to setup stunnel between the replica-set nodes and let it take care of encrypted channel independently. This is the usual route a lot of applications take which do not have SSL embedded as an option.