MongoDB Security: Making Things Secure by Default
summary
MongoDB deployments receive concrete steps: enable authentication (or bootstrap a first admin user before turning it on), use a shared keyfile for internal replica-set auth, and add SSL certificates to encrypt intra-node traffic. Sharded clusters require migrating admin users into the config servers or authentication breaks. LDAP/AD via SASL is supported for centralized login. Backups often become the weakest link—store them encrypted and restrict S3 access. Overhead from SSL is small; keyfile is easier for isolated networks.
AI-written summary · about
chapters (11)
- 0:00Recent Security Problems
- 1:07Agenda
- 1:45Installing MongoDB
- 3:36Enabling authentication
- 5:25Default Roles
- 6:27Creating a standard user
- 7:04Testing the standard user access
- 7:23Starting a replica-set with key file
- 8:43Starting a replicaset/shard with key file
- 11:23Enhanced security
- 13:38Rate this session
related talks
34mMongoDB Security
58mAuthentication and Authorization in MongoDB
42mHow AWS and MongoDB raise the security bar with distributed ownership
54mNoSQL Shouldn’t Mean NoSecurity
18mBulletproofing your YugabyteDB Infrastructure to Reduce Risk
24mMoving MongoDB to the Cloud: Strategies and points to consider
32mAchieving PCI Compliance With Percona Server for MongoDB, or Getting as Close as Possible
22mEnterprise Authentication for Percona Server for MongoDB - LDAP and Kerberos