Can we face any issues to migrate from Percona mongodb to MongoDB enterprise edition ?
2 Likes
Hi Murali.
Well, PSMDB doesn’t support KMIP Key server integration like MongoDB Enterprise. So if you were using Data-at-rest encryption you would be obliged to use Hashicorp Vault servers for storing master keys instead of KMIP server.
Another difference at the moment is the PSMDB doesn’t yet support AWS IAM authentication as MongoDB enterprise 4.4+ does.
But for the other enterprise features such as Audit logs, LDAP and Kerberos authentication, the in-memory storage engine, these are all supported and are expected to work exactly the same.
The migration process is to simply stop a node, uninstall mongodb-enterprise package, install the percona-server-mongodb package of the same version number, and restart. No need to change the config file even. (Except if you used KMIP as the key server for data-at-rest encryption).
Repeat that changeover node by node in each replicaset. It’s the same as doing a rolling restart to upgrade to the next minor version, it’s only that you’ll be changing from mongodb enterprise 4.x.y to percona server mongodb 4.x.y-a etc. Upgrading to a latest minor version within the same major version range is O.K. too.
For reference about the feature comparison: Percona Server for MongoDB® Feature Comparison
2 Likes
Hi Percona Team,
Thanks for the mail.
We suggested migrating our community mongo to percona mongodb. Our leadership worried about the rollback plan which includes
- Revert back to community/enterprise edition from percona if any issues observed , Any risks in this?
- In case in future if we want to migrate our percona mongodb version to enterprise mongodb version , is it possible or any issues in it?
- Can we implement tenant or db specific key rotations for encryption at the rest database.
2 Likes
Hi Murali.
To answer 1 and 2: The migration from PSDMB to MongoDB Enterprise will be fine, with the exceptions mentioned before (eg. KMIP vs. Hashicorp Vault). There isn’t an issue such as PSMDB having data files with binary formats that differ to what MongoDB Enterprise (or Community) edition has.
I see that you’re planning to use data-at-rest encryption. You can stop a PSMDB node using Hashicorp Vault; uninstall PSMDB binaries, install MongoDB Enterprise binaries and configure it to connect to a KMIP server instead, restart and let it do an initial sync from the PSMDB-using nodes. It may be surprising that two different versions of MongoDB using different key servers can sync, but as it says in the documentation data-at-rest encryption is not a part of replication. Nodes using it and nodes that are not can also sync between each other.
An extra point regarding 1 that probably isn’t needed, but I’ll add it for completeness: If you enable enterprise features with PSMDB you won’t be able to migrate to MongoDB Community in a single step. You would first disable those features (whether audit log, data-at-rest encryption, etc.) in configuration of PSMDB first, restart etc. until the entire replica set or cluster is running without them, then changeover to MongoDB Community.
On 3. This is not related to rollback or migration I see. But is still a requirement to fill, I see.
I’ve not yet configured using different keys for different db namespaces. I have a recollection that WiredTiger makes this possible, but I don’t believe there is any configuration in the MongoDB layer above that gives a user control of that. (This is for any edition of MongoDB.) We’re open to implementing it in PSMDB if this is crucial improvement that can be made.
For key rotations, the sort where only the keys (local keys) are rewritten, PSMDB has a --vaultRotateMasterKey option that is used, the same as the method that --kmipRotateMasterKey is used for in MongoDB enterprise.
Regards,
Akira
2 Likes
Hi Akira.
Thanks a ton! for your detailed explanation!
Please check the feasibility of providing the db specific key rotations options which is used for multi tenant specific databases as the security is the major concern of all customers with their own keys .
2 Likes
Hi Murali.
I checked regarding having having db-specific key rotations. This is not supported now, which you knew, I did however look in depth into what it would require to make an enhancement.
Underneath the hood MongoDB is already creates a separate local key for each collection (and index) data file. So that sounds positive.
The local keys however stored in one bucket - a single WiredTiger keydb file, which is a normal WiredTiger table.
Just as each collection (and index file) is opened with a key, the keydb WiredTiger file is opened with the “master” key fetched from the Key Management Server (Hashicorp Vault in the case of PSMDB; a KMIP server in the case of MongoDB enterprise).
There is no multi-key possibility in this architecture. Each data file can have only one key by limitation in the WT API (a very reasonable limitation i.m.o.). This includes the WiredTiger keydb table file that encrypts all the local keys for other data files.
As well as this the interaction with the Key Management Server has been programmed with the assumption of fetching only one key.
So it would be a major project to give MongoDB users the ability to have separate Key Management Server keys for different database namespaces in a cluster (or non-sharded replica set).
1 Like
Hi Akira,
Thanks a ton for your brief response…
As we are storing multi-tenancy data in our mongodb our clients worry about the security party and maintaining the tenant specific replica set is very expensive for us.
We are checking the feasibility to provide more security to each tenant in one replicat set .
From mongo db 3.6 we can store the each db into a dedicated data directory , is it possible to provide security to each database directory level irrespective of collection datafile and index datafile ?
1 Like
is it possible to provide security to each database directory level irrespective of collection datafile and index datafile ?
No, not as a MongoDB feature.
A purely filesystem-controlled encryption that has different keys by directory (more likely different mounts mounted as those subdirectories) probably exists. But my gut feeling it is would be impractical with lots of servers, lots of different databases. I’ve never heard of someone doing it.
1 Like
ok Thanks for your valuable suggestion!
2 Likes